escout

代码、心情

常用链接

统计

SOA相关

我参与的团队

最新评论

基于RBAC的权限模型

权限模型

把权限模型划分为页面访问控制权限和数据权限 ( 商业逻辑权限 ) 。其中,页面访问控制权限主要在于控制页面是否可以被访问,比如,管理员可以访问权限设置页面。数据权限主要是指是否有操作某个数据的权限,比如说组织机构中的部分问题,一个部门应该只看到本部门的数据,这就是数据权限,这个应该在业务逻辑中控制,而不是页面中。

本权限模型专注于页面访问控制,不涉及数据操作权限。使用用户、角色、资源和操作来控制实际的页面访问。同时,区别于一般的页面权限模型,本模型采用细粒度的权限控制,可以控制到页面的具体操作,很不是整个页面不加区分。所以,这样就可以在一个页面放置多个操作,方便于用户,同时又不失安全性。

考虑到权限在实际中很少变动,使用数据库的冗余设计,还有数据缓存等来提高效率。

 

用户: User

       Id name

用户角色表( 1 对多):

       Id userID roleID

角色 : Role

       Id name description defaultPage (系统初始化时,使用的登陆页?)

权限 (Role-Resource-Operation) Authority

       Id role resource resourceURL (为效率考虑采用的冗余,等同 Resource 中的 url ,在实际验证中将使用该 url 来验证)、 operationID operationName (为效率考虑,采用冗余,等同 Operation 中的 name ,实际验证中使用该操作名称来做验证)

资源: Resource

       Id name description url

操作: Operation

       Id name( 一般应改为英文,对应方法的名字 ) description

 

BaseAction 中应该有一个 getMethodAuthMap (),得到方法和可用操作的映射。如果映射中找不到,则直接使用该方法名当作操作名称。如果方法映射找到了,但是为空,这意味着该方法对于任何用户都是可以访问的,不要求验证。子类可以继承和覆盖该方法,来实现特殊的权限逻辑。

 

权限操作应该允许复制已有的权限来生成新的权限。

在前端控制器中设置已有的对于某个资源的操作,放到 hashtable 中,比如 auth 。对于页面,使用表达式语言 EL 来限制实际的逻辑,比如如下要求对于当前页面要有 delete 权限:

       <c:if test=”auth.delete”>

       </c:if>

同时,在整体页面中,使用 struts dispathAction 来做分发, url 形如 url?method=delete 在执行该方法之前,首先检查当前页面的这个权限 delete ,如果可以,则导向到正确的页面,否则导向到 accessDenied.do 页面(注意,该页面比较特殊,对于任何用户都应该是可以访问的,也就是前面的 getMethodAuthMap 返回为 NULL

 

posted on 2006-04-30 17:27 绿色使者、绿色心情 阅读(914) 评论(0)  编辑  收藏 所属分类: java 安全


只有注册用户登录后才能发表评论。


网站导航: