Xiaomi Galaxy Talos Book

认证授权模型


权限模型介绍Talos中认证/授权相关的概念和配置规则

权限类型

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

用户身份

使用Talos,client登录后认证的身份有以下几种:

  • Developer
  • AppRoot
  • AppUser
  • Guest

以上身份对应的权限如下:

  • Developer 身份才可以创建Topic,并作为创建的所有Topic的Owner,对所有以该身份创建的Topic都具有admin的权限;
  • AppRoot 是针对某一个Topic具有Topic Read & Message R+W的权限,可由Developer进行授权,请注意上述权限中低于等于TOPIC_READ_AND_MESSAGE_FULL_CONTROL的权限才允许被下放,Topic的Write和Permission操作等更高级的权限是不允许被下放,只有Topic的Owner身份Developer才具有这些高级权限
  • AppUser 是通过OAuth或SSO登录的某个app用户在登录Talos所认证的身份
  • Guest 是指访客的身份

用户登录Credential配置 => 认证身份

每个使用Talos的用户都需要到小米开放平台申请开发者帐号,并创建云服务密钥,得到一组或几组App的AppKeyAppSecret,用以使用SDK时配置登录的Credential;

配置Credential进行登录时不同的身份对应着不同的用户类型,如下:

  1. DEV_XIAOMI,Credential配置使用AccountKey/AccountSecret通过SDK签名认证,认证后身份为Developer,为其创建的所有Topic的Owner,拥有该开发者名下所有Topic的所有权限;

  2. APP_SECRET,Credential配置使用AppKey/AppSecret通过SDK签名认证,认证后身份为AppRoot,需要Topic的Owner进行授权才具有相应的权限;

  3. DEV_XIAOMI_SSO

  4. APP_XIAOMI_SSO

  5. APP_ACCESS_TOKEN,OAuth认证

  6. APP_ANONYMOUS,匿名登录,认证后身份为应用终端的Guest,需要Owner的授权才能进行相应的访问;

目前支持的认证类型

  • 签名认证
  • OAuth
  • SSO

授权操作

在如下场景中可能会涉及到授权身份的配置问题,即使用Grantee的配置,如下说明

  • createTopic:创建Topic时设置ACL:
  • setPermission:设置SetPermissionRequest中的Grantee
  • revokePermission:设置RevokePermission中的Grantee
  • queryPermission:设置GetPermission中的Grantee

Grantee需要配置GrantType和Identifier,它们的对应关系如下:

  • GrantType.DEVELOPER,Identifier需要配置为 accountId
  • GrantType.APP_ROOT,Identifier需要配置为 appId
  • GrantType.APP_USER,Identifier需要配置为 appId
  • GrantType.GUEST,Identifier需要配置为 appId

开发建议

权限方面
  1. 每个业务组申请一个开发者帐号AccountId,管理业务相关的多个topic,每个topic对应一个Appkey;
  2. 业务组内部:不同的topic通过Appkey实现隔离;
  3. 业务组之间:如果有访问需求,通过AccountId/AppId进行交叉授权
Quota方面 (开发中)
  1. 每个accountId具有一定的quota限额,accountId只在拥有quota后才可以创建topic,quota的额度向Talos管理员申请
  2. 每个topic具有一定的quota限额,accountId的quota大于等于名下所有topic的quota总和