光宗耀组——项目需求分析

|作业所属课程 |https://edu.cnblogs.com/campus/zswxy/2018SE|
| ---- | ---- | ---- |
|作业要求 |https://edu.cnblogs.com/campus/zswxy/2018SE/homework/11607|
|团队名称 |光宗耀祖|
|作业目标 |需求规格说明书|
|gitee |https://gitee.com/gzyz|

| 成员 |任务分工 | 任务比重 |
| ---- | ---- | ---- | ---- |
| 廖辉映 |微服务模块编写 | 24% |
| 覃澳 | 框架编写 | 19% |
| 梁凤波 | 测试 | 19% |
| 熊雅琴 | 项目文档编写 | 19% |
| 赵艺 | 微服务信息传递编写 | 19% |

1. 引言

1.1 目的

​本次设计的网站，是微服务权限系统。其基本原理与RBAC非常相似，更详细的RBAC模型非常复杂。本文只做了一些基础的理论性概述。

1.2 范围

适用于各个管理层次的管理者。

1.3 背景

​在20世纪90年代期间，大量的专家学者和专门研究单位对RBAC的概念进行了深入研究，先后提出了许多类型的RBAC模型，其中以美国Geore Mason大学信息安全技术实验室（LIST）提出的RBAC96模型最具有系统性，得到普遍的公认。RBAC认为权限的过程可以抽象概括为：判断【Who是否可以对What进行How的访问操作（Operator）】这个逻辑表达式的值是否为True的求解过程。
即将权限问题转换为Who、What、How的问题。who、what、how构成了访问权限三元组。

1.4 定义

RBAC支持公认的安全原则：最小特权原则、责任分离原则和数据抽象原则。
最小特权原则得到支持，是因为在RBAC模型中可以通过限制分配给角色权限的多少和大小来实现，分配给与某用户对应的角色的权限只要不超过该用户完成其任务的需要就可以了。
责任分离原则的实现，是因为在RBAC模型中可以通过在完成敏感任务过程中分配两个责任上互相约束的两个角色来实现，例如在清查账目时，只需要设置财务管理员和会计两个角色参加就可以了。
数据抽象是借助于抽象许可权这样的概念实现的，如在账目管理活动中，可以使用信用、借方等抽象许可权，而不是使用操作系统提供的读、写、执行等具体的许可权。

1.5 参考文献

[1]http://csrc.nist.gov/groups/SNS/rbac/index.html.

[2]http://csrc.nist.gov/groups/SNS/rbac/faq.html.

2. 项目概述

2.1模型描述

RBAC的模型中包括用户（U）、角色（R）和权限（P）等3类实体集合。 一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。

2.2模型关系

在RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、权限permissions(PRMS)五个基本数据元素，此模型指明用户、角色、访问权限和会话之间的关系。

1、每个角色至少具备一个权限，每个用户至少扮演一个角色；可以对两个完全不同的角色分配完全相同的访问权限；会话由用户控制，一个用户可以创建会话并激活多个用户角色，从而获取相应的访问权限，用户可以在会话中更改激活角色，并且用户可以主动结束一个会话。

2、用户和角色是多对多的关系，表示一个用户在不同的场景下可以拥有不同的角色。

3、角色和权限是多对多的关系，表示角色可以拥有多分权利，同一个权利可以授给多个角色。

2.3模型设计

随着系统的日益庞大，为了方便管理者的管理，可引入角色组对角色进行分类管理，跟用户组不同，角色组不参与授权。例如：某电网系统的权限管理模块中，角色就是挂在区局下，而区局在这里可当作角色组，它不参于权限分配。另外，为方便上面各主表自身的管理与查找，可采用树型结构，如菜单树、功能树等，当然这些可不需要参于权限分配。

2.4一般约束

进行本软件开发工作的约束条件如下：

1.开发时间紧张：由于期末将近，考试和作业繁多，开发时间十分有限。

2.开发项目技术不够复杂：由于开发人员和测试人员的知识薄弱，技术欠佳，以至于此项目还有待完善。

2.5假设与约束

1.团队之间的积极配合是非常重要的。

2.开发人员需对本项目熟悉且掌握一定代码设计知识，测试人员需要理清此模型的逻辑关系。

3. 具体需求

​ 通过用例图我们可知，此RBAC模型基于角色的访问控制，是“用户-角色-权限”的授权模型；

用例图如图所示：

3.1功能需求

3.1.1用户认证

在用户认证，简单的讲，可以简化为应用对用户登录状态的认证。传统的单体应用，使用session来进行用户认证，但是这种方式已经不适合微服务的场景了；微服务的结构下，可以通过分布式session来解决，也可以通过和Spring Cloud Security结合很好的OAuth2来解决。

a.用户登录，验证成功
b.服务器给用户客户端分发令牌token，并将token以及其他信息存储到认证服务或者公共缓存中
C.客户端请求时带服务器分发的token，请求服务
d. 服务拿到用户token，并通过认证服务或者公共缓存中存储的token来校验用户token
e. token校验成功，执行服务逻辑，返回结果

3.1.2服务权限认证

微服务的一大核心是将服务进行拆分，降低服务的复杂度，拆分后，就会有服务之间的调用关系，服务之间的权限控制也是必要的。一般只需要维系微服务之间的调用关系，微服务调用时，调用发带着自己的服务标识，被调用发校验调用方的
权限。

3.1.3用户权限认证

用户权限一般分为功能权限和数据权限。

3.2性能需求

3.2.1用户权限需求

1.功能权限：

用户功能权限一般采用经典的RBAC（Role Based Access Control）方式进行控制，RBAC的核心就是通过角色来控制用户权限，也就是用户通过角色和权限产生关联，再去控制用户的操作。

2.数据权限

用户的数据权限需要新建模型去控制，通过数据范围的模型去控制，核心是通过数据范围来控制数据权限，先定义好在哪些维度上进行数据权限的控制，数据范围有各个维度数据的数据集，根据这个数据集去控制用户的数据的访问范围。

3.3属性

3.3.1 可用性

（1）任何用户都对应一个或多个角色，一个角色对应一个或多个权限，每个用户可以有相同或者不同的权限。

（2）经RBAC的核心是用户只和角色关联，而角色代表对了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承。

（3）在一个系统中，如果用户组的许可权和成员仅可以被系统安全员修改的话，在这种机制下，用户组的机制是非常接近于角色的概念的。角色也可以在用户组的基础上实现，这有利于保持原有系统中的控制关系。在这种情况下，角色相当于一个策略部件，与用户组的授权及责任关系相联系，而用户组是实现角色的机制，因此，两者之间是策略与实现机制之间的关系。

3.3.2安全性

（1）用户权限

 安全性较好，用户、权限和角色三者紧密联系。 

（2）数据备份，使用Mysql数据库，可进行系统信息备份，允许恢复误删的重要数据。

4. 验收验证标准