锁定老帖子 主题:Spring Security优劣之我见
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-04-09
daquan198163 写道 那个role就是角色了。 实现的方法: 1、实现UserDetailsService的public UserDetails loadUserByUsername(String username) 从数据库取用户资料,返回的这个UserDetails 包括用户名、密码、状态还有该用户关联的角色。 2、实现FilterInvocationDefinitionSource的public ConfigAttributeDefinition getAttributes(Object obj),此方法根据请求的URL从数据库找到对应的资源及该资源关联的角色。 3、当然,前提是你的数据库里有这些表:user、role、resource、user_role、role_resource 剩下的事情就由SpringSecurity来计算了,比如投票决定某人是否可以访问某url、调用某方法 讨论的role是基于这个问题的。 引用 角色被“编码”到配置文件和源文件,这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中,客户可能并不能确定有哪些角色,以及角色怎么分配给系统用户。角色大多需要等到系统上线后,才能确定。这些编码有: |
|
返回顶楼 | |
发表时间:2009-04-09
daquan198163同学说的是对的。
Spring Security的模型非常简单,只是通过5张表来建立访问关系。User、Role、Resource和他们互相之间的关联表。所以用户自定义角色,也只是在这5张表的数据中做文章。比如说,你要新建一个用户,只是往User表中添加记录;新建一个角色,只是往Role里面添加一条记录;新建一种访问资源,在Resource表中添加记录。并且在互相之间的关联表中指明用户的角色和资源访问关系。 Spring Security对于所有未列在配置中的URL,默认也会走所有的Filter链,所以完全不必在配置文件中对URL与角色的关系做一一指定,你甚至可以在runtime的时候指定上面提到的5张表的关系。这样就可以做到用户自定义角色和资源访问权限了。 至于说到数据访问权限,我的经验还不够丰富,在我看来很难建立一套成熟而松耦合的机制,所以我对楼主所谓不需要写一行代码就能完成数据访问权限非常好奇,楼主可以另开一贴向大家交流一下。 |
|
返回顶楼 | |
发表时间:2009-04-09
我博客里面有演示:
http://metadmin.iteye.com/blog/359533 |
|
返回顶楼 | |
发表时间:2009-04-09
还行我挺喜欢这个的 可复用的东西就是那么麻烦 习惯了~
|
|
返回顶楼 | |
发表时间:2009-04-09
个人一点看法:
ROLE应该粗粒度的控制,通常是平行的,不适合做细粒度的控制. 权限集合通常是树形的,一个大集合里面包括小集合,甚至一个大集合里面的两个小集合部分重叠。大集合包括基本权限,小集合包括特殊权限,把某个用户置于一个圈子里,那他应具有所有包含他的圈子的权限。 ROLE_1,ROLE_2,ROLE_1_2,ROLE_2_3表示起来不直观,不好管理。所以Spring Security(SS)做完所有事情是不可能的。而SS却能很好的和WEB容器和Bean容器打交到,而且也很完善,所以自己开发一套系统不借助SS,也是耗费很大的,而且不一定没漏洞。 折中的办法是两者结合。成型的权限系统很少是纯SS的,通常SS管大方向和容器打交道,另外一套可以方便嵌入到SS的权限系统。 ACL模型基于这种“圈子”结构可以简化信息量,当然“圈子”的管理工具要做到足够好。 ACL模型最突出的矛盾是ACL信息的粒度和系统能提供的信息容量和通道的矛盾,大粒度的ACL可以将一个圈子里的人设置位是否具有某个权限。但现实情况是企业人员是不断变动的,而且权限也是不断变化的,权限回收和授予的矛盾就成了主要矛盾。 一个权限控制的物件被控制得越精细,需要的数据流量就越大,权限的回收和授予造成的瓶颈就越大。单一数据库或者LDAP的解决方式越来越难满足了,将来的发展方向应该放在云计算、MapReduce、分布式存储。 所以我觉得难点应该在权限的管理和权限可以被怎么存取。 |
|
返回顶楼 | |
发表时间:2009-04-09
最后修改:2009-04-09
我个人认为Spring Security存在以下几个硬伤:
1. 角色被“编码”到配置文件和源文件,这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中,客户可能并不能确定有哪些角色,以及角色怎么分配给系统用户。角色大多需要等到系统上线后,才能确定。这些编码有: a) url的权限控制,<intercept-url pattern="/**" access="ROLE_USER" />; b) java方法的权限控制,@Secured("IS_AUTHENTICATED_ANONYMOUSLY"); c) java方法的权限控制,<protect method="set*" access="ROLE_ADMIN" />; 从Acegi时代就支持了, 主要是重新实现下FilterInvocationDefinitionSource这个类. 参考SpringSide http://www.springside.org.cn/docs/reference/Acegi4.htm 2. RBCA这种被广泛运用的模型,没有在Spring Security体现出来; Spring Security支持RBCA, Spring Security sample里是users和authorities两层权限控制, 再加一层role或二层没什么本质区别. 以前做过一个系统权限控制比较麻烦,分了user,role,permission,resource四层. 3. Spring Security没有提供好的细粒度(数据级)权限方案,提供的缺省实现维护工作量大,在大数据量情况下,几乎不可用; 数据级权限控制,觉得LZ提的可能是ACL(Access Control Lists) Based Security. ACL和RBAC这两种安全控制模型差异很大,这个貌似Spring Security不支持的吧? 有了解的童鞋可以跟贴解释下 http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsACLBasedSecurity.html |
|
返回顶楼 | |
发表时间:2009-04-09
最后修改:2009-04-09
手一抖 提交了2次... 字数字数字数
|
|
返回顶楼 | |
发表时间:2009-04-09
-_-很好奇 Spring Security的ACL真的有人用在大数据量的企业应用当中吗?
一直感觉那只是一个玩具,思想上来看没啥问题,但是牵涉到具体的应用当中根本玩不转。 |
|
返回顶楼 | |
发表时间:2009-04-10
metadmin 写道 我博客里面有演示:
http://metadmin.iteye.com/blog/359533 我简单看了一下,你的数据权限那块,我没有能够看到相应的代码,和step by step的操作,我想知道如何应用到具体的项目中去。 |
|
返回顶楼 | |
发表时间:2009-04-10
看了半天,虽然知道lz在说什么,但是没什么学习资料,学起来不容易啊!
|
|
返回顶楼 | |