系统权限控制体系

本文探讨了系统权限控制的本质,包括访问控制的两个主要任务。介绍了DAC、MAC、IBAC、RBAC和ABAC等理论模型,以及在Java中如Spring Security、Apache Shiro等常用框架。同时,概述了权限系统从JAAS到分布式SSO和统一登录的演变历史。

在 Web 应用开发中,安全一直是非常重要的一个方面。安全虽然属于应用的非功能性需求,但是应该在应用开发的初期就考虑进来。比如我们开放的功能页面需要登录授权之后才能访问,一些功能需要具备特定权限的人才能操作;再比如我们开放了数据API接口,如果不做访问控制,那么任何人都可以调用,当被不法分子操作时将给我们带来巨大的麻烦。那么在Java 整个体系中访问控制是否有一套理论技术支撑呢,我们是否可以做一个通用性的访问控制系统来完成分布式系统架构下的复杂的权限控制?接下来会一一介绍。

访问控制的本质:

系统权限控制 本质上是访问控制(Access Control),那访问控制的本质又是什么呢?其实就是合法的访问受保护的资源,通俗的解释就是“【谁】是否有可以对某个【资源】进行某种【操作】”;可以看出访问控制的三个基本要素:主体(请求实体)、客体(资源实体)、控制策略(属性集合);

访问控制需要完成的两个任务:

识别和确认访问系统的用户;
决定该用户可以对某一系统资源进行何种类型的访问;

访问控制理论模型:

示意图:

基于RBAC权限模型的常见数据库模型设计:

设计的核心主题: 用户、权限、角色、用户角色、角色权限、用户组、用户组角色、操作审计
阿里巴巴登录鉴权与审计的三驾马车:BUC、ACL、OpLog;

Java常用访问控制框架:

  • JAAS框架:
    • Authentication(鉴别), Authorization(授权),Accounting(计费);
    • Java认证和授权服务(Java Authentication and Authorization Service,简称JAAS)
    • 支持的框架:LDAP
    • 特点:面世时间早,使用受限,不建议使用;
  • Spring Security框架
  • Apache Shiro框架

权限系统的演变历史:

1: 标准的JAAS 时代;

J2ee时代,Java提出了标准的鉴权服务,即jaas;通过简单的容器配置和文件配置,通过一个LDAP(可以用数据库,只是效率不高),就可以提供一个极为高效便捷的权限管控服务。这个模式不仅支持页面管控,还支持ejb服务接口管控。其鉴权因为ldap的数倍于数据库的查询效率而无需任何缓存,速度很快。但是伴随着分布式服务化进程,应用的数量无限度增长,这种散落在各个容器的配置给容灾和修改,都带来了极大的挑战,ldap的可读化差,修改和编辑极为不便,当需求一旦个性化超过了树能够表达的模型便很难在适应。并且当ldap的数据爆炸式增长,且呈现28规律时(数据冷热不均),或者如果需要频繁的写ldap,查询效率会陡然下降。虽然这种方式目前并不流行的,但是由于历史原因,还存留着使用这种方式的管控方式,所以我们在Spring Security或者阿里的ACL中都还能看到对JAAS的支持。

2: 单点登录(SSO)+接口鉴权时代;

把分散在各个系统的登录认证服务统一到一个系统中来,统一管控登录授权业务,用户只要在一个系统中登录了,在其它系统中就没必要再次登录了,这就是SSO。简单的实现是登录授权系统部署在一台机器上,不涉登录系统的多机部署,此架构具有单点风险;任何具备高可用思维的架构师都不会允许此风险存在,原因有二:1. 统一登录中心后,SSO成为极为核心的应用,如果SSO系统挂了,那么需要登录的任何服务器都无法正常提供服务;2. 单台机器不具备抵抗登录风暴的能力; 所以SSO系统必须成为集群部署模式。其次,在访问控制模型上,也必须放弃JAAS方式,转而使用RBAC模型;

3: 统一登录(分布式SESSION) + 接口鉴权时代;

SSO系统集群部署后,面临的首要问题就是Session的共享问题,比如用户在sso-1 机器上登录了,下次访问sso-2机器时,也必须是登录态的。分布式Session使用较多的方案为:Session集中管理;比如阿里巴巴基于Tair 缓存体系的共享session体系tbsession。如果采用了session + cookie的方案,并且服务端集群是多域名共享登录的话,那么还需要提供cookie跨域同步的能力(解决cookie不能跨域的问题)。

OA权限管理分为: 人员管理 角色管理 模块管理 其实有这样一些概念: 主体:用户和角色可以称为主体。 资源:就是可以进行crud的对象。 权限:就是对资源的crud操作。 授权:就是对这种权限的分配。 认证:就是查询用户是否有权限。 用户和角色的关系是多对多,这共同组成了主体。 模块是资源。 主体和资源的纽带是ACL(访问控制列表),主体和ACL之间是多对多关系,资源和ACL之间也是多对多关系。ACL里面就记录了用户的权限。 在数据库上它就是一个中间表的作用。 授权是这样的: 授权分为两种: 角色授权 对角色统一授权,继承这种角色的用户就自动拥有该角色所拥有的权限,并且权限分有优先级,这样两种权限如果之间发生冲突则取高优级。 用户授权 对用户进行单独授权,这种情况必须在不继承角色的情况下才能生效,并且此时只使用单独授权的权限。 每一次授权都是针对特定模块,而不是所有。 搜索用户所有授权过程是这样的: 1、查询用户所有角色的权限,按优先给从低到高,有重复的可以以高优先级覆盖。(存入Map中,key是资源标识) 2、查询用户直接授予的权限。查询不继承的权限。 3、合并权限。 4、再从中选择具体的权限(crud)。 认证过程是这样的: 根据用户标识和资源标识查找ACL实例 有实例: 查看是否有确定授权 确定:返回授权 不确定(继承):查询用户拥有角色列表,根据角色标识和资源标识查找ACL实例(循环) 没有实例: 查询用户拥有角色列表,根据角色标识和资源标识查找ACL实例(循环)
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值