【转】我理解的权限管理设计二

         任何一个系统最基础的莫非资源、用户、权限之前的管理，无论做什么样的产品都需要权限系统来支撑，只是对于不同的权限系统需要不同级别的权限管理底层进行支撑。

 

        首先明确一下权限管理系统的概念；权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。权限管理几乎出现在任何系统里面，只要有用户和密码的系统。目前可以归纳为简单的模型，如下图：

 

权限管理主要分为两大类：

一、资源管理认证

1、功能级的权限验证逻辑非常简单。查看该当前登录用户的角色是否包含该功能的权限。如果有，则表示有权访问，否则表示无权访问。对于WEB系统，一般定义一个Filter就可以完成权限验证，无需在各个程序入口进行权限判断。程序伪代码如下：

// 获取访问功能

String url=request.getRequestPath();
// 进行权限验证
User user=request.getSession().get(“user”);
boolean permit=PrivilegeManager.permit( user, url );
if( permit ) {
chain.doFilter( request, response );
} else {
// 可以转到提示界面
}

2、页面内嵌业务相关

功能级别的只能使用页面的是否能够正确的访问不能直接代表，如果对于一个比较复杂系统，涉及到的问题可以是一个用户他只有查询的功能，没有业务操作的权限，这样对于我们上述的简单权限认证明显会感觉力不从心可以对前台按钮级别的显示进行效果的封装，在现实的时候进行按钮是否显示的判断，这样也就直接屏蔽了按钮级别的权限任务操作

二、数据权限认证

　目前，数据级权限管理领域，一直没有统一的技术。大体上，软件开发人员采用如下技术：
1，硬编码，也就是将这种逻辑以if/else等形式与业务代码耦合在一起，这种情况居多；
2，使用规则引擎，也有一些企业将这种逻辑以规则形式提出来，并使用规则引擎解析规则；
3，使用第三方专业软件，有开源中间件Ralasafe；开源框架Spring Security；商业产品Oracle Entitlements Server，IBM Tivoli Access Manager。
硬编码形式弊端是非常显然的。耦合性强，难以测试；系统组件复用率低；系统后期改动代价非常大，牵一发而动全身。
使用规则引擎可以解决很多问题，学习难度尚可。但规则引擎并不是专业用于权限管理的，所以对于复杂一些的权限管理，就显得力不从心。
Ralasafe和Oracle、IBM的商业产品一样，都是中间件形式。对应用系统和应用数据库结构没有要求。都有管理界面进行直接操控管理，而且都能在线进行测试。相比较，Ralasafe还可以控制查询权限（即从系统查询订单、查询客户等），Oracle、IBM的商业产品没有这方面功能；从产品学习难度来看，Ralasafe只要有一些IT经验，就能快速上手；Oracle、IBM产品即使是专业人员，也难以掌握。
Spring Security是框架，需要对你的应用系统进行改动，你的系统必须在该框架进行设计编写。它只是帮助开发人员将权限提取出来了，但数据级权限还需要开发人员开发Voter。而且配置工作巨大，难以测试。
虽然上述提到的产品，都是Java产品。但Ralasfe和Oracle、IBM的商业产品，以中间件形式，可以部署在独立服务器上，使用web service等方式与非Java系统交互。

 

转自：http://blog.daniushow.com/?p=78