权限控制和OAuth

目录

1 权限控制是什么

　　1.1 ACL

　　1.2 RBAC

　　　　1.2.1 名词术语

　　　　1.2.2 RBAC定义

　　　　1.2.3 RBAC分类

　　　　　　1.2.3.1 RBAC0

　　　　　　1.2.3.2 RBAC1

　　　　　　1.2.3.3 RBAC2

　　　　1.2.4 RBAC 接口

2 垂直权限（功能权限）

3 水平权限（数据权限）

4 OAuth

　　4.1 受权码模式（authorization code）

　　4.2 简化模式（implicit）

　　4.3 密码模式（resource owner password credentials）

　　4.4 客户端模式（client credentials）

5 参考

 

权限其实是一种能力，对权限的合理分配，一直是安全设计中的核心问题。本文主要讲了权限控制是什么，有哪些成熟的模型可学习参考。简单了解一下~

1 权限控制是什么

认证（Authentication）和 受权（Authorization）是两个概念：

• 认证的目的是为了认出用户是谁，解决的是『Who am I』的问题；

• 而受权的目的是为了决定用户可以作什么，解决的是『What can I do』的问题。

形象的来讲：假设系统是一个屋子，持有钥匙的人能够开门进入屋子。那么屋子就是经过锁和钥匙来进行『认证』的，开门的过程对应的就是登录。开门以后，能访问哪一个屋子，什么事情能作，什么事情不能作，就是『受权』的管辖范围了。

某个主体（subject）对某个客体（object）须要实施某种操做（operation），系统对这种操做的限制就是权限控制。在一个安全的系统中，经过认证来确认主体的身份。客体是一种资源，是主体发起请求的对象。主体所能作什么，就是权限，权限能够细分为不一样的能力，例如：在Linux文件系统中，将权限分为 读、写、执行 三种能力。"基于角色的访问控制"和"基于数据的访问控制"是进行系统安全设计时常常用到的两种控制方式，下文会涉及到。

如下是一些常见的权限控制模型： 

 

1.1 ACL

ACL(Access Control List) 控制访问列表。在ACL中，包含用户(User)、资源(Resource)、资源操做(Operation)三个关键要素。每一项资源，都配有一个列表，记录哪些用户能够对这项资源执行哪些操做。当系统试图访问这项资源时，会检查这个列表中是否有关于当前用户的操做权限。

总的来讲，ACL是面向"资源"的访问控制模型，机制是围绕"资源"展开的。模型以下图所示：

 

ACL典型的例子：

在 Linux 中，主体是系统用户，客体是被访问的文件，一个文件所能执行的操做分为读(r)、写(w)、执行(x)，这三种操做同时对应着三种主体：文件拥有者、文件拥有者所在的用户组、其余用户。主体-客体-操做这三种的对应关系构成了 ACL 控制访问列表，当用户访问文件时，可否成功将由 ACL 决定。 

 

1.2 RBAC

1.2.1 名词术语

用户（user）：人、机器、网络等，进行资源或服务访问的实施主体

角色（role）：一个工做职能，被授予角色的用户将具备相应的权威和责任

会话（session）：从用户到其激活的角色集合的一个映射

权限（permission）：对受RBAC保护的一个或多个对象执行某个操做的许可

操做（operation）：一个程序可执行的映像，被调用时为用户执行某些功能

客体（object）：须要进行访问控制的系统资源，例如：文件、打印机、数据库记录等 

 

1.2.2 RBAC定义

RBAC(Role-Based Access Control)：基于角色的访问控制。 RBAC认为受权实际就是 who，what，how 三者之间的关系，即 who 对 what 进行 how 的操做。

• Who：权限的拥用者或主体（如 User、Group、Role 等等）

• What：权限针对的对象或资源

• How：具体的权限

RBAC的关注点在于 Role 和 User, Permission 的关系。称为 User assignment(UA) 和 Permission assignment(PA)。关系的左右两边都是 Many-to-Many 关系。就是 user 能够有多个 role，role 能够包括多个 user。User 经过成为 Role 而获得这些 Role 的 Permission，Role 隔离了 User 和 Permission 的逻辑关系。

