Spring security 的知識
衆所周知，Spring Security針對Acegi的一個重大的改進就在於其配置方式大大簡化了。所以如果配置還是基於Acegi-1.X這樣比較繁瑣的配置方式的話，那麼我們還不如直接使用Acegi而不要去升級了。所以在這裏，我將結合一個示例，重點討論一下SpringSecurity 2是如何進行配置簡化的。
搭建基礎環境
首先我們爲示例搭建基本的開發環境，環境的搭建方式，可以參考我的另外一篇文章：http://www.iteye.com/wiki/struts2/1321-struts2-development-environment-to-build
整個環境的搭建包括：創建合適的目錄結構、加入了合適的Library，加入了基本的Jetty啓動類、加入基本的配置文件等。最終的項目結構，可以參考我的附件。
Spring Security基本配置
Spring Security是基於Spring的的權限認證框架，對於Spring和Acegi已經比較熟悉的同學對於之前的配置方式應該已經非常瞭解。接下來的例子，將向大家展示Spring
Security基於schema的配置方式。
最小化配置
1. 在web.xml文件中加入Filter聲明
1. <!-- Spring security Filter -->
2. <filter>
3. <filter-name>springSecurityFilterChain</filter-name>
4. <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
5. </filter>
6. <filter-mapping>
7. <filter-name>springSecurityFilterChain</filter-name>
8. <url-pattern>/*</url-pattern>
9. </filter-mapping>
這個Filter會攔截所有的URL請求，並且對這些URL請求進行Spring
Security的驗證。
注意，springSecurityFilterChain這個名稱是由命名空間默認創建的用於處理web安全的一個內部的bean的id。所以你在你的Spring配置文件中，不應該再使用這個id作爲你的bean。
與Acegi的配置不同，Acegi需要自行聲明一個Spring的bean來作爲Filter的實現，而使用Spring
Security後，無需再額外定義bean，而是使用<http>元素進行配置。
2. 使用最小的<http>配置
1. <http auto-config='true'>
2. <intercept-url pattern="/**" access="ROLE_USER" />
3. </http>
這段配置表示：我們要保護應用程序中的所有URL，只有擁有ROLE_USER角色的用戶才能訪問。你可以使用多個<intercept-url>元素爲不同URL的集合定義不同的訪問需求，它們會被歸入一個有序隊列中，每次取出最先匹配的一個元素使用。所以你必須把期望使用的匹配條件放到最上邊。
3. 配置UserDetailsService來指定用戶和權限
接下來，我們來配置一個UserDetailsService來指定用戶和權限：
1. <authentication-provider>
2. <user-service>
3. <user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" />
4. <user name="robbin" password="robbin" authorities="ROLE_USER" />
5. <user name="QuakeWang" password="QuakeWang" authorities="ROLE_ADMIN" />
6. </user-service>
7. </authentication-provider>
在這裏，downpour擁有ROLE_USER和ROLE_ADMIN的權限，robbin擁有ROLE_USER權限，QuakeWang擁有ROLE_ADMIN的權限
4. 小結
有了以上的配置，你已經可以跑簡單的Spring Security的應用了。只不過在這裏，我們還缺乏很多基本的元素，所以我們尚不能對上面的代碼進行完整性測試。
如果你具備Acegi的知識，你會發現，有很多Acegi中的元素，在Spring
Security中都沒有了，這些元素包括：表單和基本登錄選項、密碼編碼器、Remember-Me認證等等。
接下來，我們就來詳細剖析一下Spring Security中的這些基本元素。
剖析基本配置元素
1. 有關auto-config屬性
在上面用到的auto-config屬性，其實是下面這些配置的縮寫：
1. <http>
2. <intercept-url pattern="/**" access="ROLE_USER" />
3. <form-login />
4. <anonymous />
5. <http-basic />
6. <logout />
7. <remember-me />
8. </http>
這些元素分別與登錄認證，匿名認證，基本認證，註銷處理和remember-me對應。他們擁有各自的屬性，可以改變他們的具體行爲。
這樣，我們在Acegi中所熟悉的元素又浮現在我們的面前。只是在這裏，我們使用的是命名空間而已。
2. 與Acegi的比較
我們仔細觀察一下沒有auto-config的那段XML配置，是不是熟悉多了？讓我們來將基於命名空間的配置與傳統的Acegi的bean的配置做一個比較，我們會發現以下的區別：
1) 基於命名空間的配置更加簡潔，可維護性更強
例如，基於命名空間進行登錄認證的配置代碼，可能像這樣：
1. <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" default-target-url="/work" />
如果使用老的Acegi的Bean的定義方式，可能像這樣：
1. <bean id="authenticationProcessingFilter"
2. class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
3. <property name="authenticationManager"
4. ref="authenticationManager"/>
5. <property name="authenticationFailureUrl"
6. value="/login.jsp?error=1"/>
7. <property name="defaultTargetUrl" value="/work"/>
8. <property name="filterProcessesUrl"
9. value="/j_acegi_security_check"/>
10. <property name="rememberMeServices" ref="rememberMeServices"/>
11. </bean>
這樣的例子很多，有興趣的讀者可以一一進行比較。
2) 基於命名空間的配置，我們無需再擔心由於過濾器鏈的順序而導致的錯誤
以前，Acegi在缺乏默認內置配置的情況下，你需要自己來定義所有的bean，並指定這些bean在過濾器鏈中的順序。一旦順序錯了，很容易發生錯誤。而現在，過濾器鏈的順序被默認指定，你不需要在擔心由於順序的錯誤而導致的錯誤。
3. 過濾器鏈在哪裏
到目前爲止，我們都還沒有討論過整個Spring Security的核心部分：過濾器鏈。在原本Acegi的配置中，我們大概是這樣配置我們的過濾器鏈的：
1. <bean id="filterChainProxy"
2. class="org.acegisecurity.util.FilterChainProxy">
3. <property name="filterInvocationDefinitionSource">
4. <value>
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,securityContextHolderAwareRequestFilter,exceptionTranslationFilter,filterSecurityInterceptor
13. </value>
14. </property>
15. </bean>
其中，每個過濾器鏈都將對應於Spring配置文件中的bean的id。
現在，在Spring Security中，我們將看不到這些配置，這些配置都被內置在<http>節點中。讓我們來看看這些默認的，已經被內置的過濾器：
這些過濾器已經被Spring容器默認內置註冊，這也就是我們不再需要在配置文件中定義那麼多bean的原因。
同時，過濾器順序在使用命名空間的時候是被嚴格執行的。它們在初始化的時候就預先被排好序。不僅如此，Spring Security規定，你不能替換那些<http>元素自己使用而創建出的過濾器，比如HttpSessionContextIntegrationFilter,ExceptionTranslationFilter或
FilterSecurityInterceptor。
當然，這樣的規定是否合理，有待進一步討論。因爲實際上在很多時候，我們希望覆蓋過濾器鏈中的某個過濾器的默認行爲。而Spring Security的這種規定在一定程度上限制了我們的行爲。
不過Spring Security允許你把你自己的過濾器添加到隊列中，使用custom-filter元素，並且指定你的過濾器應該出現的位置：
1. <beans:bean id="myFilter" class="com.mycompany.MySpecialAuthenticationFilter">
2. <custom-filter position="AUTHENTICATION_PROCESSING_FILTER"/>
3. </beans:bean>
不僅如此，你還可以使用after或before屬性，如果你想把你的過濾器添加到隊列中另一個過濾器的前面或後面。可以分別在position屬性使用"FIRST"或"LAST"來指定你想讓你的過濾器出現在隊列元素的前面或後面。
這個特性或許能夠在一定程度上彌補Spring Security的死板規定，而在之後的應用中，我也會把它作爲切入點，對資源進行管理。
另外，我需要補充一點的是，對於在http/intercept-url中沒有進行定義的URL，將會默認使用系統內置的過濾器鏈進行權限認證。所以，你並不需要在http/intercept-url中額外定義一個類似/**的匹配規則。
使用數據庫對用戶和權限進行管理
一般來說，我們都有使用數據庫對用戶和權限進行管理的需求，而不會把用戶寫死在配置文件裏。所以，我們接下來就重點討論使用數據庫對用戶和權限進行管理的方法。
用戶和權限的關係設計
在此之前，我們首先需要討論一下用戶（User）和權限（Role）之間的關係。Spring
Security在默認情況下，把這兩者當作一對多的關係進行處理。所以，在Spring Security中對這兩個對象所採用的表結構關係大概像這樣：
1. CREATE TABLE users (
2. username VARCHAR(50) NOT NULL PRIMARY KEY,
3. password VARCHAR(50) NOT NULL,
4. enabled BIT NOT NULL
5. );
6.
7. CREATE TABLE authorities (
8. username VARCHAR(50) NOT NULL,
9. authority VARCHAR(50) NOT NULL
10. );
不過這種設計方式在實際生產環境中基本上不會採用。一般來說，我們會使用邏輯主鍵ID來標示每個User和每個Authorities（Role）。而且從典型意義上講，他們之間是一個多對多的關係，我們會採用3張表來表示，下面是我在MySQL中建立的3張表的schema示例：
1. CREATE TABLE `user` (
2. `id` int(11) NOT NULL auto_increment,
3. `name` varchar(255) default NULL,
4. `password` varchar(255) default NULL,
5. `disabled` int(1) NOT NULL,
6. PRIMARY KEY (`id`)
7. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
8.
9. CREATE TABLE `role` (
10. `id` int(11) NOT NULL auto_increment,
11. `name` varchar(255) default NULL,
12. PRIMARY KEY (`id`)
13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
14.
15. CREATE TABLE `user_role` (
16. `user_id` int(11) NOT NULL,
17. `role_id` int(11) NOT NULL,
18. PRIMARY KEY (`user_id`,`role_id`),
19. UNIQUE KEY `role_id` (`role_id`),
20. KEY `FK143BF46AF6AD4381` (`user_id`),
21. KEY `FK143BF46A51827FA1` (`role_id`),
22. CONSTRAINT `FK143BF46A51827FA1` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`),
23. CONSTRAINT `FK143BF46AF6AD4381` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`)
24. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
通過配置SQL來模擬用戶和權限
有了數據庫的表設計，我們就可以在Spring Security中，通過配置SQL，來模擬用戶和權限，這依然通過<authentication-provider>來完成：
1. <authentication-provider>
2. <jdbc-user-service data-source-ref="dataSource"
3. users-by-username-query="SELECT U.username, U.password, U.accountEnabled AS 'enabled' FROM User U where U.username=?"
4. authorities-by-username-query="SELECT U.username, R.name as 'authority' FROM User U JOIN Authority A ON u.id = A.userId JOIN Role R ON R.id = A.roleId WHERE U.username=?"/>
5. </authentication-provider>
這裏給出的是一個使用SQL進行模擬用戶和權限的示例。其中你需要爲運行SQL準備相應的dataSource。這個dataSource應該對應於Spring中的某個bean的定義。
從這段配置模擬用戶和權限的情況來看，實際上Spring Security對於用戶，需要username，password，accountEnabled三個字段。對於權限，它需要的是username和authority兩個字段。
也就是說，如果我們能夠通過其他的方式，模擬上面的這些對象，並插入到Spring Security中去，我們同樣能夠實現用戶和權限的認證。接下來，我們就來看看我們如何通過自己的實現，來完成這件事情。
通過擴展Spring Security的默認實現來進行用戶和權限的管理
事實上，Spring Security提供了2個認證的接口，分別用於模擬用戶和權限，以及讀取用戶和權限的操作方法。這兩個接口分別是：UserDetails和UserDetailsService。
1. public interface UserDetails extends Serializable {
2. GrantedAuthority[] getAuthorities();
3. String getPassword();
4. String getUsername();
5. boolean isAccountNonExpired();
6. boolean isAccountNonLocked();
7. boolean isCredentialsNonExpired();
8. boolean isEnabled();
9. }
1. public interface UserDetailsService {
2. UserDetails loadUserByUsername(String username)
3. throws UsernameNotFoundException, DataAccessException;
4. }
非常清楚，一個接口用於模擬用戶，另外一個用於模擬讀取用戶的過程。所以我們可以通過實現這兩個接口，來完成使用數據庫對用戶和權限進行管理的需求。在這裏，我將給出一個使用Hibernate來定義用戶和權限之間關係的示例。
1. 定義User類和Role類，使他們之間形成多對多的關係
1. @Entity
2. @Proxy(lazy = false)
3. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
4. public class User {
5. private static final long serialVersionUID = 8026813053768023527L;
6. @Id
7. @GeneratedValue
8. private Integer id;
9. private String name;
10. private String password;
11. private boolean disabled;
12. @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER)
13. @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id"))
14. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
15. private Set<Role> roles;
16. // setters and getters
17. }
1. @Entity
2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
3. public class Role {
4. @Id
5. @GeneratedValue
6. private Integer id;
7. private String name;
8. // setters and getters
9. }
請注意這裏的Annotation的寫法。同時，我爲User和Role之間配置了緩存。並且將他們之間的關聯關係設置的lazy屬性設置成false，從而保證在User對象取出之後的使用不會因爲脫離session的生命週期而產生lazy
loading問題。
2. 使User類實現UserDetails接口
接下來，我們讓User類去實現UserDetails接口：
1. @Entity
2. @Proxy(lazy = false)
3. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
4. public class User implements UserDetails {
5. private static final long serialVersionUID = 8026813053768023527L;
6. @Id
7. @GeneratedValue
8. private Integer id;
9. private String name;
10. private String password;
11. private boolean disabled;
12. @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER)
13. @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id"))
14. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
15. private Set<Role> roles;
16. /**
17. * The default constructor
18. */
19. public User() {
20.
21. }
22.
23. /* (non-Javadoc)
24. * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
25. */
26. public GrantedAuthority[] getAuthorities() {
27. List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
28. for(Role role : roles) {
29. grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
30. }
31. return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
32. }
33.
34. /* (non-Javadoc)
35. * @see org.springframework.security.userdetails.UserDetails#getPassword()
36. */
37. public String getPassword() {
38. return password;
39. }
40. /* (non-Javadoc)
41. * @see org.springframework.security.userdetails.UserDetails#getUsername()
42. */
43. public String getUsername() {
44. return name;
45. }
46. /* (non-Javadoc)
47. * @see org.springframework.security.userdetails.UserDetails#isAccountNonExpired()
48. */
49. public boolean isAccountNonExpired() {
50. return true;
51. }
52. /* (non-Javadoc)
53. * @see org.springframework.security.userdetails.UserDetails#isAccountNonLocked()
54. */
55. public boolean isAccountNonLocked() {
56. return true;
57. }
58. /* (non-Javadoc)
59. * @see org.springframework.security.userdetails.UserDetails#isCredentialsNonExpired()
60. */
61. public boolean isCredentialsNonExpired() {
62. return true;
63. }
64. /* (non-Javadoc)
65. * @see org.springframework.security.userdetails.UserDetails#isEnabled()
66. */
67. public boolean isEnabled() {
68. return !this.disabled;
69. }
70.
71. // setters and getters
72. }
實現UserDetails接口中的每個函數，其實沒什麼很大的難度，除了其中的一個函數我需要額外強調一下：
1. /* (non-Javadoc)
2. * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
3. */
4. public GrantedAuthority[] getAuthorities() {
5. List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
6. for(Role role : roles) {
7. grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
8. }
9. return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
10. }
這個函數的實際作用是根據User返回這個User所擁有的權限列表。如果以上面曾經用過的例子來說，如果當前User是downpour，我需要得到ROLE_USER和ROLE_ADMIN；如果當前User是robbin，我需要得到ROLE_USER。
瞭解了含義，實現就變得簡單了，由於User與Role是多對多的關係，我們可以通過User得到所有這個User所對應的Role，並把這些Role的name拼裝起來返回。
由此可見，實現UserDetails接口，並沒有什麼神祕的地方，它只是實際上在一定程度上只是代替了使用配置文件的硬編碼：
1. <user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" />
3. 實現UserDetailsService接口
1. @Repository("securityManager")
2. public class SecurityManagerSupport extends HibernateDaoSupport implements UserDetailsService {
3. /**
4. * Init sessionFactory here because the annotation of Spring 2.5 can not support override inject
5. *
6. * @param sessionFactory
7. */
8. @Autowired
9. public void init(SessionFactory sessionFactory) {
10. super.setSessionFactory(sessionFactory);
11. }
12.
13. public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException, DataAccessException {
14. List<User> users = getHibernateTemplate().find("FROM User user WHERE user.name = ? AND user.disabled = false", userName);
15. if(users.isEmpty()) {
16. throw new UsernameNotFoundException("User " + userName + " has no GrantedAuthority");
17. }
18. return users.get(0);
19. }
20. }
這個實現非常簡單，由於我們的User對象已經實現了UserDetails接口。所以我們只要使用Hibernate，根據userName取出相應的User對象即可。注意在這裏，由於我們對於User的關聯對象Roles都設置了lazy="false"，所以我們無需擔心lazy
loading的問題。
4. 配置文件
有了上面的代碼，一切都變得很簡單，重新定義authentication-provider節點即可。如果你使用Spring
2.5的Annotation配置功能，你甚至可以不需要在配置文件中定義securityManager的bean。
1. <authentication-provider user-service-ref="securityManager">
2. <password-encoder hash="md5"/>
3. </authentication-provider>
使用數據庫對資源進行管理
在完成了使用數據庫來進行用戶和權限的管理之後，我們再來看看http配置的部分。在實際應用中，我們不可能使用類似/**的方式來指定URL與權限ROLE的對應關係，而是會針對某些URL，指定某些特定的ROLE。而URL與ROLE之間的映射關係最好可以進行擴展和配置。而URL屬於資源的一種，所以接下來，我們就來看看如何使用數據庫來對權限和資源的匹配關係進行管理，並且將認證匹配加入到Spring
Security中去。
權限和資源的設計
上面我們講到，用戶（User）和權限（Role）之間是一個多對多的關係。那麼權限（Role）和資源（Resource）之間呢？其實他們之間也是一個典型的多對多的關係，我們同樣用3張表來表示：
1. CREATE TABLE `role` (
2. `id` int(11) NOT NULL auto_increment,
3. `name` varchar(255) default NULL,
4. `description` varchar(255) default NULL,
5. PRIMARY KEY (`id`)
6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
7.
8. CREATE TABLE `resource` (
9. `id` int(11) NOT NULL auto_increment,
10. `type` varchar(255) default NULL,
11. `value` varchar(255) default NULL,
12. PRIMARY KEY (`id`)
13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
14.
15. CREATE TABLE `role_resource` (
16. `role_id` int(11) NOT NULL,
17. `resource_id` int(11) NOT NULL,
18. PRIMARY KEY (`role_id`,`resource_id`),
19. KEY `FKAEE599B751827FA1` (`role_id`),
20. KEY `FKAEE599B7EFD18D21` (`resource_id`),
21. CONSTRAINT `FKAEE599B751827FA1` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`),
22. CONSTRAINT `FKAEE599B7EFD18D21` FOREIGN KEY (`resource_id`) REFERENCES `resource` (`id`)
23. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
在這裏Resource可能分成多種類型，比如MENU,URL,METHOD等等。
針對資源的認證
針對資源的認證，實際上應該由SpringSecurity中的FilterSecurityInterceptor這個過濾器來完成。不過內置的FilterSecurityInterceptor的實現往往無法滿足我們的要求，所以傳統的Acegi的方式，我們往往會替換FilterSecurityInterceptor的實現，從而對URL等資源進行認證。
不過在Spring Security中，由於默認的攔截器鏈內置了FilterSecurityInterceptor，而且上面我們也提到過，這個實現無法被替換。這就使我們犯了難。我們如何對資源進行認證呢？
實際上，我們雖然無法替換FilterSecurityInterceptor的默認實現，不過我們可以再實現一個類似的過濾器，並將我們自己的過濾器作爲一個customer-filter，加到默認的過濾器鏈的最後，從而完成整個過濾檢查。
接下來我們就來看看一個完整的例子：
1. 建立權限（Role）和資源（Resource）之間的關聯關係
修改上面的權限（Role）的Entity定義：
1. @Entity
2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
3. public class Role {
4. @Id
5. @GeneratedValue
6. private Integer id;
7. private String name;
8. @ManyToMany(targetEntity = Resource.class, fetch = FetchType.EAGER)
9. @JoinTable(name = "role_resource", joinColumns = @JoinColumn(name = "role_id"), inverseJoinColumns = @JoinColumn(name = "resource_id"))
10. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
11. private Set<Resource> resources;
12. // setters and getter
13. }
增加資源（Resource）的Entity定義：
1. @Entity
2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
3. public class Resource {
4. @Id
5. @GeneratedValue
6. private Integer id;
7. private String type;
8. private String value;
9. @ManyToMany(mappedBy = "resources", targetEntity = Role.class, fetch = FetchType.EAGER)
10. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
11. private Set<Role> roles;
12. /**
13. * The default constructor
14. */
15. public Resource() {
16. }
17. }
注意他們之間的多對多關係，以及他們之間關聯關係的緩存和lazy屬性設置。
2. 在系統啓動的時候，把所有的資源load到內存作爲緩存
由於資源信息對於每個項目來說，相對固定，所以我們可以將他們在系統啓動的時候就load到內存作爲緩存。這裏做法很多，我給出的示例是將資源的存放在servletContext中。
1. public class ServletContextLoaderListener implements ServletContextListener {
2. /* (non-Javadoc)
3. * @see javax.servlet.ServletContextListener#contextInitialized(javax.servlet.ServletContextEvent)
4. */
5. public void contextInitialized(ServletContextEvent servletContextEvent) {
6. ServletContext servletContext = servletContextEvent.getServletContext();
7. SecurityManager securityManager = this.getSecurityManager(servletContext);
8. Map<String, String> urlAuthorities = securityManager.loadUrlAuthorities();
9. servletContext.setAttribute("urlAuthorities", urlAuthorities);
10. }
11. /* (non-Javadoc)
12. * @see javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)
13. */
14. public void contextDestroyed(ServletContextEvent servletContextEvent) {
15. servletContextEvent.getServletContext().removeAttribute("urlAuthorities");
16. }
17. /**
18. * Get SecurityManager from ApplicationContext
19. *
20. * @param servletContext
21. * @return
22. */
23. protected SecurityManager getSecurityManager(ServletContext servletContext) {
24. return (SecurityManager) WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean("securityManager");
25. }
26. }
這裏，我們看到了SecurityManager，這是一個接口，用於權限相關的邏輯處理。還記得之前我們使用數據庫管理User的時候所使用的一個實現類SecurityManagerSupport嘛？我們不妨依然借用這個類，讓它實現SecurityManager接口，來同時完成url的讀取工作。
1. @Service("securityManager")
2. public class SecurityManagerSupport extends HibernateDaoSupport implements UserDetailsService, SecurityManager {
3. /**
4. * Init sessionFactory here because the annotation of Spring 2.5 can not support override inject
5. *
6. * @param sessionFactory
7. */
8. @Autowired
9. public void init(SessionFactory sessionFactory) {
10. super.setSessionFactory(sessionFactory);
11. }
12.
13. /* (non-Javadoc)
14. * @see org.springframework.security.userdetails.UserDetailsService#loadUserByUsername(java.lang.String)
15. */
16. public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException, DataAccessException {
17. List<User> users = getHibernateTemplate().find("FROM User user WHERE user.name = ? AND user.disabled = false", userName);
18. if(users.isEmpty()) {
19. throw new UsernameNotFoundException("User " + userName + " has no GrantedAuthority");
20. }
21. return users.get(0);
22. }
23.
24. /* (non-Javadoc)
25. * @see com.javaeye.sample.security.SecurityManager#loadUrlAuthorities()
26. */
27. public Map<String, String> loadUrlAuthorities() {
28. Map<String, String> urlAuthorities = new HashMap<String, String>();
29. List<Resource> urlResources = getHibernateTemplate().find("FROM Resource resource WHERE resource.type = ?", "URL");
30. for(Resource resource : urlResources) {
31. urlAuthorities.put(resource.getValue(), resource.getRoleAuthorities());
32. }
33. return urlAuthorities;
34. }
35. }
3. 編寫自己的FilterInvocationDefinitionSource實現類，對資源進行認證
1. public class SecureResourceFilterInvocationDefinitionSource implements FilterInvocationDefinitionSource, InitializingBean {
2. private UrlMatcher urlMatcher;
3. private boolean useAntPath = true;
4. private boolean lowercaseComparisons = true;
5.
6. /**
7. * @param useAntPath the useAntPath to set
8. */
9. public void setUseAntPath(boolean useAntPath) {
10. this.useAntPath = useAntPath;
11. }
12.
13. /**
14. * @param lowercaseComparisons
15. */
16. public void setLowercaseComparisons(boolean lowercaseComparisons) {
17. this.lowercaseComparisons = lowercaseComparisons;
18. }
19.
20. /* (non-Javadoc)
21. * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
22. */
23. public void afterPropertiesSet() throws Exception {
24.
25. // default url matcher will be RegexUrlPathMatcher
26. this.urlMatcher = new RegexUrlPathMatcher();
27.
28. if (useAntPath) { // change the implementation if required
29. this.urlMatcher = new AntUrlPathMatcher();
30. }
31.
32. // Only change from the defaults if the attribute has been set
33. if ("true".equals(lowercaseComparisons)) {
34. if (!this.useAntPath) {
35. ((RegexUrlPathMatcher) this.urlMatcher).setRequiresLowerCaseUrl(true);
36. }
37. } else if ("false".equals(lowercaseComparisons)) {
38. if (this.useAntPath) {
39. ((AntUrlPathMatcher) this.urlMatcher).setRequiresLowerCaseUrl(false);
40. }
41. }
42.
43. }
44.
45. /* (non-Javadoc)
46. * @see org.springframework.security.intercept.ObjectDefinitionSource#getAttributes(java.lang.Object)
47. */
48. public ConfigAttributeDefinition getAttributes(Object filter) throws IllegalArgumentException {
49.
50. FilterInvocation filterInvocation = (FilterInvocation) filter;
51. String requestURI = filterInvocation.getRequestUrl();
52. Map<String, String> urlAuthorities = this.getUrlAuthorities(filterInvocation);
53.
54. String grantedAuthorities = null;
55. for(Iterator<Map.Entry<String, String>> iter = urlAuthorities.entrySet().iterator(); iter.hasNext();) {
56. Map.Entry<String, String> entry = iter.next();
57. String url = entry.getKey();
58.
59. if(urlMatcher.pathMatchesUrl(url, requestURI)) {
60. grantedAuthorities = entry.getValue();
61. break;
62. }
63.
64. }
65.
66. if(grantedAuthorities != null) {
67. ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor();
68. configAttrEditor.setAsText(grantedAuthorities);
69. return (ConfigAttributeDefinition) configAttrEditor.getValue();
70. }
71.
72. return null;
73. }
74.
75. /* (non-Javadoc)
76. * @see org.springframework.security.intercept.ObjectDefinitionSource#getConfigAttributeDefinitions()
77. */
78. @SuppressWarnings("unchecked")
79. public Collection getConfigAttributeDefinitions() {
80. return null;
81. }
82.
83. /* (non-Javadoc)
84. * @see org.springframework.security.intercept.ObjectDefinitionSource#supports(java.lang.Class)
85. */
86. @SuppressWarnings("unchecked")
87. public boolean supports(Class clazz) {
88. return true;
89. }
90.
91. /**
92. *
93. * @param filterInvocation
94. * @return
95. */
96. @SuppressWarnings("unchecked")
97. private Map<String, String> getUrlAuthorities(FilterInvocation filterInvocation) {
98. ServletContext servletContext = filterInvocation.getHttpRequest().getSession().getServletContext();
99. return (Map<String, String>)servletContext.getAttribute("urlAuthorities");
100. }
101.
102. }
4. 配置文件修改
接下來，我們來修改一下Spring Security的配置文件，把我們自定義的這個過濾器插入到過濾器鏈中去。
1. <beans:beans xmlns="http://www.springframework.org/schema/security"
2. xmlns:beans="http://www.springframework.org/schema/beans"
3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4. xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
5. http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">
6.
7. <beans:bean id="loggerListener" class="org.springframework.security.event.authentication.LoggerListener" />
8.
9. <http access-denied-page="/403.jsp" >
10. <intercept-url pattern="/static/**" filters="none" />
11. <intercept-url pattern="/template/**" filters="none" />
12. <intercept-url pattern="/" filters="none" />
13. <intercept-url pattern="/login.jsp" filters="none" />
14. <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" default-target-url="/index" />
15. <logout logout-success-url="/login.jsp"/>
16. <http-basic />
17. </http>
18.
19. <authentication-manager alias="authenticationManager"/>
20.
21. <authentication-provider user-service-ref="securityManager">
22. <password-encoder hash="md5"/>
23. </authentication-provider>
24.
25. <beans:bean id="accessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
26. <beans:property name="allowIfAllAbstainDecisions" value="false"/>
27. <beans:property name="decisionVoters">
28. <beans:list>
29. <beans:bean class="org.springframework.security.vote.RoleVoter"/>
30. <beans:bean class="org.springframework.security.vote.AuthenticatedVoter"/>
31. </beans:list>
32. </beans:property>
33. </beans:bean>
34.
35. <beans:bean id="resourceSecurityInterceptor" class="org.springframework.security.intercept.web.FilterSecurityInterceptor">
36. <beans:property name="authenticationManager" ref="authenticationManager"/>
37. <beans:property name="accessDecisionManager" ref="accessDecisionManager"/>
38. <beans:property name="objectDefinitionSource" ref="secureResourceFilterInvocationDefinitionSource" />
39. <beans:property name="observeOncePerRequest" value="false" />
40. <custom-filter after="LAST" />
41. </beans:bean>
42.
43. <beans:bean id="secureResourceFilterInvocationDefinitionSource" class="com.javaeye.sample.security.interceptor.SecureResourceFilterInvocationDefinitionSource" />
44.
45. </beans:beans>
請注意，由於我們所實現的，是FilterSecurityInterceptor中的一個開放接口，所以我們實際上定義了一個新的bean，並通過<custom-filter
after="LAST" />插入到過濾器鏈中去。
Spring Security對象的訪問
1. 訪問當前登錄用戶
Spring Security提供了一個線程安全的對象：SecurityContextHolder，通過這個對象，我們可以訪問當前的登錄用戶。我寫了一個類，可以通過靜態方法去讀取：
1. public class SecurityUserHolder {
2.
3. /**
4. * Returns the current user
5. *
6. * @return
7. */
8. public static User getCurrentUser() {
9. return (User) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
10. }
11.
12. }
2. 訪問當前登錄用戶所擁有的權限
通過上面的分析，我們知道，用戶所擁有的所有權限，其實是通過UserDetails接口中的getAuthorities()方法獲得的。只要實現這個接口，就能實現需求。在我的代碼中，不僅實現了這個接口，還在上面做了點小文章，這樣我們可以獲得一個用戶所擁有權限的字符串表示：
1. /* (non-Javadoc)
2. * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
3. */
4. public GrantedAuthority[] getAuthorities() {
5. List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
6. for(Role role : roles) {
7. grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
8. }
9. return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
10. }
11.
12. /**
13. * Returns the authorites string
14. *
15. * eg.
16. * downpour --- ROLE_ADMIN,ROLE_USER
17. * robbin --- ROLE_ADMIN
18. *
19. * @return
20. */
21. public String getAuthoritiesString() {
22. List<String> authorities = new ArrayList<String>();
23. for(GrantedAuthority authority : this.getAuthorities()) {
24. authorities.add(authority.getAuthority());
25. }
26. return StringUtils.join(authorities, ",");
27. }
3. 訪問當前登錄用戶能夠訪問的資源
這就涉及到用戶（User），權限（Role）和資源（Resource）三者之間的對應關係。我同樣在User對象中實現了一個方法：
1. /**
2. * @return the roleResources
3. */
4. public Map<String, List<Resource>> getRoleResources() {
5. // init roleResources for the first time
6. if(this.roleResources == null) {
7. this.roleResources = new HashMap<String, List<Resource>>();
8.
9. for(Role role : this.roles) {
10. String roleName = role.getName();
11. Set<Resource> resources = role.getResources();
12. for(Resource resource : resources) {
13. String key = roleName + "_" + resource.getType();
14. if(!this.roleResources.containsKey(key)) {
15. this.roleResources.put(key, new ArrayList<Resource>());
16. }
17. this.roleResources.get(key).add(resource);
18. }
19. }
20.
21. }
22. return this.roleResources;
23. }
這裏，會在User對象中設置一個緩存機制，在第一次取的時候，通過遍歷User所有的Role，獲取相應的Resource信息。
代碼示例
在附件中，我給出了一個簡單的例子，把我上面所講到的所有內容整合在一起，是一個eclipse的工程，大家可以下載進行參考。
Spring security 的知識
衆所周知，Spring Security針對Acegi的一個重大的改進就在於其配置方式大大簡化了。所以如果配置還是基於Acegi-1.X這樣比較繁瑣的配置方式的話，那麼我們還不如直接使用Acegi而不要去升級了。所以在這裏，我將結合一個示例，重點討論一下SpringSecurity 2是如何進行配置簡化的。
搭建基礎環境
首先我們爲示例搭建基本的開發環境，環境的搭建方式，可以參考我的另外一篇文章：http://www.iteye.com/wiki/struts2/1321-struts2-development-environment-to-build
整個環境的搭建包括：創建合適的目錄結構、加入了合適的Library，加入了基本的Jetty啓動類、加入基本的配置文件等。最終的項目結構，可以參考我的附件。
Spring Security基本配置
Spring Security是基於Spring的的權限認證框架，對於Spring和Acegi已經比較熟悉的同學對於之前的配置方式應該已經非常瞭解。接下來的例子，將向大家展示Spring
Security基於schema的配置方式。
最小化配置
1. 在web.xml文件中加入Filter聲明
1. <!-- Spring security Filter -->
2. <filter>
3. <filter-name>springSecurityFilterChain</filter-name>
4. <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
5. </filter>
6. <filter-mapping>
7. <filter-name>springSecurityFilterChain</filter-name>
8. <url-pattern>/*</url-pattern>
9. </filter-mapping>
這個Filter會攔截所有的URL請求，並且對這些URL請求進行Spring
Security的驗證。
注意，springSecurityFilterChain這個名稱是由命名空間默認創建的用於處理web安全的一個內部的bean的id。所以你在你的Spring配置文件中，不應該再使用這個id作爲你的bean。
與Acegi的配置不同，Acegi需要自行聲明一個Spring的bean來作爲Filter的實現，而使用Spring
Security後，無需再額外定義bean，而是使用<http>元素進行配置。
2. 使用最小的<http>配置
1. <http auto-config='true'>
2. <intercept-url pattern="/**" access="ROLE_USER" />
3. </http>
這段配置表示：我們要保護應用程序中的所有URL，只有擁有ROLE_USER角色的用戶才能訪問。你可以使用多個<intercept-url>元素爲不同URL的集合定義不同的訪問需求，它們會被歸入一個有序隊列中，每次取出最先匹配的一個元素使用。所以你必須把期望使用的匹配條件放到最上邊。
3. 配置UserDetailsService來指定用戶和權限
接下來，我們來配置一個UserDetailsService來指定用戶和權限：
1. <authentication-provider>
2. <user-service>
3. <user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" />
4. <user name="robbin" password="robbin" authorities="ROLE_USER" />
5. <user name="QuakeWang" password="QuakeWang" authorities="ROLE_ADMIN" />
6. </user-service>
7. </authentication-provider>
在這裏，downpour擁有ROLE_USER和ROLE_ADMIN的權限，robbin擁有ROLE_USER權限，QuakeWang擁有ROLE_ADMIN的權限
4. 小結
有了以上的配置，你已經可以跑簡單的Spring Security的應用了。只不過在這裏，我們還缺乏很多基本的元素，所以我們尚不能對上面的代碼進行完整性測試。
如果你具備Acegi的知識，你會發現，有很多Acegi中的元素，在Spring
Security中都沒有了，這些元素包括：表單和基本登錄選項、密碼編碼器、Remember-Me認證等等。
接下來，我們就來詳細剖析一下Spring Security中的這些基本元素。
剖析基本配置元素
1. 有關auto-config屬性
在上面用到的auto-config屬性，其實是下面這些配置的縮寫：
1. <http>
2. <intercept-url pattern="/**" access="ROLE_USER" />
3. <form-login />
4. <anonymous />
5. <http-basic />
6. <logout />
7. <remember-me />
8. </http>
這些元素分別與登錄認證，匿名認證，基本認證，註銷處理和remember-me對應。他們擁有各自的屬性，可以改變他們的具體行爲。
這樣，我們在Acegi中所熟悉的元素又浮現在我們的面前。只是在這裏，我們使用的是命名空間而已。
2. 與Acegi的比較
我們仔細觀察一下沒有auto-config的那段XML配置，是不是熟悉多了？讓我們來將基於命名空間的配置與傳統的Acegi的bean的配置做一個比較，我們會發現以下的區別：
1) 基於命名空間的配置更加簡潔，可維護性更強
例如，基於命名空間進行登錄認證的配置代碼，可能像這樣：
1. <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" default-target-url="/work" />
如果使用老的Acegi的Bean的定義方式，可能像這樣：
1. <bean id="authenticationProcessingFilter"
2. class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
3. <property name="authenticationManager"
4. ref="authenticationManager"/>
5. <property name="authenticationFailureUrl"
6. value="/login.jsp?error=1"/>
7. <property name="defaultTargetUrl" value="/work"/>
8. <property name="filterProcessesUrl"
9. value="/j_acegi_security_check"/>
10. <property name="rememberMeServices" ref="rememberMeServices"/>
11. </bean>
這樣的例子很多，有興趣的讀者可以一一進行比較。
2) 基於命名空間的配置，我們無需再擔心由於過濾器鏈的順序而導致的錯誤
以前，Acegi在缺乏默認內置配置的情況下，你需要自己來定義所有的bean，並指定這些bean在過濾器鏈中的順序。一旦順序錯了，很容易發生錯誤。而現在，過濾器鏈的順序被默認指定，你不需要在擔心由於順序的錯誤而導致的錯誤。
3. 過濾器鏈在哪裏
到目前爲止，我們都還沒有討論過整個Spring Security的核心部分：過濾器鏈。在原本Acegi的配置中，我們大概是這樣配置我們的過濾器鏈的：
1. <bean id="filterChainProxy"
2. class="org.acegisecurity.util.FilterChainProxy">
3. <property name="filterInvocationDefinitionSource">
4. <value>
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,securityContextHolderAwareRequestFilter,exceptionTranslationFilter,filterSecurityInterceptor
13. </value>
14. </property>
15. </bean>
其中，每個過濾器鏈都將對應於Spring配置文件中的bean的id。
現在，在Spring Security中，我們將看不到這些配置，這些配置都被內置在<http>節點中。讓我們來看看這些默認的，已經被內置的過濾器：
這些過濾器已經被Spring容器默認內置註冊，這也就是我們不再需要在配置文件中定義那麼多bean的原因。
同時，過濾器順序在使用命名空間的時候是被嚴格執行的。它們在初始化的時候就預先被排好序。不僅如此，Spring Security規定，你不能替換那些<http>元素自己使用而創建出的過濾器，比如HttpSessionContextIntegrationFilter,ExceptionTranslationFilter或
FilterSecurityInterceptor。
當然，這樣的規定是否合理，有待進一步討論。因爲實際上在很多時候，我們希望覆蓋過濾器鏈中的某個過濾器的默認行爲。而Spring Security的這種規定在一定程度上限制了我們的行爲。
不過Spring Security允許你把你自己的過濾器添加到隊列中，使用custom-filter元素，並且指定你的過濾器應該出現的位置：
1. <beans:bean id="myFilter" class="com.mycompany.MySpecialAuthenticationFilter">
2. <custom-filter position="AUTHENTICATION_PROCESSING_FILTER"/>
3. </beans:bean>
不僅如此，你還可以使用after或before屬性，如果你想把你的過濾器添加到隊列中另一個過濾器的前面或後面。可以分別在position屬性使用"FIRST"或"LAST"來指定你想讓你的過濾器出現在隊列元素的前面或後面。
這個特性或許能夠在一定程度上彌補Spring Security的死板規定，而在之後的應用中，我也會把它作爲切入點，對資源進行管理。
另外，我需要補充一點的是，對於在http/intercept-url中沒有進行定義的URL，將會默認使用系統內置的過濾器鏈進行權限認證。所以，你並不需要在http/intercept-url中額外定義一個類似/**的匹配規則。
使用數據庫對用戶和權限進行管理
一般來說，我們都有使用數據庫對用戶和權限進行管理的需求，而不會把用戶寫死在配置文件裏。所以，我們接下來就重點討論使用數據庫對用戶和權限進行管理的方法。
用戶和權限的關係設計
在此之前，我們首先需要討論一下用戶（User）和權限（Role）之間的關係。Spring
Security在默認情況下，把這兩者當作一對多的關係進行處理。所以，在Spring Security中對這兩個對象所採用的表結構關係大概像這樣：
1. CREATE TABLE users (
2. username VARCHAR(50) NOT NULL PRIMARY KEY,
3. password VARCHAR(50) NOT NULL,
4. enabled BIT NOT NULL
5. );
6.
7. CREATE TABLE authorities (
8. username VARCHAR(50) NOT NULL,
9. authority VARCHAR(50) NOT NULL
10. );
不過這種設計方式在實際生產環境中基本上不會採用。一般來說，我們會使用邏輯主鍵ID來標示每個User和每個Authorities（Role）。而且從典型意義上講，他們之間是一個多對多的關係，我們會採用3張表來表示，下面是我在MySQL中建立的3張表的schema示例：
1. CREATE TABLE `user` (
2. `id` int(11) NOT NULL auto_increment,
3. `name` varchar(255) default NULL,
4. `password` varchar(255) default NULL,
5. `disabled` int(1) NOT NULL,
6. PRIMARY KEY (`id`)
7. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
8.
9. CREATE TABLE `role` (
10. `id` int(11) NOT NULL auto_increment,
11. `name` varchar(255) default NULL,
12. PRIMARY KEY (`id`)
13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
14.
15. CREATE TABLE `user_role` (
16. `user_id` int(11) NOT NULL,
17. `role_id` int(11) NOT NULL,
18. PRIMARY KEY (`user_id`,`role_id`),
19. UNIQUE KEY `role_id` (`role_id`),
20. KEY `FK143BF46AF6AD4381` (`user_id`),
21. KEY `FK143BF46A51827FA1` (`role_id`),
22. CONSTRAINT `FK143BF46A51827FA1` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`),
23. CONSTRAINT `FK143BF46AF6AD4381` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`)
24. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
通過配置SQL來模擬用戶和權限
有了數據庫的表設計，我們就可以在Spring Security中，通過配置SQL，來模擬用戶和權限，這依然通過<authentication-provider>來完成：
1. <authentication-provider>
2. <jdbc-user-service data-source-ref="dataSource"
3. users-by-username-query="SELECT U.username, U.password, U.accountEnabled AS 'enabled' FROM User U where U.username=?"
4. authorities-by-username-query="SELECT U.username, R.name as 'authority' FROM User U JOIN Authority A ON u.id = A.userId JOIN Role R ON R.id = A.roleId WHERE U.username=?"/>
5. </authentication-provider>
這裏給出的是一個使用SQL進行模擬用戶和權限的示例。其中你需要爲運行SQL準備相應的dataSource。這個dataSource應該對應於Spring中的某個bean的定義。
從這段配置模擬用戶和權限的情況來看，實際上Spring Security對於用戶，需要username，password，accountEnabled三個字段。對於權限，它需要的是username和authority兩個字段。
也就是說，如果我們能夠通過其他的方式，模擬上面的這些對象，並插入到Spring Security中去，我們同樣能夠實現用戶和權限的認證。接下來，我們就來看看我們如何通過自己的實現，來完成這件事情。
通過擴展Spring Security的默認實現來進行用戶和權限的管理
事實上，Spring Security提供了2個認證的接口，分別用於模擬用戶和權限，以及讀取用戶和權限的操作方法。這兩個接口分別是：UserDetails和UserDetailsService。
1. public interface UserDetails extends Serializable {
2. GrantedAuthority[] getAuthorities();
3. String getPassword();
4. String getUsername();
5. boolean isAccountNonExpired();
6. boolean isAccountNonLocked();
7. boolean isCredentialsNonExpired();
8. boolean isEnabled();
9. }
1. public interface UserDetailsService {
2. UserDetails loadUserByUsername(String username)
3. throws UsernameNotFoundException, DataAccessException;
4. }
非常清楚，一個接口用於模擬用戶，另外一個用於模擬讀取用戶的過程。所以我們可以通過實現這兩個接口，來完成使用數據庫對用戶和權限進行管理的需求。在這裏，我將給出一個使用Hibernate來定義用戶和權限之間關係的示例。
1. 定義User類和Role類，使他們之間形成多對多的關係
1. @Entity
2. @Proxy(lazy = false)
3. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
4. public class User {
5. private static final long serialVersionUID = 8026813053768023527L;
6. @Id
7. @GeneratedValue
8. private Integer id;
9. private String name;
10. private String password;
11. private boolean disabled;
12. @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER)
13. @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id"))
14. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
15. private Set<Role> roles;
16. // setters and getters
17. }
1. @Entity
2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
3. public class Role {
4. @Id
5. @GeneratedValue
6. private Integer id;
7. private String name;
8. // setters and getters
9. }
請注意這裏的Annotation的寫法。同時，我爲User和Role之間配置了緩存。並且將他們之間的關聯關係設置的lazy屬性設置成false，從而保證在User對象取出之後的使用不會因爲脫離session的生命週期而產生lazy
loading問題。
2. 使User類實現UserDetails接口
接下來，我們讓User類去實現UserDetails接口：
1. @Entity
2. @Proxy(lazy = false)
3. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
4. public class User implements UserDetails {
5. private static final long serialVersionUID = 8026813053768023527L;
6. @Id
7. @GeneratedValue
8. private Integer id;
9. private String name;
10. private String password;
11. private boolean disabled;
12. @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER)
13. @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id"))
14. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
15. private Set<Role> roles;
16. /**
17. * The default constructor
18. */
19. public User() {
20.
21. }
22.
23. /* (non-Javadoc)
24. * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
25. */
26. public GrantedAuthority[] getAuthorities() {
27. List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
28. for(Role role : roles) {
29. grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
30. }
31. return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
32. }
33.
34. /* (non-Javadoc)
35. * @see org.springframework.security.userdetails.UserDetails#getPassword()
36. */
37. public String getPassword() {
38. return password;
39. }
40. /* (non-Javadoc)
41. * @see org.springframework.security.userdetails.UserDetails#getUsername()
42. */
43. public String getUsername() {
44. return name;
45. }
46. /* (non-Javadoc)
47. * @see org.springframework.security.userdetails.UserDetails#isAccountNonExpired()
48. */
49. public boolean isAccountNonExpired() {
50. return true;
51. }
52. /* (non-Javadoc)
53. * @see org.springframework.security.userdetails.UserDetails#isAccountNonLocked()
54. */
55. public boolean isAccountNonLocked() {
56. return true;
57. }
58. /* (non-Javadoc)
59. * @see org.springframework.security.userdetails.UserDetails#isCredentialsNonExpired()
60. */
61. public boolean isCredentialsNonExpired() {
62. return true;
63. }
64. /* (non-Javadoc)
65. * @see org.springframework.security.userdetails.UserDetails#isEnabled()
66. */
67. public boolean isEnabled() {
68. return !this.disabled;
69. }
70.
71. // setters and getters
72. }
實現UserDetails接口中的每個函數，其實沒什麼很大的難度，除了其中的一個函數我需要額外強調一下：
1. /* (non-Javadoc)
2. * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
3. */
4. public GrantedAuthority[] getAuthorities() {
5. List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
6. for(Role role : roles) {
7. grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
8. }
9. return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
10. }
這個函數的實際作用是根據User返回這個User所擁有的權限列表。如果以上面曾經用過的例子來說，如果當前User是downpour，我需要得到ROLE_USER和ROLE_ADMIN；如果當前User是robbin，我需要得到ROLE_USER。
瞭解了含義，實現就變得簡單了，由於User與Role是多對多的關係，我們可以通過User得到所有這個User所對應的Role，並把這些Role的name拼裝起來返回。
由此可見，實現UserDetails接口，並沒有什麼神祕的地方，它只是實際上在一定程度上只是代替了使用配置文件的硬編碼：
1. <user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" />
3. 實現UserDetailsService接口
1. @Repository("securityManager")
2. public class SecurityManagerSupport extends HibernateDaoSupport implements UserDetailsService {
3. /**
4. * Init sessionFactory here because the annotation of Spring 2.5 can not support override inject
5. *
6. * @param sessionFactory
7. */
8. @Autowired
9. public void init(SessionFactory sessionFactory) {
10. super.setSessionFactory(sessionFactory);
11. }
12.
13. public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException, DataAccessException {
14. List<User> users = getHibernateTemplate().find("FROM User user WHERE user.name = ? AND user.disabled = false", userName);
15. if(users.isEmpty()) {
16. throw new UsernameNotFoundException("User " + userName + " has no GrantedAuthority");
17. }
18. return users.get(0);
19. }
20. }
這個實現非常簡單，由於我們的User對象已經實現了UserDetails接口。所以我們只要使用Hibernate，根據userName取出相應的User對象即可。注意在這裏，由於我們對於User的關聯對象Roles都設置了lazy="false"，所以我們無需擔心lazy
loading的問題。
4. 配置文件
有了上面的代碼，一切都變得很簡單，重新定義authentication-provider節點即可。如果你使用Spring
2.5的Annotation配置功能，你甚至可以不需要在配置文件中定義securityManager的bean。
1. <authentication-provider user-service-ref="securityManager">
2. <password-encoder hash="md5"/>
3. </authentication-provider>
使用數據庫對資源進行管理
在完成了使用數據庫來進行用戶和權限的管理之後，我們再來看看http配置的部分。在實際應用中，我們不可能使用類似/**的方式來指定URL與權限ROLE的對應關係，而是會針對某些URL，指定某些特定的ROLE。而URL與ROLE之間的映射關係最好可以進行擴展和配置。而URL屬於資源的一種，所以接下來，我們就來看看如何使用數據庫來對權限和資源的匹配關係進行管理，並且將認證匹配加入到Spring
Security中去。
權限和資源的設計
上面我們講到，用戶（User）和權限（Role）之間是一個多對多的關係。那麼權限（Role）和資源（Resource）之間呢？其實他們之間也是一個典型的多對多的關係，我們同樣用3張表來表示：
1. CREATE TABLE `role` (
2. `id` int(11) NOT NULL auto_increment,
3. `name` varchar(255) default NULL,
4. `description` varchar(255) default NULL,
5. PRIMARY KEY (`id`)
6. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
7.
8. CREATE TABLE `resource` (
9. `id` int(11) NOT NULL auto_increment,
10. `type` varchar(255) default NULL,
11. `value` varchar(255) default NULL,
12. PRIMARY KEY (`id`)
13. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
14.
15. CREATE TABLE `role_resource` (
16. `role_id` int(11) NOT NULL,
17. `resource_id` int(11) NOT NULL,
18. PRIMARY KEY (`role_id`,`resource_id`),
19. KEY `FKAEE599B751827FA1` (`role_id`),
20. KEY `FKAEE599B7EFD18D21` (`resource_id`),
21. CONSTRAINT `FKAEE599B751827FA1` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`),
22. CONSTRAINT `FKAEE599B7EFD18D21` FOREIGN KEY (`resource_id`) REFERENCES `resource` (`id`)
23. ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
在這裏Resource可能分成多種類型，比如MENU,URL,METHOD等等。
針對資源的認證
針對資源的認證，實際上應該由SpringSecurity中的FilterSecurityInterceptor這個過濾器來完成。不過內置的FilterSecurityInterceptor的實現往往無法滿足我們的要求，所以傳統的Acegi的方式，我們往往會替換FilterSecurityInterceptor的實現，從而對URL等資源進行認證。
不過在Spring Security中，由於默認的攔截器鏈內置了FilterSecurityInterceptor，而且上面我們也提到過，這個實現無法被替換。這就使我們犯了難。我們如何對資源進行認證呢？
實際上，我們雖然無法替換FilterSecurityInterceptor的默認實現，不過我們可以再實現一個類似的過濾器，並將我們自己的過濾器作爲一個customer-filter，加到默認的過濾器鏈的最後，從而完成整個過濾檢查。
接下來我們就來看看一個完整的例子：
1. 建立權限（Role）和資源（Resource）之間的關聯關係
修改上面的權限（Role）的Entity定義：
1. @Entity
2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
3. public class Role {
4. @Id
5. @GeneratedValue
6. private Integer id;
7. private String name;
8. @ManyToMany(targetEntity = Resource.class, fetch = FetchType.EAGER)
9. @JoinTable(name = "role_resource", joinColumns = @JoinColumn(name = "role_id"), inverseJoinColumns = @JoinColumn(name = "resource_id"))
10. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
11. private Set<Resource> resources;
12. // setters and getter
13. }
增加資源（Resource）的Entity定義：
1. @Entity
2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
3. public class Resource {
4. @Id
5. @GeneratedValue
6. private Integer id;
7. private String type;
8. private String value;
9. @ManyToMany(mappedBy = "resources", targetEntity = Role.class, fetch = FetchType.EAGER)
10. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
11. private Set<Role> roles;
12. /**
13. * The default constructor
14. */
15. public Resource() {
16. }
17. }
注意他們之間的多對多關係，以及他們之間關聯關係的緩存和lazy屬性設置。
2. 在系統啓動的時候，把所有的資源load到內存作爲緩存
由於資源信息對於每個項目來說，相對固定，所以我們可以將他們在系統啓動的時候就load到內存作爲緩存。這裏做法很多，我給出的示例是將資源的存放在servletContext中。
1. public class ServletContextLoaderListener implements ServletContextListener {
2. /* (non-Javadoc)
3. * @see javax.servlet.ServletContextListener#contextInitialized(javax.servlet.ServletContextEvent)
4. */
5. public void contextInitialized(ServletContextEvent servletContextEvent) {
6. ServletContext servletContext = servletContextEvent.getServletContext();
7. SecurityManager securityManager = this.getSecurityManager(servletContext);
8. Map<String, String> urlAuthorities = securityManager.loadUrlAuthorities();
9. servletContext.setAttribute("urlAuthorities", urlAuthorities);
10. }
11. /* (non-Javadoc)
12. * @see javax.servlet.ServletContextListener#contextDestroyed(javax.servlet.ServletContextEvent)
13. */
14. public void contextDestroyed(ServletContextEvent servletContextEvent) {
15. servletContextEvent.getServletContext().removeAttribute("urlAuthorities");
16. }
17. /**
18. * Get SecurityManager from ApplicationContext
19. *
20. * @param servletContext
21. * @return
22. */
23. protected SecurityManager getSecurityManager(ServletContext servletContext) {
24. return (SecurityManager) WebApplicationContextUtils.getWebApplicationContext(servletContext).getBean("securityManager");
25. }
26. }
這裏，我們看到了SecurityManager，這是一個接口，用於權限相關的邏輯處理。還記得之前我們使用數據庫管理User的時候所使用的一個實現類SecurityManagerSupport嘛？我們不妨依然借用這個類，讓它實現SecurityManager接口，來同時完成url的讀取工作。
1. @Service("securityManager")
2. public class SecurityManagerSupport extends HibernateDaoSupport implements UserDetailsService, SecurityManager {
3. /**
4. * Init sessionFactory here because the annotation of Spring 2.5 can not support override inject
5. *
6. * @param sessionFactory
7. */
8. @Autowired
9. public void init(SessionFactory sessionFactory) {
10. super.setSessionFactory(sessionFactory);
11. }
12.
13. /* (non-Javadoc)
14. * @see org.springframework.security.userdetails.UserDetailsService#loadUserByUsername(java.lang.String)
15. */
16. public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException, DataAccessException {
17. List<User> users = getHibernateTemplate().find("FROM User user WHERE user.name = ? AND user.disabled = false", userName);
18. if(users.isEmpty()) {
19. throw new UsernameNotFoundException("User " + userName + " has no GrantedAuthority");
20. }
21. return users.get(0);
22. }
23.
24. /* (non-Javadoc)
25. * @see com.javaeye.sample.security.SecurityManager#loadUrlAuthorities()
26. */
27. public Map<String, String> loadUrlAuthorities() {
28. Map<String, String> urlAuthorities = new HashMap<String, String>();
29. List<Resource> urlResources = getHibernateTemplate().find("FROM Resource resource WHERE resource.type = ?", "URL");
30. for(Resource resource : urlResources) {
31. urlAuthorities.put(resource.getValue(), resource.getRoleAuthorities());
32. }
33. return urlAuthorities;
34. }
35. }
3. 編寫自己的FilterInvocationDefinitionSource實現類，對資源進行認證
1. public class SecureResourceFilterInvocationDefinitionSource implements FilterInvocationDefinitionSource, InitializingBean {
2. private UrlMatcher urlMatcher;
3. private boolean useAntPath = true;
4. private boolean lowercaseComparisons = true;
5.
6. /**
7. * @param useAntPath the useAntPath to set
8. */
9. public void setUseAntPath(boolean useAntPath) {
10. this.useAntPath = useAntPath;
11. }
12.
13. /**
14. * @param lowercaseComparisons
15. */
16. public void setLowercaseComparisons(boolean lowercaseComparisons) {
17. this.lowercaseComparisons = lowercaseComparisons;
18. }
19.
20. /* (non-Javadoc)
21. * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
22. */
23. public void afterPropertiesSet() throws Exception {
24.
25. // default url matcher will be RegexUrlPathMatcher
26. this.urlMatcher = new RegexUrlPathMatcher();
27.
28. if (useAntPath) { // change the implementation if required
29. this.urlMatcher = new AntUrlPathMatcher();
30. }
31.
32. // Only change from the defaults if the attribute has been set
33. if ("true".equals(lowercaseComparisons)) {
34. if (!this.useAntPath) {
35. ((RegexUrlPathMatcher) this.urlMatcher).setRequiresLowerCaseUrl(true);
36. }
37. } else if ("false".equals(lowercaseComparisons)) {
38. if (this.useAntPath) {
39. ((AntUrlPathMatcher) this.urlMatcher).setRequiresLowerCaseUrl(false);
40. }
41. }
42.
43. }
44.
45. /* (non-Javadoc)
46. * @see org.springframework.security.intercept.ObjectDefinitionSource#getAttributes(java.lang.Object)
47. */
48. public ConfigAttributeDefinition getAttributes(Object filter) throws IllegalArgumentException {
49.
50. FilterInvocation filterInvocation = (FilterInvocation) filter;
51. String requestURI = filterInvocation.getRequestUrl();
52. Map<String, String> urlAuthorities = this.getUrlAuthorities(filterInvocation);
53.
54. String grantedAuthorities = null;
55. for(Iterator<Map.Entry<String, String>> iter = urlAuthorities.entrySet().iterator(); iter.hasNext();) {
56. Map.Entry<String, String> entry = iter.next();
57. String url = entry.getKey();
58.
59. if(urlMatcher.pathMatchesUrl(url, requestURI)) {
60. grantedAuthorities = entry.getValue();
61. break;
62. }
63.
64. }
65.
66. if(grantedAuthorities != null) {
67. ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor();
68. configAttrEditor.setAsText(grantedAuthorities);
69. return (ConfigAttributeDefinition) configAttrEditor.getValue();
70. }
71.
72. return null;
73. }
74.
75. /* (non-Javadoc)
76. * @see org.springframework.security.intercept.ObjectDefinitionSource#getConfigAttributeDefinitions()
77. */
78. @SuppressWarnings("unchecked")
79. public Collection getConfigAttributeDefinitions() {
80. return null;
81. }
82.
83. /* (non-Javadoc)
84. * @see org.springframework.security.intercept.ObjectDefinitionSource#supports(java.lang.Class)
85. */
86. @SuppressWarnings("unchecked")
87. public boolean supports(Class clazz) {
88. return true;
89. }
90.
91. /**
92. *
93. * @param filterInvocation
94. * @return
95. */
96. @SuppressWarnings("unchecked")
97. private Map<String, String> getUrlAuthorities(FilterInvocation filterInvocation) {
98. ServletContext servletContext = filterInvocation.getHttpRequest().getSession().getServletContext();
99. return (Map<String, String>)servletContext.getAttribute("urlAuthorities");
100. }
101.
102. }
4. 配置文件修改
接下來，我們來修改一下Spring Security的配置文件，把我們自定義的這個過濾器插入到過濾器鏈中去。
1. <beans:beans xmlns="http://www.springframework.org/schema/security"
2. xmlns:beans="http://www.springframework.org/schema/beans"
3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4. xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
5. http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.4.xsd">
6.
7. <beans:bean id="loggerListener" class="org.springframework.security.event.authentication.LoggerListener" />
8.
9. <http access-denied-page="/403.jsp" >
10. <intercept-url pattern="/static/**" filters="none" />
11. <intercept-url pattern="/template/**" filters="none" />
12. <intercept-url pattern="/" filters="none" />
13. <intercept-url pattern="/login.jsp" filters="none" />
14. <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" default-target-url="/index" />
15. <logout logout-success-url="/login.jsp"/>
16. <http-basic />
17. </http>
18.
19. <authentication-manager alias="authenticationManager"/>
20.
21. <authentication-provider user-service-ref="securityManager">
22. <password-encoder hash="md5"/>
23. </authentication-provider>
24.
25. <beans:bean id="accessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
26. <beans:property name="allowIfAllAbstainDecisions" value="false"/>
27. <beans:property name="decisionVoters">
28. <beans:list>
29. <beans:bean class="org.springframework.security.vote.RoleVoter"/>
30. <beans:bean class="org.springframework.security.vote.AuthenticatedVoter"/>
31. </beans:list>
32. </beans:property>
33. </beans:bean>
34.
35. <beans:bean id="resourceSecurityInterceptor" class="org.springframework.security.intercept.web.FilterSecurityInterceptor">
36. <beans:property name="authenticationManager" ref="authenticationManager"/>
37. <beans:property name="accessDecisionManager" ref="accessDecisionManager"/>
38. <beans:property name="objectDefinitionSource" ref="secureResourceFilterInvocationDefinitionSource" />
39. <beans:property name="observeOncePerRequest" value="false" />
40. <custom-filter after="LAST" />
41. </beans:bean>
42.
43. <beans:bean id="secureResourceFilterInvocationDefinitionSource" class="com.javaeye.sample.security.interceptor.SecureResourceFilterInvocationDefinitionSource" />
44.
45. </beans:beans>
請注意，由於我們所實現的，是FilterSecurityInterceptor中的一個開放接口，所以我們實際上定義了一個新的bean，並通過<custom-filter
after="LAST" />插入到過濾器鏈中去。
Spring Security對象的訪問
1. 訪問當前登錄用戶
Spring Security提供了一個線程安全的對象：SecurityContextHolder，通過這個對象，我們可以訪問當前的登錄用戶。我寫了一個類，可以通過靜態方法去讀取：
1. public class SecurityUserHolder {
2.
3. /**
4. * Returns the current user
5. *
6. * @return
7. */
8. public static User getCurrentUser() {
9. return (User) SecurityContextHolder.getContext().getAuthentication().getPrincipal();
10. }
11.
12. }
2. 訪問當前登錄用戶所擁有的權限
通過上面的分析，我們知道，用戶所擁有的所有權限，其實是通過UserDetails接口中的getAuthorities()方法獲得的。只要實現這個接口，就能實現需求。在我的代碼中，不僅實現了這個接口，還在上面做了點小文章，這樣我們可以獲得一個用戶所擁有權限的字符串表示：
1. /* (non-Javadoc)
2. * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
3. */
4. public GrantedAuthority[] getAuthorities() {
5. List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
6. for(Role role : roles) {
7. grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
8. }
9. return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
10. }
11.
12. /**
13. * Returns the authorites string
14. *
15. * eg.
16. * downpour --- ROLE_ADMIN,ROLE_USER
17. * robbin --- ROLE_ADMIN
18. *
19. * @return
20. */
21. public String getAuthoritiesString() {
22. List<String> authorities = new ArrayList<String>();
23. for(GrantedAuthority authority : this.getAuthorities()) {
24. authorities.add(authority.getAuthority());
25. }
26. return StringUtils.join(authorities, ",");
27. }
3. 訪問當前登錄用戶能夠訪問的資源
這就涉及到用戶（User），權限（Role）和資源（Resource）三者之間的對應關係。我同樣在User對象中實現了一個方法：
1. /**
2. * @return the roleResources
3. */
4. public Map<String, List<Resource>> getRoleResources() {
5. // init roleResources for the first time
6. if(this.roleResources == null) {
7. this.roleResources = new HashMap<String, List<Resource>>();
8.
9. for(Role role : this.roles) {
10. String roleName = role.getName();
11. Set<Resource> resources = role.getResources();
12. for(Resource resource : resources) {
13. String key = roleName + "_" + resource.getType();
14. if(!this.roleResources.containsKey(key)) {
15. this.roleResources.put(key, new ArrayList<Resource>());
16. }
17. this.roleResources.get(key).add(resource);
18. }
19. }
20.
21. }
22. return this.roleResources;
23. }
這裏，會在User對象中設置一個緩存機制，在第一次取的時候，通過遍歷User所有的Role，獲取相應的Resource信息。
