开发者学堂课程【IDaaS企业身份管理：上手访问控制】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/980/detail/14908
上手访问控制
内容介绍：
一、IDaas 的必要性
二、应用访问流程
三、权限管理 - 横纵矩阵授权
四、授权粒度 - 集中式授权管理
五、应用实例实操
一、IDaas 的必要性：
企业内部对身份的管理、对权限的控制和统一的选项控制，一直有一个非常核心的强烈诉求。伴随着当前内部的员工数量和应用数量以及员工之间可以去访问的这个连接数量变多的时候，就需要在管理的层面有一个统一的收口，统一的进行分配啊，以给员工对应的服务。
三、如果不使用统一的方式去管理的话，例如在应用a里面，张三创建了一个管理员账号，那么张三就可以拿着这个账号再给李四，李四给王五，那么这个过程其实是完全不可控的。
四、使用了统一的权限管理之后，可以统一给员工分配对应的权限，统一的去进行管理，统一的去进行查看员工的权限，同时可以在这个单点上面去确定访问者就是他本人，例如ADaas默认开启的智能模式的二次认证，会通过短信的方式去验证，当前的操作者是否是本人。而无需再将密码告诉其他员工来进行确认。这样在整个访问进行收口之后，在后续的审计、跟踪中，出现了一些异常情况复盘的时候，就可以定位到到底是谁在什么情况下是否拥有权限去进行某个操作，或者它是否进行了一些越权的行为。
二、应用访问流程
用户访问（·支持idp和sp发起 ·用户选择登录方式）→2.身份认证（·首次登录 ·二次认证 ·强制改密/密码过期）→3.检查权限（·检查是否授权）→4.应用账户（·检查应用账户策略 ·使用应用账户）→5.应用SSO（·传送登录结果）
1.用户访问
2. IDaas体系保护的这个应用会触发整个单点登录的流程，有idp和sp发起，在这个过程中，用户会被提示需要登录，ADaas会提供一系列登录方式的组合。用户可以自由选择登录方式。
3. 身份认证
4. 对于首次登录的验证，对于二次认证的验证，对于密码强制改密，密码过期的一些强制校验的验证。
5. 检查权限
6. ADaas会验证当前用户想要访问的应用是否具有权限，管理员是否允许用户去访问他要访问的应用，允许才可访问。如果不允许，会提示一个错误信息，告知当前没有授权去访问。
7. 应用账户
应用账户的转化，把应用账户或者在很多系统以及一些线下交付的版本中，应用账户会成为子账户。是一个完全一个东西，改名叫应用账户。是为了和阿里云访问控制的子账户名称去进行一个规避。这是两个不同的概念，虽然在两套体系中概念是相近的，但是在我们的体系中把这个质量户叫做应用账户。这也是海外的绝大部分厂商所使用的一个标准名称叫application user。应用账户本身作为ADaas核心的通讯录里面这个账户。
8. 比如说一名员工，在应用中所扮演的那个账户或者角色的名称到底是什么？可以出现两个账户在这个应用里面都存在，员工作为这两个账户的身份登录到这个应用中。登录了主账户之后想要去访问对应的应用，在应用中它到底扮演应该是一个什么样的账户或的角色？是怎样的关联关系？
9. 应用SSO
最后发起了这个应用的单点登录，比如说流程里边可能就是请求到他的acs地址。即assertionConsumer url。指的是断言接收的地址。也就是说接受summe response地址，叫做acl地址。或者oadc协议里面去接收返回信息，那么这个信息会返回到应用，然后后续可能还需要跟ADaas进行交互，然后或者去见证我发过去的这个信息，然后实际的把用户进行登录。
三、权限管理 - 横纵矩阵授权
● 集中权限管理（PS），对用户权限进行多维度及细颗粒度的划分，实现跨部门、跨地区的分层分级管理。一级/二级/三级授权，对应分别是能访问哪些应用，能访问应用里的哪些模块，能访问模块下的哪些数据。
● 通过默认部门组(纵向)；给用户整理汇报关系，加入这个组织的自动获取权限；
● 自定义岗位角色(横向)，给用户打上属性标签，拥有这个标签的自动获取权限；
1.纵向权限
对于权限管理，会有俩个维度的考量。一是授权的维度本身从哪些维度去进行授权。现在有一套完整的组织架构树的管理方式，现在的授权体系可以直接把某一个树节点，比如下面图中，就是上海分公司的这个节点，可以直接把这个节点授予给某个应用，那么这个节点下的所有的此部门和子部门对应的人员就自动拥有了去访问应用a的这个访问权限，那么可以某一个单个人去赋予到这个这个应用的权限，只有指定员工可以访问的话，可以用a去进行一个关联。
2.横向授权
横向授权指的是组的概念，组的概念还在开发中啊，当前这个2020年3月底还没有把组的这个理念去上限，但是组的概念也较好理解，就是在使用组的时候往往会有角色组，岗位组，但是本身只是组的一些概念上的变化，它本身并没有特别多其他的属性，所以组可以理解为是跨组织机构，跨部门的。可以把一些人拉到一起，比如说一个项目组可能会把这个很多售前售后交付这个研发的人都拉到一块，进行一次项目交付，那么这个项目组可以把人都拉到一起后统一一组的维度去进行授权。
四、授权粒度 - 集中式授权管理
基于角色授权（RBAC）
● 基于用户的组织架构、角色、加入组织的员工自动获得权限
基于属性授权（ABAC）
● 通过数据字典，自定义员工属性，具有该属性的员工自动获得权限
临时授权
● 通过黑名单的方式始终拒绝，面对复杂的授权要求也可以轻松管理
区分被授权的主体，就是主体指的是是哪些账户，哪些组织，哪些组。权限这一面到底应该怎么去划分。在通常意义上，企业去构建一个完整的权限模型的时候，会有这个三级的这个权限。根据每一个不同的级别的定义不同。举个例子，假设这个用户现在想要访问某一个特定资源，这个资源本身可能是有三级的属性。