RBAC支持三个著名的安全原则：

• 最小权限原则：要求系统只授予主体必要的权限，而不要过分受权，这样能有效减小系统、网络、应用、数据库出错的机会。RBAC能够将其角色配置成其完成任务所须要的最小的权限集

• 责任分离原则：调用相互独立互斥的角色来共同完成敏感的任务。例如：记帐员和财务管理员共同参与同一过帐

• 数据抽象原则：权限的抽象。如：财务操做用借款、存款等抽象权限，而不用操做系统提供的典型的读、写、执行权限。 

 

1.2.3 RBAC分类

1.2.3.1 RBAC0

RBAC0：RBAC的核心部分，是通用的权限模型，其余的版本都是创建在 RBAC0 的基础上并进行相应的扩展。 模型图以下：

use和role关系：N:N

role和permission关系：N:N

在用户的会话中保持激活状态的角色的权限构成了用户的可用权限

 

1.2.3.2 RBAC1

RBAC1：基于 RBAC0 的角色层次模型，角色层次定义了角色间的继承关系，例如：角色 r1 继承了角色 r2，r1 则拥有了 r2 的全部权限。模型图以下： 

使用第一种模型也能够，不过会存在数据冗余，没有RBAC1更面向对象 

 

1.2.3.3 RBAC2

RBAC2：基于 RBAC0 的约束模型，增长了职级分离关系，用来实施利益冲突策略防止组织中用户的越权行为，限制了用户的权限。包含SSD（静态职级分离）和DSD（动态职级分离）概念。

SSD：用户/角色分配约束，由2个参数定义 ：

• 包含2或2个以上角色的角色集合

• 用户拥有的角色在该角色集中小于某个阀值

DSD：会话与角色之间的约束，约束一个用户会话能够激活的角色来限制用户的权限。例如：一个用户拥有3个角色，一个会话中只激活1个角色。模型图以下

 

 

1.2.4 RBAC 接口

RBAC接口定义规范，可参考：GBT 25062-2010 信息安全技术 鉴别与受权 基于角色的访问控制模型与管理规范

 

2 垂直权限（功能权限）

访问控制是创建用户与权限之间的关系，目前经常使用的一种方法就是基于 RBAC 模型，咱们可称之为『垂直权限』。例如：在一个论坛中，有admin、普通用户、匿名用户三种角色，admin有删除、编辑、置顶帖子的权限，普通用户有评论和浏览帖子的权限，匿名用户只有浏览帖子的权限。目前已有 Shiro，Spring Security 等基于 RBAC 模型的成熟框架来处理功能权限管理和鉴权的问题。

垂直权限的漏洞举例：Web应用程序在服务端没有作权限控制，只是在前端菜单显示上将部分页面隐藏了。此时，恶意用户能够猜想其余管理页面的 URL，就能够访问或控制其余角色拥有的数据或页面，达到越权操做的目的，可能会使得普通用户拥有了管理员的权限。

解决：对管理员所见的管理界面 URL，每次用户访问时，都要断定该用户是否有访问此 URL 的权限。推荐使用成熟的权限解决方案框架。 

 

3 水平权限（数据权限）

用户A和用户B可能同属于一个角色 RoleX，但用户 A 和用户 B 都各自有一些私有数据，正常状况下，用户本身只能访问本身的私有数据，例如：你有删除邮件的功能（操做权限），但只能删除本身的邮件，不能误删其余人的邮件（数据权限）。但在 RBAC 模型下，系统只会验证用户A是否属于角色 RoleX，而不会判断用户A是否能访问只属于用户B的数据 DataB，此时就可能发生越权访问。

这种问题，称之为『水平权限管理问题』，又能够称之为『基于数据的访问控制』：相比垂直权限管理来讲，水平权限问题出如今同一个角色上，系统只验证了能访问数据的角色，没有对数据的子集作细分，所以缺少了一个用户到数据级之间的对应关系。对于数据的访问控制，与业务结合的比较紧密，目前尚未统一的数据级权限管理框架，通常是具体问题具体解决。

数据权限就是控制访问数据的可见范围，表现形式是：当某用户有操做权限时候，不表明对全部数据都有查看或管理的权限。通常表现为行权限和列权限：

