Spring Security详细配置.docx

1、Spring Security详细配置论坛上看了不少Spring Security的相关文章。这些文章基本上都还是基于Acegi-1.X的配置方式，而主要的配置示例也来自于SpringSide的贡献。 众所周知，Spring Security针对Acegi的一个重大的改进就在于其配置方式大大简化了。所以如果配置还是基于Acegi-1.X这样比较繁琐的配置方式的话，那么我们还不如直接使用Acegi而不要去升级了。所以在这里，我将结合一个示例，重点讨论一下Spring Security 2是如何进行配置简化的。 搭建基础环境 首先我们为示例搭建基本的开发环境，环境的搭建方式，可以参考我的另外一篇文

2、章： 整个环境的搭建包括：创建合适的目录结构、加入了合适的Library，加入了基本的Jetty启动类、加入基本的配置文件等。最终的项目结构，可以参考我的附件。 参考文档 这里主要的参考文档是Spring Security的自带的Reference。网络上有一个它的中文翻译，地址如下： 除此之外，springside有一个比较完整的例子，不过是基于Acegi的，我也参阅了其中的一些实现。 Spring Security基本配置 Spring Security是基于Spring的的权限认证框架，对于Spring和Acegi已经比较熟悉的同学对于之前的配置方式应该已经非常了解。接下来的例子，将向大

