更新时间:2024-06-14 08:46:26下载pdf
本次实践针对一个 虚拟智慧校园,通过 资源授权服务(IAM,Identity & Access Management) 功能完成 权限授予 和 权限控制。适用的开发环境为 IntelliJ IDEA 和 API Explorer。
本次案例假设在智慧校园建设中,有一个 施工员 的角色,施工员 可以根据教学楼结构进行空间管理,每个空间可以对应的是教室、会议室或者活动室,并具有在空间内安装、调试设备的权限。
在进行本文案例操作时,请区分 开发者令牌 和 用户令牌。
在操作权限管理时,请使用 开发者令牌。
目前只开放了 开发者令牌 权限管理功能。
在授权用户操作资源时,请切换到 用户令牌。
在进行案例实践操作前,请参考 资源授权服务(IAM)功能介绍,以便您能更快速、完整的完成体验流程。文中相关 API 的说明,请参考 云服务 API 参考。
接口介绍
GET: /v1.0/token
参数说明
获取 开发者令牌 时,请不要携带 targetUid
参数。
获取 用户令牌 时,请携带 targetUid
参数。targetUid
参数内容需要与您给用户授权的用户唯一标识编号保持一致。
目前只开放了开发者身份的权限管理功能,因此在进行权限管理前需要切换到开发者身份,获取授权令牌时不携带 targetUid
参数。
操作结果
接口介绍
POST /v2.0/cloud/iam/role
操作结果
创建的角色编号为 5001。
接口介绍
GET /v2.0/cloud/iam/policy/action
操作结果
根据 施工员 的角色需要的操作行为,创建两个策略,一个管理空间操作,一个管理设备相关的操作:
空间策略:
space:create
space:remove
space:get
space:modify
space:listChild
space:listResource
设备策略:
device:get:shadow
device:issue:shadow
devicegroup:create
devicegroup:list:device
device:get
device:remove
device:transfer
接口介绍
创建空间策略:
POST /v2.0/cloud/iam/policy
由于空间策略里面包含了空间下大部分行为,因此可以先包含所有空间行为,再排除判断两个空间的关系行为(space:relation
) 即可。
请求参数
{
"name": "space strategy",
"description": "Behavior strategies related to space viewing and operation",
"allow_action": [
"space:*"
],
"deny_action": [
"space:relation"
]
}
操作结果
生成的空间策略为 90001。
设备策略创建:
请求参数
{
"name": "device policy",
"description": "View device-related properties, issue commands, transfer devices, etc.",
"allow_action": [
"device:get:shadow",
"device:issue:shadow",
"devicegroup:create",
"devicegroup:list:device",
"device:get",
"device:remove",
"device:transfer"
]
}
操作结果
生成设备策略为 90003。
空间资源案例:
接口介绍
GET /v2.0/cloud/space/child
操作结果
设备资源案例
可在 云项目 下选择进入项目,再在 设备 > 全部设备 下查看当前已经绑定的所有设备,如果没有测试设备,可以通过 添加设备 入口添加虚拟设备进行测试。添加设备的详细步骤,请参考 关联设备。
接口介绍
POST /v2.0/cloud/iam/role/{role_id}/permission
参数说明
{
"permission_list": [
{
"policy_id": "90001",
"resource_id": "158103741",
"resource_type": 1
},
{
"policy_id": "90003",
"resource_id": "vdevo168680716982361",
"resource_type": 2
},
{
"policy_id": "90003",
"resource_id": "vdevo168680716412726",
"resource_type": 2
},
{
"policy_id": "90003",
"resource_id": "vdevo168680715245356",
"resource_type": 2
},
{
"policy_id": "90003",
"resource_id": "vdevo168680714375003",
"resource_type": 2
}
]
}
操作结果
假设在 ISV 系统(您定制开发的自有系统)内某一个员工的唯一标识编号为 testuser003
。您需要给该员工关联角色,实现只有在特定时间对特定空间,有空间及设备操作权限:
唯一标识编号可以为客户自有系统内员工唯一标识编号,也可以为涂鸦用户唯一标识编号,但同一个云项目下的员工标识编号必须唯一。
5001
)则给用户关联角色案例如下:
接口介绍
POST /v2.0/cloud/iam/role/{role_id}/user/{user_id}
请求参数
{
"attach_type": 0,
"start_time": 1686801600000,
"end_time": 1686974400000
}
attach_type
参数说明:
角色 5001 关联的空间为一楼(158103741)。如果需要包含一楼内的教室 1(158103744)、教室 2(158103745)及 活动室(158103746),则需要将 attach_type
设置为穿透。穿透表示可以拥有当前空间,及当前空间下,关联的直接和间接空间权限。并且此用户授予的角色为带有效期的,因此关联角色时需要区分为临时穿透(attach_type
= 0
),具体授权类型参数(attach_type
)定义可查看 给用户关联角色(POST:/v2.0/cloud/iam/role/{role_id}/user/{user_id}
)接口。
操作结果
首先,需要通过已授权用户标识获取 用户令牌。
获取令牌接口介绍
GET: /v1.0/token
获取 用户令牌 时,需要通过 targetUid
参数指定当前需要操作业务的员工唯一标识编号。与上个步骤中 给用户关联角色 使用的用户唯一标识编号必须一致,否则无法进行权限匹配。
操作结果
testuser003 员工的操作都通过此授权令牌调接口进行,操作的目标资源及操作行为本身都会自动进行权限的校验。
已授权权限示例:获取已授权设备(vdevo168680716982361
)的 物模型属性配置(GET:/v2.0/cloud/thing/{device_id}/shadow/properties|device:get:shadow
):
未授权权限示例:针对未授权的设备(vdevo168671847475582
),获取物模型属性配置 则会提示无权限:
该内容对您有帮助吗?
是意见反馈该内容对您有帮助吗?
是意见反馈