1. 行权限：限制用户对某些行的访问，例如：只能对某人、某部门的数据进行访问；也能够是根据数据的范围进行限制，例如：按合同额大小限制用户对数据的访问

2. 列权限：限制用户对某些列的访问，例如：某些内容的摘要能够被查阅，但详细内容只有 VIP 用户能查阅

水平权限的漏洞案例：Web应用程序接受用户的请求，修改某条数据id（资源的惟一编号）时，而没有判断当前用户是否能够访问该条记录，致使恶意用户能够修改本不属于本身的数据。例如：`/api/v1/blog?blogId=xxx [DELETE]` 这是删除博客内容的url，当用户改变 blogId 时，后端若是未校验博客的所属人是不是当前用户，则能够删除其余人的博客内容。

解决方案：用户作出相应动做时（新建、删除、更新等）时，须要对其会话身份进行验证（可采用Cookie机制），而且对用户访问的对象记录校验数据权限是否ok（按业务场景）。

 

4 OAuth

OAuth 是一个在不提供用户名和密码的状况下，受权第三方应用访问 Web 资源的安全协议。例如一个 OAuth 场景：用户将照片存储在Google，而后在"云冲印"的网站，将照片冲印出来。那么，"云冲印"网站须要得到用户的受权来读取Google上的用户照片。

OAuth 的一些名词：

• Third-party application：第三方应用程序，又称 "Client" 客户端，上例中的"云冲印"网站

• HTTP Service：HTTP服务提供商，上例中的Google

• Resource Owner：资源全部者，就是用户

• User Agent：用户代理，就是浏览器

• Authorization server：认证服务器，即服务商提供商专门处理认证的服务器

• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器

OAuth 的受权流程：

A：用户打开第三方应用程序 Client，Client 要求用户给与受权

B：用户赞成给予 Client 受权

C：Client 使用 B 步骤中得到的受权，向认证服务器申请令牌

D：认证服务器对 Client 进行认证以后，确认无误，赞成发放令牌

E：Client 使用令牌，向资源服务器申请获取资源

F：资源服务器确认令牌无误以后，赞成向 Client 开放资源

对于 B 步骤中的用户给 Client 第三方程序受权，OAuth2.0 定义了如下四种受权模式：

 

4.1 受权码模式（authorization code）

受权码模式是功能最完整、流程最严密的受权模式，它的特色是经过 Client 的后台服务器，与服务提供商的认证服务器进行交互

将每一步骤与所需的参数用时序图表示以下：

其中A.3中的scope是申请用户受权的权限范围，会向用户显示一个可受权列表，例如：获取用户信息、相册列表、点赞等资源，例以下图所示：

 

实例可参考：微信公众平台技术文档-微信网页受权

QQ互联-使用Authorization_Code获取Access_Token 

 

4.2 简化模式（implicit）

简化模式不经过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了受权码的步骤。全部步骤都在浏览器中完成，令牌对访问者是可见的，且 Client 不须要认证

将每一步骤与所需的参数用时序图表示以下：

实例可参考：QQ互联-使用Implicit_Grant方式获取Access_Token

 

4.3 密码模式（resource owner password credentials）

密码模式中，用户向 Client 提供本身的用户名和密码，Client 使用这些信息，向服务提供商索要权限。这种模式中，用户须要将本身的密码提供给 Client，但 Client 处不得存储密码，这一般用于用户对 Client 高度信任的状况下，例如：Client 是操做系统的一部分或一个著名公司。而认证服务器只有在其余受权模式没法执行状况下，才会采用这种模式。

将每一步骤与所需的参数用时序图表示以下：

 

4.4 客户端模式（client credentials）

客户端模式，指 Client 以本身的名义，而不是以用户的名义，向服务提供商进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向 Client 注册，Client 以本身的名义要求服务提供商提供服务，其实不存在用户的受权问题。

将每一步骤与所需的参数用时序图表示以下：

实例可参考：微信公众平台技术文档-获取access token （微信公众号的API接口调用，与用户受权无关）

 

5 参考

《白帽子讲Web安全》

理解OAuth2.0

https://github.com/casbin/casbin