Spring Security优劣之我见

<!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning /> <w:DrawingGridVerticalSpacing>7.8 磅</w:DrawingGridVerticalSpacing> <w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery> <w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery> <w:Compatibility> <w:SpaceForUL /> <w:BalanceSingleByteDoubleByteWidth /> <w:DoNotLeaveBackslashAlone /> <w:ULTrailSpace /> <w:DoNotExpandShiftReturn /> <w:AdjustLineHeightInTable /> <w:BreakWrappedTables /> <w:SnapToGridInCell /> <w:WrapTextWithPunct /> <w:UseAsianBreakRules /> <w:UseFELayout /> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--> <!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:宋体; mso-ascii-font-family:"Times New Roman"; mso-hansi-font-family:"Times New Roman";} table.MsoTableGrid {mso-style-name:网格型; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; border:solid windowtext 1.0pt; mso-border-alt:solid windowtext .5pt; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-border-insideh:.5pt solid windowtext; mso-border-insidev:.5pt solid windowtext; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; mso-pagination:none; font-size:10.0pt; font-family:宋体; mso-ascii-font-family:"Times New Roman"; mso-hansi-font-family:"Times New Roman";} </style> <![endif]-->

Spring Security优劣之我见

 

拜读了Spring Security相关帖子和Spring Security参考文档。现将我理解的Spring Security写下来和大家共享。

 

本文目的是从Spring Security能够提供的功能、以及基本原理角度分析，并不深入到如何编码。然后反过来，审查我们的软件系统需要哪些权限控制。进而评审Spring Security的适用性。

 

本文力求文字简单，概念也简单。

--------------------------------------------------------------

文章大纲：

Spring Security 如何控制权限

    概要

    与WEB系统的集成
    控制内容
    细粒度权限控制
我们理想中的权限管理
    客户对权限管理的需求
    开发中遇到的难点
    我们理想的权限管理
Spring Security的评价
    优点
    缺点

--------------------------------------------------------------

Spring Security如何控制权限

概要

Spring使用由Filter组成的Chain，来判断权限。如下图所示：

<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter" /> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0" /> <v:f eqn="sum @0 1 0" /> <v:f eqn="sum 0 0 @1" /> <v:f eqn="prod @2 1 2" /> <v:f eqn="prod @3 21600 pixelWidth" /> <v:f eqn="prod @3 21600 pixelHeight" /> <v:f eqn="sum @0 0 1" /> <v:f eqn="prod @6 1 2" /> <v:f eqn="prod @7 21600 pixelWidth" /> <v:f eqn="sum @8 21600 0" /> <v:f eqn="prod @7 21600 pixelHeight" /> <v:f eqn="sum @10 21600 0" /> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" /> <o:lock v:ext="edit" aspectratio="t" /> </v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" style="width:414.75pt; height:174pt" mce_style="width:414.75pt; height:174pt"> <v:imagedata src="file:///C:\DOCUME~1\back\LOCALS~1\Temp\msohtml1\01\clip_image001.png" mce_src="file:///C:\DOCUME~1\back\LOCALS~1\Temp\msohtml1\01\clip_image001.png" o:title=""Ĥ" /> </v:shape><![endif]--><!--[if !vml]--><!--[endif]-->

Spring预定义了很多out-of-boxed filter供开发者直接使用。

每个Filter一般情况下（有些Filter是abstract的），都和配置文件的一个元素（有的情况下可能是属性）对应。

比如：AUTHENTICATION_PROCESSING_FILTER，对应配置文件里面的：http/form-login元素。

 

如果Spring提供的Filter不能满足系统的权限功能，开发者可以自定义Filter，然后把Filter放在某个Filter Chain的某个位置。可以替换掉原有Filter Chain的某个Filter，也可以放在某个Filter之前或者之后。

 

总之，Spring Security采用Filter Chain模式判断权限，Spring提供了一些Filter，也支持开发者自定义Filter。

