权限控制和OAuth
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,此时就可能发生越权访问。
这种问题,称之为『水平权限管理问题』,又可以称之为『基于数据的访问控制』:相比垂直权限管理来说,水平权限问题出现在同一个角色上,系统只验证了能访问数据的角色,没有对数据的子集做细分,因此缺乏了一个用户到数据级之间的对应关系。对于数据的访问控制,与业务结合的比较紧密,目前还没有统一的数据级权限管理框架,一般是具体问题具体解决。
数据权限就是控制访问数据的可见范围,表现形式是:当某用户有操作权限时候,不代表对所有数据都有查看或管理的权限。一般表现为行权限和列权限:
行权限:限制用户对某些行的访问,例如:只能对某人、某部门的数据进行访问;也可以是根据数据的范围进行限制,例如:按合同额大小限制用户对数据的访问
列权限:限制用户对某些列的访问,例如:某些内容的摘要可以被查阅,但详细内容只有 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 参考
权限控制和OAuth的更多相关文章
- aProxy: 带认证授权和权限控制的反向代理
前段时间很多数据库因为没有做好权限控制暴露在外网被删然后遭勒索的事件,而类似的有些内网的web服务也会被开放到公网并且没有做任何权限控制的,这样也会有一定的风险.所以就决定写篇文章简单介绍一个小工具. ...
- 认证鉴权与API权限控制在微服务架构中的设计与实现(四)
引言: 本文系<认证鉴权与API权限控制在微服务架构中的设计与实现>系列的完结篇,前面三篇已经将认证鉴权与API权限控制的流程和主要细节讲解完.本文比较长,对这个系列进行收尾,主要内容包括 ...
- OAuth2.0 原理流程及其单点登录和权限控制
2018年07月26日 07:21:58 kefeng-wang 阅读数:5468更多 所属专栏: Java微服务构架 版权声明:[自由转载-非商用-非衍生-保持署名]-转载请标明作者和出处. h ...
- 单点登录(十八)----cas4.2.x客户端增加权限控制shiro
我们在上面章节已经完成了cas4.2.x登录启用mongodb的验证方式. 单点登录(十三)-----实战-----cas4.2.X登录启用mongodb验证方式完整流程 也完成了获取管理员身份属性 ...
- Spring cloud微服务安全实战-6-4权限控制改造
授权,权限的控制 令牌里的scope包含fly就有权限访问.根据Oauth的scope来做权限控制, 要让@PreAuthorize生效,就要在启动类里面写一个注解. 里面有一个属性叫做,就是在方法的 ...
- Spring Cloud Data Flow整合Cloudfoundry UAA服务做权限控制
我最新最全的文章都在南瓜慢说 www.pkslow.com,欢迎大家来喝茶! 1 前言 关于Spring Cloud Data Flow这里不多介绍,有兴趣可以看下面的文章.本文主要介绍如何整合Dat ...
- Nacos 权限控制介绍及实战
方案背景 Nacos自开源依赖,权限控制一直需求比较强烈,这也反应了用户需求将Nacos部署到生产环境的需求.最新发布的Nacos 1.2.0版本已经支持了服务发现和配置管理的权限控制,保障用户安全上 ...
- Spring Security实现统一登录与权限控制
1 项目介绍 最开始是一个单体应用,所有功能模块都写在一个项目里,后来觉得项目越来越大,于是决定把一些功能拆分出去,形成一个一个独立的微服务,于是就有个问题了,登录.退出.权限控制这些东西怎么办呢? ...
- 尝试asp.net mvc 基于controller action 方式权限控制方案可行性
微软在推出mvc框架不久,短短几年里,版本更新之快,真是大快人心,微软在这种优秀的框架上做了大量的精力投入,是值得赞同的,毕竟程序员驾驭在这种框架上,能够强力的精化代码,代码层次也更加优雅,扩展较为方 ...
随机推荐
- c++中段自评
不知不觉,学期已过一大半.也是时候对自己的编程水平重新进行一次评估了. 1.通过最近的中段测试和acm新手赛的洗礼,以及之前的课前预习.课中学习.和课后作业的锻炼,我逐渐体会到编程语言的魅力同时也理解 ...
- c# 将object尝试转为指定对象
主方法: /// <summary> /// 将object尝试转为指定对象 /// </summary> /// <param name="data" ...
- beego笔记
beego学习笔记一:创建第一个beego Web项目 Go语言beego框架快速搭建体验五分钟讲解01 beego框架图文简介五分钟讲解02 beego框架图文简介五分钟讲解03-go语言简单方式操 ...
- logback配置文件
logback-spring.xml 通用配置文件如下: <?xml version="1.0" encoding="UTF-8"?> <co ...
- java中的接口与继承,接口的例子讲解
extends 继承类:implements 实现接口. 简单说: 1.extends是继承父类,只要那个类不是声明为final或者那个类定义为abstract的就能继承, 2.JAVA中不支持多重继 ...
- 再谈docker基本命令
子曰,温故而知新 今日,再次看书之际,又寻得docker的几条使用命令,用小本本记下来 配置docker镜像源 当我们在拉去一些共有镜像时,默认,docker会向docker.io去获取,如果在拉取的 ...
- [swarthmore cs75] Lab 1 — OCaml Tree Programming
课程回顾 Swarthmore学院16年开的编译系统课,总共10次大作业.本随笔记录了相关的课堂笔记以及第2大次作业. 比较两个lists的逻辑: let rec cmp l ll = match ( ...
- U-Boot Makefile分析(5)主控Makefile分析
这次分析源码根目录下的Makefile,它负责读入配置过的信息,通过OBJS.LIBS等变量设置能够参与镜像链接的目标文件,设定编译的目标等等. HOSTARCH := $(shell uname - ...
- 如何让 Git 使用 HTTP 代理服务器
因为我们的内部网络使用了代理,所以在 安装 OpenStack 基于 Web 的管理控制台 的时候有个小麻烦,我们的 http 代理服务器无法通过 git 协议下载 openstack-dashboa ...
- 升讯威微信营销系统开发实践:(2)中控服务器的详细设计( 完整开源于 Github)
GitHub:https://github.com/iccb1013/Sheng.WeixinConstruction因为个人精力时间有限,不会再对现有代码进行更新维护,不过微信接口比较稳定,经测试至 ...