普元EOS-用户、角色、权限的设计思路

1 前言

普元EOS作为企业应用开发，肯定要对用户、角色、权限这些内容进行管理，本文就描述这些内容EOS的设计思想，以及如何使用这些工具。

2 传统的访问权限控制

先说一个RBAC的概念，就是 Role-Based Access Control，中文意思是：基于角色（Role）的访问控制。

也就是是说，权限分配给角色，角色分配给用户，用户拥有角色 - 也就拥有了权限，有什么权限就可以访问资源。

RBAC 设计到的关键点有下面几项：

角色（Role）：角色是指在系统中具有一组相关权限的抽象概念，代表了用户在特定上下文中的身份或职能，例如管理员、普通用户等。

权限（Permission）：权限是指对系统资源进行操作的许可，如读取、写入、修改等。权限可以被分配给角色。

用户（User）：用户是指系统的实际使用者，每个用户可以被分配一个或多个角色。

分配（Assignment）：分配是指将角色与用户关联起来，以赋予用户相应的权限。

这里面，用户被分配若干角色，角色被分配若干权限，权限对应的是某个页面，或某个功能，或者是某个接口，或者是某个数据。据此，用户能否访问页面，能否使用功能，能否访问接口，能否操作数据，就确定了。

3  EOS中访问权限管理的思想

EOS在进行权限控制的时候，有以下几个关键的对象：

机构(org)：包括公司、部门，还有总公司、分公司、这样的分类，感觉没必要，反正就是部门，形成组织架构。

用户(user)：用户是指登录信息，包括账号和密码登登录信息。

员工(employee)：机构下自然就有员工，每个员工对应一个用户账号，这是两个对象，但基本是一对一的，一个员工对应一个用户。

角色(role)：角色就是一个权限组，这个很好理解。比较难理解的是角色分为平台角色和应用角色，这个是EOS特有的。

EOS启动后，一切都运行在Afcenter这个平台下，AFcenter：叫做应用联邦中心。

在AfCenter平台下集成组织架构、低开ide、工作流引擎，以及我们自己开发的微服务应用。

那么就有了平台级别的权限、角色，和应用级别的权限、角色。

为了简化开发和降低开发复杂度，我今后很长时间都只处理平台级别的角色和权限，所以这里也只针对平台级别的角色进行概念说明。

好吧，我们假设没有应用级别的角色和权限。(准确的，在EOS的Afcenter中叫业务对象，业务级别的角色，另外也没有权限，叫业务级别的资源)。

资源(resource)：在EOS中，资源就是权限，没有Permission，而是Resource。

其实很好理解，权限是什么呢？权限就是能访问什么页面，能访问哪个API接口，这不就是资源吗？

因此，角色分配页面、功能，就实现了角色 - 权限的关联关系。

资源 - 页面(url)：页面类型的资源，页面可以直接传入一个URL，也可以直接选择低开的表单、视图或者工作流。

资源 - 功能(function)：功能是在高开中使用的资源，可以配置在接口的注解上。通过这种方式来决定能访问哪些接口。

人员与员工的关系：每个员工都对应一个人员，用这个人员进行登录。人员和员工是一个人的两个身份，人员保存这个人的登录账号和密码，员工保存这个人在企业中的身份信息。

人员与角色的关系：EOS中，人员可以分配角色，分配角色后，该人员登录后，就拥有角色下的资源的访问权限。

员工与角色关系：员工也可以分配角色，人员登录后，其对应的员工所拥有角色的资源，也可以访问了。

机构与角色关系：机构也可以分配角色，该机构下的员工登录后，也拥有该机构拥有角色的资源的访问权限。