与WEB系统的集成

使用Java EE的Filter（非Spring的Filter）机制，将需要权限判断的url，“牵引”给Spring的Filter Chain即可。

 

一般情况下，将所有的url都引入Filter Chain。当然也可以在web.xml配置需要权限判断的url（配置filter-mapping/url-pattern）。Spring的配置文件也支持过滤掉不需要权限判断的url（配置http/intercept-url元素）。

控制内容

Spring Security提供了如下内容的控制：

<!--[if !supportLists]-->1.       <!--[endif]-->url；

<!--[if !supportLists]-->2.       <!--[endif]-->bean method；

<!--[if !supportLists]-->3.       <!--[endif]-->http session。

 

url：可以分为需要权限判断的url，不需要权限判断的url，登录表单url。通过我对spring相关帖子和参考文档的阅读，需要权限判断的url。仅限于做角色判断，就是说判断当前用户是否具有指定的角色。

 

bean method：Spring支持对Service layer method做权限判断。通过我对spring相关帖子和参考文档的阅读，也仅限于做角色判断。配置方式有2种：

<!--[if !supportLists]-->1.       <!--[endif]-->写在Java源代码里面，如：@Secured("ROLE_TELLER")（该方法只有具有TELLER角色的用户能够访问，否则抛出异常）；

<!--[if !supportLists]-->2.       <!--[endif]-->写在配置文件里面，如：<protect method="set*" access="ROLE_ADMIN" />（该bean的所有set方法，只有具有ADMIN角色的用户能够访问，否则抛出异常）。

 

http session：控制一个用户名是否能重复登录，以及重复登录次数，并非重试密码次数。

 

另外，Spring Security还提供了如下一些功能：

<!--[if !supportLists]-->1.       <!--[endif]-->remember me，记住我；

<!--[if !supportLists]-->2.       <!--[endif]-->form-login登录控制；

<!--[if !supportLists]-->3.       <!--[endif]-->多种身份认证功能；

<!--[if !supportLists]-->4.       <!--[endif]-->用户密码加密和“salt”功能；

<!--[if !supportLists]-->5.       <!--[endif]-->http协议控制；

<!--[if !supportLists]-->6.       <!--[endif]-->访问端口控制；

<!--[if !supportLists]-->7.       <!--[endif]-->Pre-Invocation & After-Invocation。

 

remember me，记住我：还记得浏览器采用cookie记住用户名和密码自动登录吗？好像就是这个（不知道我理解错了没有，应该没有。只是我不大敢相信）。使用这个功能，开发者在登录页面，使用spring自定义的标签。

 

form-login登录控制：有些页面不允许匿名访问，那么当匿名访问这些页面的时候，将弹出（或者转到）form-login窗口（或者页面）。这里又牵引出2个问题：1，输入用户名和密码后怎样验证；2，密码是否需要加密，怎么加密。

 

多种身份认证功能：Spring提供了丰富的用户身份认证功能。身份认证是什么意思？比如您告诉我“我是神仙”。那么我会问您“凭什么证明您是神仙”。这就是身份认证。认证手段一般是保存到数据库表的用户名/密码，usb key，ldap等。一般情况下，我们都使用用户名/密码的。

 

用户密码加密和“salt”功能：密码采用md5，还是sha加密算法。如果我们对密码加密的时候，不想仅仅对密码加密，还想把用户名和密码放在一起加密做为加密后的密码。那么使用salt吧。salt支持也读取用户的其他属性，不仅是用户名。

 

http协议控制：哪些url，必须采用https访问呢？哪些url必须采用http访问呢？哪些又两者都可以呢？通过这个配置。

 

访问端口控制：类似http协议控制，控制url和访问端口之间的关系。

 

Pre-Invocation & After-Invocation：在方法调用之前做权限判断，还是方法调用之后做权限判断呢？一般情况下是之前调用。也有情况下是之后调用。具体例子可以看官方文档（22.3小节）。

