Spring Security优劣之我见

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

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

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

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

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

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

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

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

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

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

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

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

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

首先，我想谈谈这种通用的权限解决方案可行性。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配置”。

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

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

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

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

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

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

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

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

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

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

楼主这篇文章写的挺不错的啊，但仔细读来感觉楼主可能对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自动功能验证，并不是难事。