角色与授予

第 2 课 · 共 7 课 约 8 分钟

Owner、Editor、Viewer 三种角色,四档开放程度;Object Type 继承父资源权限,只有 Owner 能改分享。

本课目标

读完这一课,你将能够

  • 说出 Owner、Editor、Viewer 各自能做什么,并解释「访问」与「角色」的区别
  • 说出四档开放程度,并解释 Object Type 如何继承父资源权限
  • 设计谁能执行 approve-purchase-order,说清角色、roles 与提交条件各管哪一层

先有访问,再有角色

上一节把控制分成强制与自主两类,这一节讲自主控制里最常用的一种:角色。官方把权限拆成两步。第一步是「访问」:你能不能知道这个资源存在,由组织、 Markings 这类强制要求决定。第二步才是「角色」:满足访问要求之后,你能拿它做什么。

拿示例工厂来说:外部审计师所在的公司没有被分享,他连 purchaseOrder 存在都不知道,这是访问没有通过。采购员是本组织的成员,看得到 purchaseOrder,但只有 Viewer,改不了,这是角色不够。两种情况,要补的东西完全不同。

  1. 01Viewer(查看者)查看、使用
  2. 02Editor(编辑者)还能改内容、执行 Action;不能改分享
  3. 03Owner(所有者)还能改分享与访问设置、加别的 Owner、删除分享只有它能改

角色是一组操作,不是头衔。本体(Ontology)上的角色继承到每个 Object Type。类型自己的授予只能加,不能减;Object Type 不能单独设为 Private。本组织开发者是 Owner,但仍受 Markings 约束。

开放程度:从窄到宽

PRIVATE

Private(私有)

只有 Owner。

GROUP

Group(指定范围)

指定的人、部门,或整个本组织;邀请链接也属于这一档。

PUBLIC

Public(登录即可读)

所有登录的 AIDC 账号,只读,不含匿名;只能给 Viewer。

INTERNET

Open to Internet(不登录也可读)

任何人不登录只读。文件、应用、组织 Applications 和 Space 条目支持;只有 Owner 能开。

  • 只有 Owner 能改分享:授予、收回、生成邀请链接、改开放程度,都是 Owner 的事。Editor 能改内容,却不能把内容分享出去,扩大受众只有 Owner 能拍板。
  • Public 与 Open to Internet 只能给 Viewer:所有人都能改的东西不该存在。
  • Open to Internet 只管读取:开放应用内的 Custom widget 可调用允许的匿名读接口。匿名访客不能执行 Action,也不能查询 SQL。

在示例工厂里,可以把 supplier 的 Viewer 授予整个本组织。也可以把客户信用数据分享给财务组,再用列策略限制信用额度。Object Type 继承父资源权限,不能单靠少授予来收紧继承权限。

aidc resources share <rid> --user <账号 id> --role editor
aidc resources share <rid> --group <财务组 id> --role viewer
aidc resources unshare <rid> --user <账号 id> --role editor
aidc resources link <rid> --days 7

上面四条命令依次是:授予一个人 Editor,授予财务组 Viewer,收回一条授予,生成 7 天有效的邀请链接(缺省 30 天)。只有 Owner 能改分享。

示例:谁能执行 approve-purchase-order

在示例工厂里,采购主管批准采购订单。「谁能批准」不是一个开关,而是三层依次把关:

  1. 身份与角色

    先验证身份与权限。Viewer 和匿名访客不能执行 Action。Agent Key 可按主体权限和 restrictions 执行获准 Action。

  2. Action 自己的 roles

    定义里的 roles 可以再收窄允许的角色,缺省是 developer、member、editor。

  3. 提交条件

    按参数、对象属性、当前用户判断,不满足就返回你写的失败信息。这是最细的一层。

三层是「与」的关系,任何一层不过,就执行不了。所以别指望角色去表达「这一张订单」这样的细节:角色回答「你能不能做这一类事」,提交条件才回答「这一张你能不能做」。

AIDC 已有 Groups。可以建采购主管组,维护成员,再把资源分享给组。下面的提交条件另管一件事:订单创建人不能批准自己的订单。ownerId 记录创建人。

{
  "kind": "actionType",
  "apiName": "approve-purchase-order",
  "title": "批准采购订单",
  "schema": {
    "parameters": [
      { "name": "purchaseOrder", "type": "object", "objectType": "purchaseOrder", "required": true }
    ],
    "rules": [{ "type": "modifyObject", "objectType": "purchaseOrder", "object": "$purchaseOrder", "values": { "status": "approved" } }],
    "submissionCriteria": [{
      "condition": { "type": "comparison", "left": { "user": "id" }, "operator": "isNot", "right": { "param": "purchaseOrder", "property": "ownerId" } },
      "failureMessage": "不能批准自己创建的采购订单"
    }],
    "actionLog": true
  }
}

提交条件里,user 取当前执行人,param 取参数或参数对象的属性,literal 是写死的值。先用 aidc semantic apply approve-purchase-order --param purchaseOrder=PO-1001 --validate-only 试一次,再正式提交。

要点

  • 先有访问、再有角色:访问由组织与 Markings 这类强制要求决定,角色决定拿资源做什么。
  • AIDC 有 Owner、Editor、Viewer 三种角色;只有 Owner 能改分享,Editor 能改内容、执行 Action。
  • 开放程度从窄到宽:Private、Group、Public、Open to Internet;Public 与 Open to Internet 只能给 Viewer。
  • 角色沿 本体 继承到 Object Type,只加不减;本组织开发者是 Owner,但仍受 Markings 约束。
  • 谁能执行一个 Action,由身份与角色、roles、提交条件三层依次把关。

练一练

为示例工厂设计一张授予表

角色少,靠设计才能用好。先在纸上定,再用命令核对。

为采购员、采购主管、销售、质量、财务,在 supplier、purchaseOrder、customer 上各定 Viewer、Editor 或不授予。标出哪几处只有 Owner 才设得了。

小测

选一个答案,马上看解析。

Q1你是某个 Object Type 的 Editor,想让隔壁部门的同事也能看它。你能做什么?

Q2要求「谁创建的采购订单,谁不能批准它」。最合适的写法是?

Q3Public 这一档最多能给什么角色?

延伸阅读