注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

骇客归来

ぁ枫あ

 
 
 

日志

 
 

Spring Security 基础详解(Part1)  

2009-03-04 16:21:33|  分类: Spring |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
论坛上看了不少Spring Security的相关文章。这些文章基本上都还是基于Acegi-1.X的配置方式,而主要的配置示例也来自于SpringSide的贡献。

众所周知,Spring Security针对Acegi的一个重大的改进就在于其配置方式大大简化了。所以如果配置还是基于Acegi-1.X这样比较繁琐的配置方式的话,那么我们还不如直接使用Acegi而不要去升级了。所以在这里,我将结合一个示例,重点讨论一下Spring Security 2是如何进行配置简化的。

搭建基础环境

首先我们为示例搭建基本的开发环境,环境的搭建方式,可以参考我的另外一篇文章:http://www.javaeye.com/wiki/struts2/1321-struts2-development-environment-to-build

整个环境的搭建包括:创建合适的目录结构、加入了合适的Library,加入了基本的Jetty启动类、加入基本的配置文件等。最终的项目结构,可以参考我的附件。

参考文档

这里主要的参考文档是Spring Security的自带的Reference。网络上有一个它的中文翻译,地址如下:http://www.family168.com/tutorial/springsecurity/html/springsecurity.html

除此之外,springside有一个比较完整的例子,不过是基于Acegi的,我也参阅了其中的一些实现。

Spring Security基本配置

Spring Security是基于Spring的的权限认证框架,对于Spring和Acegi已经比较熟悉的同学对于之前的配置方式应该已经非常了解。接下来的例子,将向大家展示Spring Security基于schema的配置方式。

最小化配置

1. 在web.xml文件中加入Filter声明

Xml代码

   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> 

