只要有用户参与的系统通常都要有权限管理,权限管理实现对用户访问系统的控制,按照安全规则或者安全策略控制用户能够访问并且只能访问本身被受权的资源。java
权限管理包括用户认证和受权两部分。安全
用户认证,用户去访问系统,系统要验证用户身份的合法性。最经常使用的用户身份验证的方法:一、用户名密码方式、二、指纹打卡机、三、基于证书验证方法。。系统验证用户身份合法,用户方可访问系统的资源。htm
subject:主体,理解为用户,多是程序,都要去访问系统的资源,系统须要对subject进行身份认证。对象
principal:身份信息,一般是惟一的,一个主体还有多个身份信息,可是都有一个主身份信息(primary principal)ip
credential:凭证信息,能够是密码 、证书、指纹。ci
总结:主体在进行身份认证时须要提供身份信息和凭证信息资源
用户受权,简单理解为访问控制,在用户认证经过后,系统对用户访问资源进行控制,用户具备资源的访问权限方可访问。开发
受权的过程理解为:who对what(which)进行how操做。get
who:主体即subject,subject在认证经过后系统进行访问控制。权限控制
what(which):资源(Resource),subject必须具有资源的访问权限才可访问该 资源。资源好比:系统用户列表页面、商品修改菜单、商品id为001的商品信息。
资源分为资源类型和资源实例:
系统的用户信息就是资源类型,至关于java类。
系统中id为001的用户就是资源实例,至关于new的java对象。
how:权限/许可(permission) ,针对资源的权限或许可,subject具备permission访问资源,如何访问/操做须要定义permission,权限好比:用户添加、用户修改、商品删除。
主体(帐号、密码)
资源(资源名称、访问地址)
权限(权限名称、资源id)
角色(角色名称)
角色和权限关系(角色id、权限id)
主体和角色关系(主体id、角色id)
一般企业开发中将资源和权限表合并为一张权限表,以下:
资源(资源名称、访问地址)
权限(权限名称、资源id)
合并为:
权限(权限名称、资源名称、资源访问地址)
上图常被称为权限管理的通用模型,不过企业在开发中根据系统自身的特色还会对上图进行修改,可是用户、角色、权限、用户角色关系、角色权限关系是须要去理解的。
RBAC(role based access control),基于角色的访问控制。
好比:
系统角色包括 :部门经理、总经理。。(角色针对用户来划分)
系统代码中实现:
//若是该user是部门经理则能够访问if中的代码
if(user.hasRole('部门经理')){
//系统资源内容
//用户报表查看
}
问题:
角色针对人划分的,人做为用户在系统中属于活动内容,若是该 角色能够访问的资源出现变动,须要修改你的代码了,好比:须要变动为部门经理和总经理均可以进行用户报表查看,代码改成:
if(user.hasRole('部门经理') || user.hasRole('总经理') ){
//系统资源内容
//用户报表查看
}
基于角色的访问控制是不利于系统维护(可扩展性不强)。
RBAC(Resource based access control),基于资源的访问控制。
资源在系统中是不变的,好比资源有:类中的方法,页面中的按钮。
对资源的访问须要具备permission权限,代码能够写为:
if(user.hasPermission ('用户报表查看(权限标识符)')){
//系统资源内容
//用户报表查看
}
上边的方法就能够解决用户角色变动不用修改上边权限控制的代码。
若是须要变动权限只须要在分配权限模块去操做,给部门经理或总经理增或删除权限。
建议使用基于资源的访问控制实现权限管理。