名词解释
ITAM：ITAM 是对 IT 办公资产--实物资产 (如笔记本电脑)、软件资产 (如 Office365)--进行生命周期管理的系统。
ITAM-Auth：ITAM 系统的鉴权服务。
ITAM-Data：ITAM 系统的数据服务。
SaaS：软件即服务（英语：Software as a Service，缩写：SaaS），一种软件交付模式。在这种交付模式中，软件仅需通过网络，不须经过传统的安装步骤即可使用，软件及其相关的数据集中托管于云端服务。
ServiceNow：ServiceNow 是一家美国软件公司，总部位于加州圣克拉拉，该公司开发了一个云计算平台，帮助企业管理企业 IT 工作流。ServiceNow 由弗雷德·卢迪于 2003 年创立，在纽约证券交易所上市，是罗素 1000 指数和标准普尔 500 指数的组成股。2018 年，《福布斯》杂志将其评为全球最具创新性公司的第一名。
背景
本方案梳理了业界主流权限模型，IT Saas 化中权限管理要解决的问题，参考了公司内外、国内外的一些权限设计方案，结合 RBAC、ABAC 模型提出了 ITAM 融合模型权限管理方案。
主流权限模型
参考了多个系统的权限实现后，总结出公用的权限理论模型，具体到每个系统的实现会有一些改造和优化，本部分介绍工业界广泛使用的权限模型。
概述
主体：一个访问行为的发起方，此处简化理解，假设都是用户
客体：访问行为的施加对象，如页面、功能、数据
ACL (Access-Control List 访问控制列表)
Subject：主体，访问方，可以是人也可以是系统、设备等
Action：访问的具体动作，如 Create、Read、Edit...
Object：客体，被访问方，可以是系统中的某个条目、某个文件等
一种比较基础的权限管控机制，简单直接，常应用于操作系统中的文件系统。
MAC (Mandatory Access Control 强制访问控制)
Subject：主体，访问方，可以是人也可以是系统、设备等
Action：访问的具体动作，如 Create、Read、Edit...
Object：客体，被访问方，可以是系统中的某个条目、某个文件等
Attributes：在 Subject 和 Object 上均可能有多个 Attributes ，用于鉴权判断的元数据
主体和客体会被分别赋予一个机密等级，访问时双向检查主体和客体的等级是否匹配，常被应用于安全要求性高的领域，如军事、金融、政府、计算机系统安全等，双向鉴权时遵循 authorization rule，该 rule 的存储位置和管理通常非常严格。
DAC (Discretionary Access Control 自主访问控制)
Subject：主体，访问方，可以是人也可以是系统、设备等
Action：访问的具体动作，如 Create、Read、Edit...
Object：客体，被访问方，可以是系统中的某个条目、某个文件等
Grant：转授权行为，Subject 1 可对 Object 执行的全部或部分 Action 转授给 Subject 2
自主访问控制简单理解是权限 Subject 可将自己拥有的权限转移给其他主体，通常是为了解决权限分配灵活度的问题，但是在 B 端系统里往往不会仅仅采用 DAC 这一种权限模型（比如会结合 MAC 模型），因为该模型会导致管理员无法掌控的权限扩散。
RBAC (Role Based Access Control 角色访问控制)
RBAC 认为权限的本质是 Who 对 What 进行了 How 操作
User：主体，访问方，代表系统中的用户，但也可以是机器、网络等 - Who
Object：客体，被访问方，可以是系统中的某个菜单、按钮、数据记录、API 等 - What
Operation：系统中用户可执行的某个动作 - How
Permissions：权限，代表可向 RBAC 保护下的 Object 执行 Operation （What + How）
Role：角色，代表组织内一些职责及该职责下的用户拥有某些指定的权限
Session：会话，会话由一个用户触发，同时会话激活会话关联的一个或多个 Role
本文重点介绍被 INCITS（国际信息技术标准委员会） 采纳的标准 RBAC 模型
标准 RBAC 分为 4 个子模型：
RBAC0 - Core RBAC
RBAC1 - Hierarchical RBAC
-
一般继承：角色之间的是一个绝对偏序的继承关系（有向无环，成环的角色继承无意义），这个设计比单一的树状继承更自由，适用于角色权限有继承需求但又不是严格的上下层级关系的权限场景。
RBAC2 - Constrained RBAC
RBAC3 = RBAC 1 + RBAC 2
RBAC3 是 RBAC1 和 RBAC2 的合集，既包含了角色继承也包含了相关约束。
优点：能力最强大。
缺点：4 种模型中最复杂的模型，管理成本较高。
总体上，RBAC 被认为满足了三个重要权限原则：
-
最小权限：用户仅在触发会话动作时获取到其所在角色，该角色定义了完成该动作所需的最小权限。 -
权限抽象：可结合业务抽象出具体的权限行为，如发表评论、上传附件，而不是简单的 读、写、查。 -
职责分离：角色本身表征了职责，加上 RBAC 支持角色和角色间的互斥机制，实现高风险动作分治。
对标准 RBAC 的扩展
-
面向单个用户授权时的管理成本：可以跳过 Role 直接对用户授权 -
面向大批量用户授权时的管理成本：Group 也可以被分配到 Role 中 -
面向维护 Role 的管理成本：用户在 Role 中可进行权限裁剪（代表这个用户仅拥有这个 Role 的部分权限）、可复制 Role 等等 -
和其他权限模型的结合： -
和 DAC 、MAC 的结合 -
和 ABAC 的结合
-
ABAC (Attribute Based Access Control 属性访问控制)
Subject：主体，访问方，代表系统中的用户，但也可以是机器、网络等
Object：客体，被访问方，可以是系统中的某个文件、设备、数据库记录等
Operation：系统中主体对客体请求执行的功能/行为，可包括 read、write、edit、delete 等
Attributes：属性，Subject、Object、Operation 和 Environment Condition 都有属性，属性是一对键值
Policy：一系列由属性和属性值构成的规则或关系，通过该规则/关系可判断一个访问能否被允许
Environment Conditions：可被识别的环境条件，访问行为发生的环境，通常可以是时间、地点、IP、设备、操作系统、风险级别等
ABAC 是建立在 Subject 属性、Object 属性、环境属性及访问 Policy 之上的细粒度权限管控，ABAC 能做到只有符合特定属性的 Subject 在特定条件下可以对符合特定属性的 Object 执行某权限行为。
下一代权限模型探索 - NGAC
在 DAC、MAC、RBAC、ABAC 这些主流权限模型之外，还存在大量其他权限模型（如 LBAC、GBAC、CBAC、OrBAC、RAdAC...），但目前还没有一种权限模型得到了工业界的广泛采纳。
学术界已经有了一些关于下一代权限模型的研究成果。
NIST（美国国家标准技术研究所）在 2019 年提出了 NGAC(Next Generation Access Control 下一代访问控制模型)，提出这是区别于现有权限模型之外的一种全新模型且可以广泛兼容当前数字生态里的各种权限场景。
从下图来看更像是 RBAC 思路和 ABAC 思路的结合，结合点是 用户 —— 角色的关系不再人为分配，而是根据 Policy 自动分配，用户以角色身份进行权限行为时再过一遍 ABAC 的规则判断。
典型应用场景：Alice 只有在工作日的上午 10:00-18:00 在伦敦的办公室网络下（role-based permission policy）才能以财务的角色访问并修改订单系统里的数据 （role-based permission policy）
-
Role
-
Condition
-
Script
-
资源的管理粒度细，所以权限的管控粒度、灵活性好；
-
针对不同的鉴权场景使用不同的鉴权模型；
-
UI 层资源和权限的数据链接、各信息的 Link 跳转设计细致；
-
用户和用户组的关联缺乏灵活性，例如按照用户属性圈定一批用户作为一个组；
-
权限配置比较分散，使用权限的地方散落在各个资源管理入口；
-
ACL 的 Condition 配置功能简陋，配置门槛高；
-
没有考虑开放与集成场景的鉴权；
-
没有数据范围鉴权。
-
权限管理的本质是对用户访问系统资源做权限控制，需要先定义好系统中的用户、资源、权限；
-
用户体量大、岗位流转率高的情况下，要能高效、便捷的圈用户、授权；
-
数据鉴权，包括数据行鉴权、列鉴权，数据权限高效授权、鉴权；
-
良好的业务扩展性；
-
权限管理和权限使用的前后端模块划分不一致，业务定义和工程定义不一致，例如前端是一个整体服务，后台划分了多个微服务，在权限管理、功能鉴权、数据鉴权时如何划分和控制；
-
权限需要的特色功能：角色互斥，身份代理，权限前置依赖，权限审批流程，角色授权设置有效期，权限策略优先级。
-
工作效率：用户可以多快获得应当具备的权限；
-
鉴权效率：高性能保证鉴权不影响正常业务逻辑处理；
-
安全性：保证不会由于权限系统误判导致功能、数据泄漏；
-
扩展性：在系统的多个节点提供扩展性，包括但不限于用户类型扩展、用户属性扩展、资源类型扩展、资源属性扩展。
-
接口资源表式格式：{业务应用}:{工程应用}:{接口}
-
功能权限项格式：{业务应用}:{resource}:{action}
-
itam-flow 作为一个内部系统注册为权限用户；
-
设置一个角色，这个角色可以查询 itam-data 服务的 Employee 查询接口，数据列只有 UserName、Logo、Department、Sequence；
-
itam-data 的 Employee 查询接口，识别 itam-flow 系统，按照策略查询 itam-flow 的数据权限，按权限配置返回数据。