<!-- Spring security Filter -->
<filter>
    <filter-name>springSecurityFilterChain</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
    <filter-name>springSecurityFilterChain</filter-name>
    <url-pattern>/*</url-pattern>
</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>配置

Xml代码

   1. <http auto-config='true'> 
   2.     <intercept-url pattern="/**" access="ROLE_USER" /> 
   3. </http> 

<http auto-config='true'>
    <intercept-url pattern="/**" access="ROLE_USER" />
</http>



这段配置表示:我们要保护应用程序中的所有URL,只有拥有ROLE_USER角色的用户才能访问。你可以使用多个<intercept- url>元素为不同URL的集合定义不同的访问需求,它们会被归入一个有序队列中,每次取出最先匹配的一个元素使用。所以你必须把期望使用的匹配条件放到最上边。

3. 配置UserDetailsService来指定用户和权限

接下来,我们来配置一个UserDetailsService来指定用户和权限:

Xml代码

   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> 

<authentication-provider>
    <user-service>
      <user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" />
      <user name="robbin" password="robbin" authorities="ROLE_USER" />
      <user name="QuakeWang" password="QuakeWang" authorities="ROLE_ADMIN" />
    </user-service>
  </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属性,其实是下面这些配置的缩写:

Xml代码

   1. <http> 
   2.     <intercept-url pattern="/**" access="ROLE_USER" /> 
   3.     <form-login /> 
   4.     <anonymous /> 
   5.     <http-basic /> 
   6.     <logout /> 
   7.     <remember-me /> 
   8. </http> 

<http>
    <intercept-url pattern="/**" access="ROLE_USER" />
    <form-login />
    <anonymous />
    <http-basic />
    <logout />
    <remember-me />
</http>



这些元素分别与登录认证,匿名认证,基本认证,注销处理和remember-me对应。 他们拥有各自的属性,可以改变他们的具体行为。

这样,我们在Acegi中所熟悉的元素又浮现在我们的面前。只是在这里,我们使用的是命名空间而已。

2. 与Acegi的比较

我们仔细观察一下没有auto-config的那段XML配置,是不是熟悉多了?让我们来将基于命名空间的配置与传统的Acegi的bean的配置做一个比较,我们会发现以下的区别:

1) 基于命名空间的配置更加简洁,可维护性更强

例如,基于命名空间进行登录认证的配置代码,可能像这样:

Xml代码

   1. <form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" default-target-url="/work" /> 

<form-login login-page="/login.jsp" authentication-failure-url="/login.jsp?error=true" default-target-url="/work" />



如果使用老的Acegi的Bean的定义方式,可能像这样:

Xml代码

   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> 

<bean id="authenticationProcessingFilter"
    class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
 <property name="authenticationManager"
      ref="authenticationManager"/>
 <property name="authenticationFailureUrl"
      value="/login.jsp?error=1"/>
 <property name="defaultTargetUrl" value="/work"/>
 <property name="filterProcessesUrl"
      value="/j_acegi_security_check"/>
 <property name="rememberMeServices" ref="rememberMeServices"/>
</bean>



这样的例子很多,有兴趣的读者可以一一进行比较。

2) 基于命名空间的配置,我们无需再担心由于过滤器链的顺序而导致的错误

以前,Acegi在缺乏默认内置配置的情况下,你需要自己来定义所有的bean,并指定这些bean在过滤器链中的顺序。一旦顺序错了,很容易发生错误。而现在,过滤器链的顺序被默认指定,你不需要在担心由于顺序的错误而导致的错误。

3. 过滤器链在哪里

到目前为止,我们都还没有讨论过整个Spring Security的核心部分:过滤器链。在原本Acegi的配置中,我们大概是这样配置我们的过滤器链的:

Xml代码

   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> 

<bean id="filterChainProxy"
    class="org.acegisecurity.util.FilterChainProxy">
 <property name="filterInvocationDefinitionSource">
  <value>
    CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
    PATTERN_TYPE_APACHE_ANT    
    /common/**=#NONE#
    /css/**=#NONE#
    /images/**=#NONE#
    /js/**=#NONE#
    /login.jsp=#NONE#
    /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,exceptionTranslationFilter,filterSecurityInterceptor
  </value>
 </property>
</bean>



其中,每个过滤器链都将对应于Spring配置文件中的bean的id。

现在,在Spring Security中,我们将看不到这些配置,这些配置都被内置在<http>节点中。让我们来看看这些默认的,已经被内置的过滤器:
[点击查看原始大小图片]

这些过滤器已经被Spring容器默认内置注册,这也就是我们不再需要在配置文件中定义那么多bean的原因。

同时,过滤器顺序在使用命名空间的时候是被严格执行的。它们在初始化的时候就预先被排好序。不仅如此,Spring Security规定,你不能替换那些<http>元素自己使用而创建出的过滤器,比如HttpSessionContextIntegrationFilter, ExceptionTranslationFilter 或 FilterSecurityInterceptor。

当然,这样的规定是否合理,有待进一步讨论。因为实际上在很多时候,我们希望覆盖过滤器链中的某个过滤器的默认行为。而Spring Security的这种规定在一定程度上限制了我们的行为。

不过Spring Security允许你把你自己的过滤器添加到队列中,使用custom-filter元素,并且指定你的过滤器应该出现的位置:

Xml代码

   1. <beans:bean id="myFilter" class="com.mycompany.MySpecialAuthenticationFilter"> 
   2.     <custom-filter position="AUTHENTICATION_PROCESSING_FILTER"/> 
   3. </beans:bean> 

<beans:bean id="myFilter" class="com.mycompany.MySpecialAuthenticationFilter">
    <custom-filter position="AUTHENTICATION_PROCESSING_FILTER"/>
</beans:bean>



不仅如此,你还可以使用after或before属性,如果你想把你的过滤器添加到队列中另一个过滤器的前面或后面。 可以分别在position属性使用"FIRST"或"LAST"来指定你想让你的过滤器出现在队列元素的前面或后面。

这个特性或许能够在一定程度上弥补Spring Security的死板规定,而在之后的应用中,我也会把它作为切入点,对资源进行管理。

另外,我需要补充一点的是,对于在http/intercept-url中没有进行定义的URL,将会默认使用系统内置的过滤器链进行权限认证。所以,你并不需要在http/intercept-url中额外定义一个类似/**的匹配规则。

使用数据库对用户和权限进行管理

一般来说,我们都有使用数据库对用户和权限进行管理的需求,而不会把用户写死在配置文件里。所以,我们接下来就重点讨论使用数据库对用户和权限进行管理的方法。

用户和权限的关系设计

在此之前,我们首先需要讨论一下用户(User)和权限(Role)之间的关系。Spring Security在默认情况下,把这两者当作一对多的关系进行处理。所以,在Spring Security中对这两个对象所采用的表结构关系大概像这样:

Java代码

   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. ); 

CREATE TABLE users (
  username VARCHAR(50) NOT NULL PRIMARY KEY,
  password VARCHAR(50) NOT NULL,
  enabled BIT NOT NULL
);

CREATE TABLE authorities (
  username VARCHAR(50) NOT NULL,
  authority VARCHAR(50) NOT NULL
);



不过这种设计方式在实际生产环境中基本上不会采用。一般来说,我们会使用逻辑主键ID来标示每个User和每个 Authorities(Role)。而且从典型意义上讲,他们之间是一个多对多的关系,我们会采用3张表来表示,下面是我在MySQL中建立的3张表的 schema示例:
Java代码

   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; 

CREATE TABLE `user` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(255) default NULL,
  `password` varchar(255) default NULL,
  `disabled` int(1) NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `role` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(255) default NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `user_role` (
  `user_id` int(11) NOT NULL,
  `role_id` int(11) NOT NULL,
  PRIMARY KEY  (`user_id`,`role_id`),
  UNIQUE KEY `role_id` (`role_id`),
  KEY `FK143BF46AF6AD4381` (`user_id`),
  KEY `FK143BF46A51827FA1` (`role_id`),
  CONSTRAINT `FK143BF46A51827FA1` FOREIGN KEY (`role_id`) REFERENCES `role` (`id`),
  CONSTRAINT `FK143BF46AF6AD4381` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;



通过配置SQL来模拟用户和权限

有了数据库的表设计,我们就可以在Spring Security中,通过配置SQL,来模拟用户和权限,这依然通过<authentication-provider>来完成:

Xml代码

   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> 

<authentication-provider>
    <jdbc-user-service data-source-ref="dataSource"
    users-by-username-query="SELECT U.username, U.password, U.accountEnabled AS 'enabled' FROM User U where U.username=?"
    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=?"/>
</authentication-provider>



这里给出的是一个使用SQL进行模拟用户和权限的示例。其中你需要为运行SQL准备相应的dataSource。这个dataSource应该对应于Spring中的某个bean的定义。

从这段配置模拟用户和权限的情况来看,实际上Spring Security对于用户,需要username,password,accountEnabled三个字段。对于权限,它需要的是username和authority2个字段。

也就是说,如果我们能够通过其他的方式,模拟上面的这些对象,并插入到Spring Security中去,我们同样能够实现用户和权限的认证。接下来,我们就来看看我们如何通过自己的实现,来完成这件事情。

通过扩展Spring Security的默认实现来进行用户和权限的管理

事实上,Spring Security提供了2个认证的接口,分别用于模拟用户和权限,以及读取用户和权限的操作方法。这两个接口分别是:UserDetails和UserDetailsService。

Java代码

   1. public interface UserDetails extends Serializable { 
   2.      
   3.     GrantedAuthority[] getAuthorities(); 
   4.  
   5.     String getPassword(); 
   6.  
   7.     String getUsername(); 
   8.  
   9.     boolean isAccountNonExpired(); 
  10.  
  11.     boolean isAccountNonLocked(); 
  12.  
  13.     boolean isCredentialsNonExpired(); 
  14.  
  15.     boolean isEnabled(); 
  16. } 

public interface UserDetails extends Serializable {
   
    GrantedAuthority[] getAuthorities();

    String getPassword();

    String getUsername();

    boolean isAccountNonExpired();

    boolean isAccountNonLocked();

    boolean isCredentialsNonExpired();

    boolean isEnabled();
}



Java代码

   1. public interface UserDetailsService { 
   2.     UserDetails loadUserByUsername(String username) 
   3.         throws UsernameNotFoundException, DataAccessException; 
   4. } 

public interface UserDetailsService {
    UserDetails loadUserByUsername(String username)
        throws UsernameNotFoundException, DataAccessException;
}



非常清楚,一个接口用于模拟用户,另外一个用于模拟读取用户的过程。所以我们可以通过实现这两个接口,来完成使用数据库对用户和权限进行管理的需求。在这里,我将给出一个使用Hibernate来定义用户和权限之间关系的示例。

1. 定义User类和Role类,使他们之间形成多对多的关系
Java代码

   1. @Entity 
   2. @Proxy(lazy = false) 
   3. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
   4. public class User { 
   5.      
   6.     private static final long serialVersionUID = 8026813053768023527L; 
   7.  
   8.     @Id 
   9.     @GeneratedValue 
  10.     private Integer id; 
  11.      
  12.     private String name; 
  13.      
  14.     private String password; 
  15.      
  16.     private boolean disabled; 
  17.      
  18.     @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER) 
  19.     @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id")) 
  20.     @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
  21.     private Set<Role> roles; 
  22.  
  23.         // setters and getters 
  24. } 

@Entity
@Proxy(lazy = false)
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class User {
 
 private static final long serialVersionUID = 8026813053768023527L;

    @Id
 @GeneratedValue
 private Integer id;
 
 private String name;
 
 private String password;
 
 private boolean disabled;
 
 @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER)
    @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id"))
    @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
 private Set<Role> roles;

        // setters and getters
}



Java代码

   1. @Entity 
   2. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
   3. public class Role { 
   4.      
   5.     @Id 
   6.     @GeneratedValue 
   7.     private Integer id; 
   8.      
   9.     private String name; 
  10.          
  11.         // setters and getters 
  12. } 

@Entity
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class Role {
 
 @Id
 @GeneratedValue
 private Integer id;
 
 private String name;
       
        // setters and getters
}



请注意这里的Annotation的写法。同时,我为User和Role之间配置了缓存。并且将他们之间的关联关系设置的lazy属性设置成false,从而保证在User对象取出之后的使用不会因为脱离session的生命周期而产生lazy loading问题。

2. 使User类实现UserDetails接口

接下来,我们让User类去实现UserDetails接口:

Java代码

   1. @Entity 
   2. @Proxy(lazy = false) 
   3. @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
   4. public class User implements UserDetails { 
   5.      
   6.     private static final long serialVersionUID = 8026813053768023527L; 
   7.  
   8.     @Id 
   9.     @GeneratedValue 
  10.     private Integer id; 
  11.      
  12.     private String name; 
  13.      
  14.     private String password; 
  15.      
  16.     private boolean disabled; 
  17.      
  18.     @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER) 
  19.     @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id")) 
  20.     @Cache(usage = CacheConcurrencyStrategy.READ_WRITE) 
  21.     private Set<Role> roles; 
  22.      
  23.     /**
  24.      * The default constructor
  25.      */ 
  26.     public User() { 
  27.          
  28.     } 
  29.  
  30.     /* (non-Javadoc)
  31.      * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
  32.      */ 
  33.     public GrantedAuthority[] getAuthorities() { 
  34.         List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size()); 
  35.         for(Role role : roles) { 
  36.             grantedAuthorities.add(new GrantedAuthorityImpl(role.getName())); 
  37.         } 
  38.         return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]); 
  39.     } 
  40.  
  41.     /* (non-Javadoc)
  42.      * @see org.springframework.security.userdetails.UserDetails#getPassword()
  43.      */ 
  44.     public String getPassword() { 
  45.         return password; 
  46.     } 
  47.  
  48.     /* (non-Javadoc)
  49.      * @see org.springframework.security.userdetails.UserDetails#getUsername()
  50.      */ 
  51.     public String getUsername() { 
  52.         return name; 
  53.     } 
  54.  
  55.     /* (non-Javadoc)
  56.      * @see org.springframework.security.userdetails.UserDetails#isAccountNonExpired()
  57.      */ 
  58.     public boolean isAccountNonExpired() { 
  59.         return true; 
  60.     } 
  61.  
  62.     /* (non-Javadoc)
  63.      * @see org.springframework.security.userdetails.UserDetails#isAccountNonLocked()
  64.      */ 
  65.     public boolean isAccountNonLocked() { 
  66.         return true; 
  67.     } 
  68.  
  69.     /* (non-Javadoc)
  70.      * @see org.springframework.security.userdetails.UserDetails#isCredentialsNonExpired()
  71.      */ 
  72.     public boolean isCredentialsNonExpired() { 
  73.         return true; 
  74.     } 
  75.  
  76.     /* (non-Javadoc)
  77.      * @see org.springframework.security.userdetails.UserDetails#isEnabled()
  78.      */ 
  79.     public boolean isEnabled() { 
  80.         return !this.disabled; 
  81.     } 
  82.        
  83.       // setters and getters 
  84. } 

