开发者学堂课程【IDaaS企业身份管理：上手访问控制】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/980/detail/14908
上手访问控制
1.第一级资源
第一级资源叫应用访问的这个权限，即这个账户能不能访问这个应用，这个是在最初力度下，也是最常用的，往往到这个力度可能就已经完全足够使用。对很多企业来讲，最常用的这种访问控制，对于这个当前账户是我能访问到应用一，应用二，因为应用b区进行放行或者不放行的操作。
2.第二级权限
第二级权限指的是功能模块或者菜单一级的权限，就是进入到这个应用内，变成了一个应用内权限，可以进入到应用内之后到底存在应用里面可以进行哪些管控以及进行哪些操作。它到底能看到哪些菜单？比如说如果一个快递员进入到一个快递管理系统的话，可能只看到接收快递的那个栏。无法看到整个的更宏观的快递管理，人员管理，这是2级授权的概念。
3.第三级权限
第三级权限的概念是数据呈现的概念，就是在整个二年权限中进行细分。例如收发快递的信息，理论上只能看到自己本人的。数据本身也会有一个范围，或者只能看到北京这个地区的快递。看不到上海的这三级权限，会一点一点的把用户使用权限规划的的非常的细。
4.优点与缺点
细到一定程度自然就很容易去避免很多的过去经常发生的一些越权的问题。当权限管理的集成细到这个程度，带来的这个便捷性，它带来的统一授权和统一管理的优势是非常清晰的。但是同时带来的这个这个集成成本，交付难度也会上升，因为每一套系统内的权限系统，相对而言还是比较缺乏规范的，所以在统一的去进行管理的时候会容易。也不是说所有的刚才举的这些功能都支持，比如目前在进行授权的时候，目前只支持这个到一级的授权，就是到这个用户能不能访问？喜欢哪个应用以及不能访问哪个应用，应用内部的权限管理，还没有上对应的功能去统一去管。
5.应用场景
本身进行授权的时候，如果支持的话，也会以rc作为一个基础，可能这个适用场景会更少一些。现在啊也在排期的和规划中，但是并不会很快的去进行处理。比如临时授权对于临时工的一些访问，这些在授权环节可以有的这种变化是比较多的。而我们主要希望提供的是一个引擎，一个核心，把这个基座和底座去提供出来之后，然后允许其他的开发商或者客户自己的开发，就可以在这个基础上去构建所需要的一套这个这个权限的管理体系。我们就相当于是这展现的基座。刚才这些所有的收拢起来的话，就可以看到下图中是整个的完整代授权的主体，即所有的这些通讯录，他的组织、他的组、他的账户所有的信息。可能是要授权的所有的客体，也就是所有可以授权的资源，里面可能有十个应用，每个应用内可能也有八个角色，这八个角色下又可以去拆分，那么两边的这个授权关系就可以在Adass统一的一个界面上去进行完整的调控。每一个用户到底在哪一个应用中具备什么角色，可以访问哪些系统和菜单？就有一个宏观的统一的管理入口，这是我们在未来希望能给客户带来的从业务层面上管理的宏观性的价值。现在我们更多的提供的是一个最基础的这个访问控制，知道这个人到底能不能访问某个应用。
五、应用实例实操
首先来到阿里云控制的产品详情页，点击前往控制台，进入到课程中创建的实例，可以看到有对应的应用：
首先确认有一个账户，添加一个应用到阿里云用户，点击立即添加，需要单点登录到以前的体系内：
下载一个date的文件，上传完成之后，就完成了相应配置。在sso管理的用户sso，点击编辑将文件上传。
在创建用户界面，额外添加俩个账户，为了测试方便，假设在应用系统中可以存在俩个不同的账户。
在选择单点登录的时候，可以选择其中一个进行登录。打开新的浏览器进行访问，进行登录，二次认证，进入我的应用。
可以看到是尝试用michael的账户进行登录，去访问到阿里云的体系中。在整个创建的过程中，并没有创建出来跟michael对应的账号，在进行单点登录的时候，会无法识别。
那么就需要修改在ADaas中的配置：现在选择应用账户进行登录，这时需要对每个需要登录阿里云的账户进行应用账户的分配，需要告诉ADass，当michacel的账户进行单点登录时，应该扮演的账户叫test1，因此需要进行添加。
作为test1的身份登录阿里云，重新进行登录，进入二次认证后：如下图，作为test1这个账户就成功访问到阿里云平台，拥有跟test1对应的一系列权限。
再举一个例子：假设在ADass中，为当前的应用，再为machel添加一个新的用户叫test2。可以看到test1和test2同时被划归mechel的账户下：
重新发生登录之后，会发现应用账户多了一个选择，会同时存在多个当前账户已登录的账户，允许用户去选择一个当天需要访问的身份是哪一个。
选择test2后，登录进去，登录成功，选test1进入登陆，登录成功。相当于一个ADass的登陆中，可以选择多个身份去进行访问。
下图有俩个应用：sonarqube2和阿里云用户sso。通过阿里云应用管理的方式，怎么设置mecheal怎么去设置成只能访问某一个特定的应用。
回到控制台中，可以发现一开始被应用配置的时候，当时配置全员可访问，这是当时为他设定的授权范围，假设现在改成手动授权，这意味着需要单独为这个应用去分配到底哪些账户，哪些组织可以访问阿里云的这个应用，假设回到用户这边，切到手动授权，但是没有给他授权，那么这个应用在他这一侧是不完全不可见的状态。所以在用户侧就没有办法去登陆到对应的那个应用。那么假设现在是手动授权，授权添加一次新的这个授权方式，比如说把michael指定为授权主体，或者在组织里面去添加相对应的这个组织信息，去进行一次保存，保存了之后就拥有了当前对这个应用的这个访问的这个能力。再重新刷新，作为当前michael这个应用门户的话，会看到这个应用重新出现。
所以在整个过程中可以看到通过应用账户和授权这两个这个功能菜单，可以控制哪些账户可以访问哪些应用，然后访问对应应用的时候，所扮演的身份，所以这两个功能在叠加上整个的单点登录的这个功能，ADass去进行身份访问控制非常基础的这三个模块。
