Xiaomi Galaxy Talos Book

Authentication and authorization model

Authorization model introduces Talos authentication/authorization-related concepts and configuration rules

Permission types

PUT_MESSAGE = 1                           // Message Write
GET_MESSAGE = 2                           // Message Read
FULL_MESSAGE_CONTROL = 3                  // Message R+W
DESCRIBE_TOPIC = 4                        // Topic Read
PUT_MESSAGE_AND_DESCRIBE_TOPIC = 5        // Message Write & Topic Read
GET_MESSAGE_AND_DESCRIBE_TOPIC = 6        // Message Read & Topic Read
TOPIC_READ_AND_MESSAGE_FULL_CONTROL = 7   // Topic Read & Message R+W
CHANGE_TOPIC = 8                          // Topic Write
FULL_TOPIC_CONTROL = 12                   // Topic R+W
FULL_CONTROL = 15                         // Topic & Message R+W
CHANGE_PERMISSION = 16                    // Permission Admin
ADMIN = 31                                // All Admin

User identity

With Talos, the authenticated identity of the client after logging in is as follows:

  • Developer
  • AppRoot
  • AppUser
  • Guest

The corresponding permission for the above identity is as follows:

  • Developer identity can create Topic, and as the Owner of all Topic created, has admin permission for all Topic created by this identity;
  • AppRoot focuses on Topic Read & Message R+W permission of any Topic; it can be authorized by Developer. Please note that only permissions below or equal to TOPIC_READ_AND_MESSAGE_FULL_CONTROL are allowed decentralization. More advanced permissions such as Topic Write and Permission operations are not allowed to be decentralized; only the Owner Developer of the Topic has these advanced permissions
  • AppUser is the certified identity of an app user who logs into Talos via OAuth or SSO
  • Guest refers to the identity of the visitor

User Login Credential Configuration => Authenticate Identity

Every user who uses Talos needs to apply for a developer account on the Xiaomi Open Platform and create a cloud service key to get AppKey and AppSecret for one or more group Apps to be used to configure login Credential when using SDK;

When configuring Credential to log in, different identities correspond to different user types, as follows:

  1. DEV_XIAOMI, Credential configuration uses AccountKey/AccountSecret to pass SDK signature authentication; the identity after the authentication is that of a Developer, and the Owner of all Topic created for this has all the permissions of all Topic under the developer name;

  2. APP_SECRET, Credential configuration uses AppKey/AppSecret to pass SDK signature authentication; the identity after authentication is that of AppRoot. The Owner of the Topic needs to authorize to have the corresponding permissions;

  3. DEV_XIAOMI_SSO

  4. APP_XIAOMI_SSO

  5. APP_ACCESS_TOKEN，OAuth认证

  6. APP_ANONYMOUS, Anonymous login. After authentication, the Guest whose identity is the application terminal needs the authorization of the Owner to make the corresponding access;

Currently supported authentication types

  • Signature authentication
  • OAuth
  • SSO

Authorization operation

In the following scenario, the issue of authorized identity configuration may be involved, that is, the use of Grantee configuration, as described below

  • createTopic: Sets ACL when creating Topic:
  • setPermission：Sets Grantee in SetPermissionRequest
  • revokePermission: Sets Grantee in RevokePermission
  • queryPermission: Sets Grantee in GetPermission

Grantee needs to configure GrantType and Identifier; their correspondence is as follows:

  • GrantType.DEVELOPER, Identifier needs to be configured as accountId
  • GrantType.APP_ROOT, Identifier needs to be configured as appId
  • GrantType.APP_USER, Identifier needs to be configured as appId
  • GrantType.GUEST, Identifier needs to be configured as appId

Development suggestion

Permissions
  1. Each business group applies for a developer account AccountId, manages multiple business-related topics, and each topic corresponds to an Appkey;
  2. Inside the business group: Different topics are isolated through AppKey;
  3. Between business groups: Cross-authorization with AccountId/AppId if there is an access requirement
Quota (Development)
  1. Each accountId has a certain quota; accountId can create topic only after having a quota; quotas apply to Talos administrator
  2. Each topic has a certain quota; the accountId quota is greater than or equal to the sum of quotas of all topics under the name