@Entity
@Proxy(lazy = false)
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public class User implements UserDetails {
 
 private static final long serialVersionUID = 8026813053768023527L;

    @Id
 @GeneratedValue
 private Integer id;
 
 private String name;
 
 private String password;
 
 private boolean disabled;
 
 @ManyToMany(targetEntity = Role.class, fetch = FetchType.EAGER)
    @JoinTable(name = "user_role", joinColumns = @JoinColumn(name = "user_id"), inverseJoinColumns = @JoinColumn(name = "role_id"))
    @Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
 private Set<Role> roles;
 
 /**
  * The default constructor
  */
 public User() {
 
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
  */
 public GrantedAuthority[] getAuthorities() {
  List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
     for(Role role : roles) {
      grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
     }
        return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#getPassword()
  */
 public String getPassword() {
  return password;
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#getUsername()
  */
 public String getUsername() {
  return name;
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#isAccountNonExpired()
  */
 public boolean isAccountNonExpired() {
  return true;
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#isAccountNonLocked()
  */
 public boolean isAccountNonLocked() {
  return true;
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#isCredentialsNonExpired()
  */
 public boolean isCredentialsNonExpired() {
  return true;
 }

 /* (non-Javadoc)
  * @see org.springframework.security.userdetails.UserDetails#isEnabled()
  */
 public boolean isEnabled() {
  return !this.disabled;
 }
     
      // setters and getters
}



实现UserDetails接口中的每个函数,其实没什么很大的难度,除了其中的一个函数我需要额外强调一下:

Java代码

   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. } 

/* (non-Javadoc)
 * @see org.springframework.security.userdetails.UserDetails#getAuthorities()
 */
public GrantedAuthority[] getAuthorities() {
 List<GrantedAuthority> grantedAuthorities = new ArrayList<GrantedAuthority>(roles.size());
    for(Role role : roles) {
     grantedAuthorities.add(new GrantedAuthorityImpl(role.getName()));
     }
        return grantedAuthorities.toArray(new GrantedAuthority[roles.size()]);
}



这个函数的实际作用是根据User返回这个User所拥有的权限列表。如果以上面曾经用过的例子来说,如果当前User是downpour,我需要得到ROLE_USER和ROLE_ADMIN;如果当前User是robbin,我需要得到ROLE_USER。

了解了含义,实现就变得简单了,由于User与Role是多对多的关系,我们可以通过User得到所有这个User所对应的Role,并把这些Role的name拼装起来返回。

由此可见,实现UserDetails接口,并没有什么神秘的地方,它只是实际上在一定程度上只是代替了使用配置文件的硬编码:

Xml代码

   1. <user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" /> 

<user name="downpour" password="downpour" authorities="ROLE_USER, ROLE_ADMIN" />


  评论这张
 
阅读(1443)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017