细粒度权限控制

由上面分析，我们看到url、method的权限判断，都仅限于用户角色权限判断。事实上Spring使用投票（Voter）机制，来做权限判断。用户角色权限也是一种投票。

投票这个词，听起来不容易懂。举例：董事会开会，各个股东投票以表决决议是否通过。Spring的角色投票器，只会投出一票。我们平时所说的投票至少要2张票吧，一张还叫什么投票。Spring的投票有3种结果：允许、拒绝和弃权。弃权？真的有点晕。呵呵，这种情况下还弃权。

 

那么投票器，如何集成到Spring的Filter里面呢？

Spring的Filter一般都由一个Manager支撑着。比如accessDecisionManager，可以由RoleVoter和BasicAclEntryVoter提供投票。accessDecisionManager根据RoleVoter，BasicAclEntryVoter投票结果，做出决策判断。

 

细粒度（数据级）的权限控制，Spring Security提供了一种模型以及相关实现。下面我简要说说这个模型。

举例：张三授权查询华北区域客户资料，李四授权查询华南区域客户资料。那么，首先会对所有客户记录做个标示（相当于取个id），然后在acl-entry表给张三授权华北所有客户访问权限；给李四华南区域所有客户权限。表记录大致是这样的：

访问用户	被访问数据	授权操作
张三	华北电力客户1	读取
张三	华北电力客户2	读取
李四	华南电力客户1	读取
…	…	…

这个模型的缺点是非常明显的：

<!--[if !supportLists]-->1.       <!--[endif]-->和业务数据绑定死了，业务数据的增/删，需要维护该权限表；

<!--[if !supportLists]-->2.       <!--[endif]-->在大数据量的情况下，系统效率低下。

 

因此，开发者需要自己书写投票器了。

我们理想中的权限管理

客户对权限管理的需求

这里是指我们服务的最终用户，而不是软件开发者。客户对权限管理的需求，大体可以概括如下：

<!--[if !supportLists]-->1.       <!--[endif]-->自主灵活地管理角色、角色权限，并将角色赋予系统相关用户；

<!--[if !supportLists]-->2.       <!--[endif]-->数据安全。系统展现数据是满足权限的，在系统内部搜索数据也必须在相应权限访问内，对系统数据进行增加、修改、删除必须是满足权限的；

<!--[if !supportLists]-->3.       <!--[endif]-->没有功能的按钮、菜单、数据等等，就不要在界面上出现了。

开发中遇到的难点

管理用户、角色、权限，以及三者之间的关系，这种典型的RBAC模型，非常容易，没有任何困难。

 

困难的是，数据级权限控制。这是和业务直接挂钩的，最复杂，而且会经常因为客户需求表达不到位、开发人员需求理解不到位、系统框架库表结构发生变化，而不断变化的。

这种变化，不仅需要编码，而且还需要重新测试。甚至这种变化会波及到其他模块，甚至整个系统。

系统开发经历几次变化下来，代码里面散布着if/else，散布着sql语句。导致bad smell。

我们理想的权限管理

我们期望的权限管理，应该具有这么几个特性：

<!--[if !supportLists]-->1.       <!--[endif]-->能实现角色级权限；能实现数据级权限；

<!--[if !supportLists]-->2.       <!--[endif]-->简单、易操作，能够应对各种需求；

<!--[if !supportLists]-->3.       <!--[endif]-->应对需求变更能力强；

<!--[if !supportLists]-->4.       <!--[endif]-->最好有相关界面，比如权限管理界面、角色管理界面，角色和权限关系维护界面，用户和角色关系维护界面。如果没有界面，也是可以接受的。毕竟这些页面需要最终用户来使用，不同用户对系统的界面要求不同。因此我们并不期望统一的管理界面。

 

Spring Security的评价

