安策数据加密保护-基于角色的认证与授权系统

背景

权限系统是软件，互联网开发中经常需要涉及到的概念。本人长时间供职于游戏公司，在游戏开发中，一般不会涉及到权限系统，但是，游戏的客服系统，游戏公司的报销系统，请假系统等等，这些"周边"系统非常需要权限管理。由于游戏公司的注意力都放在了主营业务"游戏"上，往往忽略了"周边"系统的设计。

 认证与授权

没有经过设计的权限系统，有可能将用户登陆，授权等行为放在一起，导致后期难以维护。目前流行的基于RBAC（Role-based access control）的权限系统，可以满足一般企业的权限控制需求，本质上一次"鉴权"分为两步

认证（identification）：检查用户是否为合法用户，用于确认用户的身份。这一步，不会跟权限扯上关系。比如用户名 + 密码 （+私钥）用户指纹用户刷脸

授权（authorization）：通过"认证"的用户，获得与之匹配的"角色"。不同的"角色"，具有不同的权限。比如你可以得到如下权限：

   系统查看权限

   系统修改权限

认证

实现一个认证系统通常有几种方式

一：User访问认证服务

如果认证通过，返回token。token包含了过期时间等重要信息，谁能携带token，说明谁是经过认证的用户。

User携带2中的token请求业务服务

业务服务去认证服务验证token的真伪

认证服务告知业务逻辑token的有效性

如果token验证通过，将业务结果返回给用户

二：User访问认证服务

返回 JWT（Json Web Token）。本质上还是Token，和实现一的区别是JWT是可以自解释的，省去了业务逻辑再次访问认证服务的过程。

携带JWT访问业务服务。由于JWT由认证服务的私钥签名，业务服务持有与私钥匹配的公钥，同样可以确保数据的不可修改性。

返回结果给User

从上面两张图，不难看出实现一更加安全，每次请求会去认证服务校验，缺点就是效率低。互联网应用一般都需要高效率，如果能容忍非法请求存在一段时间后才失效，可以采用实现二的方式。

流程很清洗，所以不再赘述具体的步骤。基于公司的业务，我将"授权服务"拆分为如下几个主要表现：

权限

需要解决的基本问题

为什么需要定义应用？

公司有报销系统，请假系统，KPI系统等。如果开发统一登录系统（SSO），很有必要区分不同应用中的权限，角色等

为什么需要角色？

一个角色包含若干个权限。假如用户A，B都具备同样的100个权限，只需要给用户A，B添加角色X即可，不需要把所有权限都手动添加一遍

为什么需要组？

如果业务需求很简单，可以暂时不实现"组”的功能。试想，今天新入职一位财务部门的新员工，你只需要将其加入“财务组”即可，而不用去关心他是不是该具备报销系统，KPI系统等权限，因为“财务组”的权限早就定义好了。同时，这么做也可以避免角色有嵌套的关系。

更为复杂的问题

角色继承

公司的组织架构本质是树状结构，boss是树根，我们是叶子。角色也可以考虑根节点继承叶子结点的属性。

角色安全

主要针对CEO等高级权限。一个公司只能有一个CEO吧，关键的角色，不能随便创建，至少也要控制一下数量。

版权声明: SafePloy安策利用网络资源获取的信息安全资料加上公司技术人员的理解整理产出的技术交 流文档，如有版权意见，请及时告知安策公司，我们将及时查证纠正错误，谢谢支持。有问题请及时电邮 market@ SafePloy.com

来源：安策信息、安策身份治理技术服务部 | 关键词：身份认证  统一身份认证   | 受欢迎指数（）