3、家展示Spring Security基于schema的配置方式。 最小化配置 1. 在web.xml文件中加入Filter声明 Xml代码 1. 2. 3. springSecurityFilterChain4. org.springframework.web.filter.DelegatingFilterProxy5. 6. 7. springSecurityFilterChain8. /*9. springSecurityFilterChain org.springframework.web.filter.DelegatingFilterProxy springSecurityFilter

4、Chain /*这个Filter会拦截所有的URL请求，并且对这些URL请求进行Spring Security的验证。 注意，springSecurityFilterChain这个名称是由命名空间默认创建的用于处理web安全的一个内部的bean的id。所以你在你的Spring配置文件中，不应该再使用这个id作为你的bean。 与Acegi的配置不同，Acegi需要自行声明一个Spring的bean来作为Filter的实现，而使用Spring Security后，无需再额外定义bean，而是使用元素进行配置。 2. 使用最小的配置 Xml代码 1. 2. 3. 这段配置表示：我们要保护应用程序中

5、的所有URL，只有拥有ROLE_USER角色的用户才能访问。你可以使用多个元素为不同URL的集合定义不同的访问需求，它们会被归入一个有序队列中，每次取出最先匹配的一个元素使用。 所以你必须把期望使用的匹配条件放到最上边。 3. 配置UserDetailsService来指定用户和权限 接下来，我们来配置一个UserDetailsService来指定用户和权限： Xml代码 1. 2. 3. 4. 5. 6. 7. 在这里，downpour拥有ROLE_USER和ROLE_ADMIN的权限，robbin拥有ROLE_USER权限，QuakeWang拥有ROLE_ADMIN的权限 4. 小结 有了

6、以上的配置，你已经可以跑简单的Spring Security的应用了。只不过在这里，我们还缺乏很多基本的元素，所以我们尚不能对上面的代码进行完整性测试。 如果你具备Acegi的知识，你会发现，有很多Acegi中的元素，在Spring Security中都没有了，这些元素包括：表单和基本登录选项、密码编码器、Remember-Me认证等等。 接下来，我们就来详细剖析一下Spring Security中的这些基本元素。 剖析基本配置元素 1. 有关auto-config属性 在上面用到的auto-config属性，其实是下面这些配置的缩写： Xml代码 1. 2. 3. 4. 5. 6. 7. 8

7、. 这些元素分别与登录认证，匿名认证，基本认证，注销处理和remember-me对应。 他们拥有各自的属性，可以改变他们的具体行为。 这样，我们在Acegi中所熟悉的元素又浮现在我们的面前。只是在这里，我们使用的是命名空间而已。 2. 与Acegi的比较 我们仔细观察一下没有auto-config的那段XML配置，是不是熟悉多了？让我们来将基于命名空间的配置与传统的Acegi的bean的配置做一个比较，我们会发现以下的区别： 1) 基于命名空间的配置更加简洁，可维护性更强 例如，基于命名空间进行登录认证的配置代码，可能像这样： Xml代码 1. 如果使用老的Acegi的Bean的定义方式，可能

8、像这样： Xml代码 1. 3. 5. 7. 8. 10. 11. 这样的例子很多，有兴趣的读者可以一一进行比较。 2) 基于命名空间的配置，我们无需再担心由于过滤器链的顺序而导致的错误 以前，Acegi在缺乏默认内置配置的情况下，你需要自己来定义所有的bean，并指定这些bean在过滤器链中的顺序。一旦顺序错了，很容易发生错误。而现在，过滤器链的顺序被默认指定，你不需要在担心由于顺序的错误而导致的错误。 3. 过滤器链在哪里 到目前为止，我们都还没有讨论过整个Spring Security的核心部分：过滤器链。在原本Acegi的配置中，我们大概是这样配置我们的过滤器链的： Xml代码 1.

9、3. 4. 5. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 6. PATTERN_TYPE_APACHE_ANT 7. /common/*=#NONE# 8. /css/*=#NONE# 9. /images/*=#NONE# 10. /js/*=#NONE# 11. /login.jsp=#NONE# 12. /*=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilte

10、r,exceptionTranslationFilter,filterSecurityInterceptor 13. 14. 15. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON PATTERN_TYPE_APACHE_ANT /common/*=#NONE# /css/*=#NONE# /images/*=#NONE# /js/*=#NONE# /login.jsp=#NONE# /*=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,secu

11、rityContextHolderAwareRequestFilter,exceptionTranslationFilter,filterSecurityInterceptor 其中，每个过滤器链都将对应于Spring配置文件中的bean的id。 现在，在Spring Security中，我们将看不到这些配置，这些配置都被内置在节点中。让我们来看看这些默认的，已经被内置的过滤器： 这些过滤器已经被Spring容器默认内置注册，这也就是我们不再需要在配置文件中定义那么多bean的原因。 同时，过滤器顺序在使用命名空间的时候是被严格执行的。它们在初始化的时候就预先被排好序。不仅如此，Spring

12、Security规定，你不能替换那些元素自己使用而创建出的过滤器，比如HttpSessionContextIntegrationFilter, ExceptionTranslationFilter 或 FilterSecurityInterceptor。 当然，这样的规定是否合理，有待进一步讨论。因为实际上在很多时候，我们希望覆盖过滤器链中的某个过滤器的默认行为。而Spring Security的这种规定在一定程度上限制了我们的行为。 不过Spring Security允许你把你自己的过滤器添加到队列中，使用custom-filter元素，并且指定你的过滤器应该出现的位置： Xml代码 1.

13、2. 3. 不仅如此，你还可以使用after或before属性，如果你想把你的过滤器添加到队列中另一个过滤器的前面或后面。 可以分别在position属性使用FIRST或LAST来指定你想让你的过滤器出现在队列元素的前面或后面。 这个特性或许能够在一定程度上弥补Spring Security的死板规定，而在之后的应用中，我也会把它作为切入点，对资源进行管理。 另外，我需要补充一点的是，对于在http/intercept-url中没有进行定义的URL，将会默认使用系统内置的过滤器链进行权限认证。所以，你并不需要在http/intercept-url中额外定义一个类似/*的匹配规则。 使用数据库对

14、用户和权限进行管理 一般来说，我们都有使用数据库对用户和权限进行管理的需求，而不会把用户写死在配置文件里。所以，我们接下来就重点讨论使用数据库对用户和权限进行管理的方法。 用户和权限的关系设计 在此之前，我们首先需要讨论一下用户（User）和权限（Role）之间的关系。Spring Security在默认情况下，把这两者当作一对多的关系进行处理。所以，在Spring Security中对这两个对象所采用的表结构关系大概像这样： Java代码 1. CREATETABLEusers( 2. usernameVARCHAR(50)NOTNULLPRIMARYKEY, 3. passwordVARC

15、HAR(50)NOTNULL, 4. enabledBITNOTNULL 5. ); 6. 7. CREATETABLEauthorities( 8. usernameVARCHAR(50)NOTNULL, 9. authorityVARCHAR(50)NOTNULL 10. );CREATE TABLE users ( username VARCHAR(50) NOT NULL PRIMARY KEY, password VARCHAR(50) NOT NULL, enabled BIT NOT NULL);CREATE TABLE authorities ( username VARCHA

16、R(50) NOT NULL, authority VARCHAR(50) NOT NULL);不过这种设计方式在实际生产环境中基本上不会采用。一般来说，我们会使用逻辑主键ID来标示每个User和每个Authorities（Role）。而且从典型意义上讲，他们之间是一个多对多的关系，我们会采用3张表来表示，下面是我在MySQL中建立的3张表的schema示例： Java代码 1. CREATETABLEuser( 2. idint(11)NOTNULLauto_increment, 3. namevarchar(255)defaultNULL, 4. passwordvarchar(255)d

17、efaultNULL, 5. disabledint(1)NOTNULL, 6. PRIMARYKEY(id) 7. )ENGINE=InnoDBDEFAULTCHARSET=utf8; 8. 9. CREATETABLErole( 10. idint(11)NOTNULLauto_increment, 11. namevarchar(255)defaultNULL, 12. PRIMARYKEY(id) 13. )ENGINE=InnoDBDEFAULTCHARSET=utf8; 14. 15. CREATETABLEuser_role( 16. user_idint(11)NOTNULL, 17. role_idint(11)NOTNULL, 18. PRIMARYKEY(user_id,role_id), 19. UNIQUEKEYrole_id(role_id), 20. KEYFK143BF46AF6AD4381(user_id), 21. KEYFK143BF46A51827FA1(role_id), 22. CONSTRAINTFK143BF46A51827FA1FOREIGNKEY(role_id)REFERENCESrole(id), 23.