在Spring Security世界里，可以区分出哪些资源可以匿名访问，哪些需要角色权限，又是哪个页面提供登录功能；怎样进行用户身份认证，用户的密码如何加密。哪些资源必须使用https协议，资源和访问端口有怎样的对应关系。

 

下面就优点和缺点对Spring Security进行点评。

优点

总体说来Spring Security具有以下几个优点：

<!--[if !supportLists]-->1.       <!--[endif]-->提供了一套权限框架，这套框架是可行的；

<!--[if !supportLists]-->2.       <!--[endif]-->提供了很多用户身份认证功能，可以节约大量开发工作；

<!--[if !supportLists]-->3.       <!--[endif]-->提供了角色判断功能，这点既是优点又是缺点；

<!--[if !supportLists]-->4.       <!--[endif]-->提供了form-login、remember me等控制。

 

其中2、4两点，对于我们中国开发者（我对国外系统不大了解），可用性并不大。我们的系统大多采用用户名/密码身份认证模式，大多公司都有可复用代码。form-login、remember me等这些功能，并不是难以开发，而且可用之处也并不多。

缺点

我个人认为Spring Security存在以下几个硬伤：

<!--[if !supportLists]-->1.       <!--[endif]-->角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：

<!--[if !supportLists]-->a)      <!--[endif]-->url的权限控制，<intercept-url pattern="/**" access="ROLE_USER" />；

<!--[if !supportLists]-->b)      <!--[endif]-->java方法的权限控制，@Secured("IS_AUTHENTICATED_ANONYMOUSLY")；

<!--[if !supportLists]-->c)       <!--[endif]-->java方法的权限控制，<protect method="set*" access="ROLE_ADMIN" />；

<!--[if !supportLists]-->2.       <!--[endif]-->RBCA这种被广泛运用的模型，没有在Spring Security体现出来；

<!--[if !supportLists]-->3.       <!--[endif]-->Spring Security没有提供好的细粒度（数据级）权限方案，提供的缺省实现维护工作量大，在大数据量情况下，几乎不可用；

<!--[if !supportLists]-->4.       <!--[endif]-->Spring Security对于用户、角色、权限之间的关系，没有提供任何一种维护界面。不过从Spring Security角度看，确实没有必要有界面。角色创建、角色和权限直接的关系，都被“编码”到配置文件和源文件了；

<!--[if !supportLists]-->5.       <!--[endif]-->Spring Security学习难度大，配置文件还是很多。我承认有很多高手，但我们也看到有很多新人加入软件开发领域。付出如此大的学习代价，获得这么一点点好处，个人觉得并不值得。

 

附言：

本人在JavaEye创建“权限管理”圈子快2周了，吸引不少网友进来。我感到很高兴，也很荣幸。由于Spring Security运用范围还是比较广的，所以我打算好好学习一下，把学习经验和大家分享一下。

 

欢迎大家加入“权限管理”圈子讨论，探讨对权限管理的认识、看法、建议等等。

http://accessmanager.group.iteye.com/

 

评论

56 楼 Sobfist 2010-03-17  

我仔细看过他的源代码。最后得出的结论是：先确定自己的权限模型，不要一想到权限管理 ，就去想怎么套spring security。往往大家都是把问题复杂化了。

55 楼 redwolf888 2010-02-04  

同感，在处理细粒度的时候，不太好实现

54 楼 ronartest 2010-01-19  

其实我个人去年研究了一下acegi 也发现这个东西可以说不灵活也可以说是灵活的（看起来），，其实就是个半成品，，关于用户 角色这些都可以自己扩展接口 拥有自己的实现，，但是我对于他在方法方面的保护就很不满意，，一个标注固定了角色。。

   这个也好解决。我现在自己做的一套方案 页面现实控制得还算灵活，想隐藏也好，禁用也罢都可以，在保护方法方面也是延续spring security 的思想，，，自己写个标注，，然后再去读标注的信息，想怎么做就怎么做。。我看上面各位所说的灵活性 是应该支持的，，我们可以基于spring security 去改他的实现，也可以延用他的思想做自己的东西，，，其中过滤器还是核心。。。。只要过滤到请求了，你想怎么验证都你自己说了算。。。。

   在数据权限方面我没什么思路暂时，不知各位有实现的可否交流一下。。

53 楼 caoyangx 2009-11-11  

spring security的最大优点就是可以自己做自己想要的功能，然后通过过滤器方式装载进去，你说的只是官方发布的demo而已，真正开发，都是进过自己改造的，没有人原封不动的拿来用。

52 楼 berlou 2009-11-11  

Acegi的角色部分确实有点不理想， 还规定必须要以ROLE_开头作为角色名， 不然它不识别。害的我们还需要Adapt一下。

51 楼 liudun 2009-11-10  

好帖啊。

50 楼 liujunsong 2009-04-23  

太复杂了.
如果一个技术方案,你不能在一张图上把它说清楚.
那么最好不要用它.
以后会陷进去的,拔不出来了就.

49 楼 metadmin 2009-04-23  

phz50 写道

楼主这篇文章写的挺不错的啊，但仔细读来感觉楼主可能对spring security了解的还不是很深呀，哈哈，请先不要立刻反驳我的评论呀，其实“角色创建、角色和权限直接的关系”这些完全可以写到数据库的，然后通过实现

org.springframework.security.intercept.web.FilterInvocationDefinitionSource

类进行URL等权限控制，只要做一些简单配置就行了啊，强烈建议文章Spring Security 2 配置精讲。。。

您说的，我前面回复已经知道了。
不过，您看：相当于我们这些开发者把数据写到数据库，然后呢实现一个类。
Spring Secuirty在这方面唯一做的事情，就是自动帮我们验证功能权限。

因此，不妨列列我们开发人员需要的工作：
1，设计库表（这不是难事）；
2，维护这些库表 的 前台界面，后台程序；
3，实现 FilterInvocationDefinitionSource 类；
4，将这个配置到Spring Security。

然后，在需要验证的地方，Spring Security帮我们自动验证。


这方面，Spring Security帮我们做的事情也太少了。


如果，不使用Spring Security。我们就缺一个自动拦截验证的功能。事实上，写个Filter，添加到web.xml，实现url自动功能验证，并不是难事。

48 楼 phz50 2009-04-23  

楼主这篇文章写的挺不错的啊，但仔细读来感觉楼主可能对spring security了解的还不是很深呀，哈哈，请先不要立刻反驳我的评论呀，其实“角色创建、角色和权限直接的关系”这些完全可以写到数据库的，然后通过实现

org.springframework.security.intercept.web.FilterInvocationDefinitionSource

类进行URL等权限控制，只要做一些简单配置就行了啊，强烈建议文章Spring Security 2 配置精讲。。。

47 楼 os586 2009-04-19  

楼上说的极是,俺正搞这个东西.

不过在对URL,Method进行权限控制的时候,如果登录者对自己的资源进行了修改,并且写入了缓存中. 这样缓存中就是登录者最新的用户权限信息.

那么URL与Method拦截器在对正在访问的URL与Method与缓存中存储的信息进行匹配 的时候,也得到了相关权限.但是SecrutiyContextHolder..getContext中的上下文验证信息确没有实时更新.因此导致决策管理器不会通过.

那么我想问大家都是怎样来完成缓存与上下文中的信息的一致的?
我的处理方式是:让UserDetailService的实现类从缓存中取得缓存中的权限信息,但是这只是在登录后的第一次存储上下文信息,如果修改了某个角色及资源信息后,修改了缓存是否同时要更新上下文信息

如果更新是怎样更新的?是再次调用UserDetailService实现类LoadUserNameByName()吗?还是通过其它的?

我是在ObjectDefitionSource中重新读取了一次,大家是怎么处理的啊?

46 楼 chc9chc 2009-04-18  

1.       角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：

a)      url的权限控制，<intercept-url pattern="/**" access="ROLE_USER" />；

b)      java方法的权限控制，@Secured("IS_AUTHENTICATED_ANONYMOUSLY")；

c)       java方法的权限控制，<protect method="set*" access="ROLE_ADMIN" />；
这个是可以从数据库里读取的，当维护后可以刷新cach

45 楼 metadmin 2009-04-17  

首先，我想谈谈这种通用的权限解决方案可行性。XACML规范制定也有很长时间了，Oracle Entitlement Server（原来的BEA 产品）遵循了该规范。他们产品在国外有很多实施案例。这是产品特性介绍： http://www.oracle.com/technology/products/id_mgmt/oes/htdocs/fov_entitlements_server.htm
（呵呵，我竟然给OES做宣传了）

通用的这种权限确实有难度，相信很多开发者都想过这种事情。我们团队并不会比大家聪明多少，我们只是认准了这个，敢于付出时间，持之以恒，搞了4年多了。


至于，metadmin模型的简陋，比不上Spring Security。我更倾向于用实例说话。目前我们实施的案例，都能通过metadmin 设计器把权限逻辑表达出来，然后在应用程序里面调用API达到控制目的。

metadmin模型，和XACML有些类似，都采用策略模式。metadmin提出了“用户分类”和“资源分类”概念。


采用API侵入模式，确实有待改进。但，我们也应该看到，需要提供API调用模式。因为权限判断不应该仅仅是URL, BEAN-METHOD控制。


让我们在回到Spring Security上面来吧。
没有这个框架之前，困扰开发者的不是“需要在哪里插入权限判断”，而是“判断逻辑的编写和变更”。
因为，我认为Spring Security，解决了不是困扰我们的问题，而避开了困扰问题。另外，增加了一个额外负担：学习曲线高，配置文件比较多（虽然spring security2做了大量精简）。



不瞒您说：我们几年前开发的权限模式，和Spring Security类似，采用filter模式。不过我们当时开发出很多可复用的out-of-box插件，配置配置就能满足70％左右的细粒度权限需求（包括做决策权限和查询权限）。
不过，我们还是否决了这个方案，因为需要这么多配置。我们团队不想把开发者从“编程”转移“XML配置”。

44 楼 downpour 2009-04-17  

任何权限系统都不能做到通用，权限系统往往和业务相关度比较大，绝大多数的企业应用，他们可能会应对不同的业务有不同的权限模型。所以我认为试图完成一套通用的权限解决方案是一种不切实际的做法，劝楼主不要误入歧途。

楼主的产品在我看来还非常初级和简陋，和Spring Security相比还相差甚远，对于我们来说，基本上也不会采用你的API进行业务领域的编程。

Spring Security的优点在于它解决了Web领域的一些简单的权限问题，但不是所有的问题，因为它的基础模型比较简单，正如之前所说的，基本上以5张表作为它的模型基础，所以它能够实现的所有功能也全部都是基于这样的模型之上的。说到生产效率，Spring Security对使用Spring作为IoC容器的J2EE程序来说，是一种比较优秀的选择，因为它能够可插拔的提供许多权限方面的功能。

43 楼 metadmin 2009-04-17  

任何一项技术的提出，尤其是工业技术。应该面向2个主题之一：
1，解决一项难题；或者
2，提高生产效率。

我想请教各位几个问题：
1，Spring Security解决了哪些难题呢？
2，Spring Security在哪些方面提高了生产效率呢？

42 楼 metadmin 2009-04-17  

可插拔的权限方案非常诱人。不瞒您说，我们正在研究这个课题。
之前，我们也提出过几套可插拔方案，但都被否决了。

说到可插拔，大家想到的肯定是：AOP和Filter。
Spring本身就是个容器，在AOP方面具有优势。

Metadmin目前还不打算采用这种方式，我们将继续探索更好的方式。
因为，我们不假定用户将使用aop技术做开发，也不假定只运行在web系统里面。

我们期望的特性是：
1，不管开发者使用什么框架，什么技术（AOP OR NOT AOP），都能使用；
2，尽量减少开发者配置工作量，学习难度。

可插拔，我们可欲，目前还不急求。

如果大家有好的可插拔方案，还请赐教。

41 楼 tuoxie007 2009-04-16  

楼主说的很是，spring-security这个东西太复杂了，配置的烦人，我为了学这个东西花了很多的时间，最后确发现这套解决方案根本不能运用于我们的项目，浪费了大量的时间和精力，希望后来的人要谨慎。
这个框架只能解决一些简单问题，复杂的问题可以通过自己实现其中的接口来实现，但成本太高，不值得，还不如就事论事的自己解决实际问题。

40 楼 downpour 2009-04-15  

to metadmin: 你的这个产品不适合我，因为我很难将它直接用于我的项目中，因为它不是可插拔的。

39 楼 songjingjing520 2009-04-13  

只讲到了spring security的角色认证这块外
spring security的ACL授权（访问控制列表）这块没涉及

38 楼 llade 2009-04-13  

justshare 写道

llade 写道

[quote="daquan198163可以的，SS的标签库就是做这个的。
但我觉得它自带的标签库有问题:<security:authorize ifAllGranted="ROLE_admin">xx</security:authorize>
这样就把角色写死在页面里了，我觉得更好的做法是
<security:authorize ifAllGranted="/xx.do">xx</security:authorize>，即声明这个被保护的页面元素对应了哪个资源，至于这个资源需要哪个角色标签库程序是很容易获得的，进而计算是否有权查看。

问题是ROLE就很多了。有些ROLE不能预设，比如，突然来了个 “南京纪检组”，必须动态的加的。

URL，METHOD，ROLE,Resource等等这些，通常情况下是固定的，也就是说：很少会有变动，即使变动，数据量也比较小，可以考虑存储在Cache中，如果有变动的话，重新添加进CACHE或刷新cache即可。
还有secutity标签，本身留有接口，可以自己重新实现.

我说的是xx.do能表示的东西相当有限，并且不那么直观。
问个问题：假如有编辑按钮南京纪检组可见,删除按钮扬州不可见，添加意见按钮江苏可见？
是否ifAllGranted="/xx.do"里面设置？不管ifAllGranted是什么，它总要等于某个东西吧。不可能是ROLE_USER之类的所有用户统称吧。

按我的习惯就会用el表达式：${button_edit}${button_delete}${button_comment}照写，其他权限逻辑放在某个ACL Voter里,而真正个过滤规则写在脚本或者由图形界面管理了，过滤完成之后只要request.setAttribute将按钮代码设进去，不显示的按钮就留空或者占位符，按钮代码也是在某个地方配置。页面上就没有ifAllGranted.

37 楼 justshare 2009-04-13  

llade 写道

[quote="daquan198163可以的，SS的标签库就是做这个的。
但我觉得它自带的标签库有问题:<security:authorize ifAllGranted="ROLE_admin">xx</security:authorize>
这样就把角色写死在页面里了，我觉得更好的做法是
<security:authorize ifAllGranted="/xx.do">xx</security:authorize>，即声明这个被保护的页面元素对应了哪个资源，至于这个资源需要哪个角色标签库程序是很容易获得的，进而计算是否有权查看。

问题是ROLE就很多了。有些ROLE不能预设，比如，突然来了个 “南京纪检组”，必须动态的加的。

URL，METHOD，ROLE,Resource等等这些，通常情况下是固定的，也就是说：很少会有变动，即使变动，数据量也比较小，可以考虑存储在Cache中，如果有变动的话，重新添加进CACHE或刷新cache即可。
还有secutity标签，本身留有接口，可以自己重新实现.