Spring Security学习笔记

      看了一个星期的Spring Security源码，应该说对控制URL级别的访问控制的认识是有80,90%了，这里把自己的一些记录给贴出来，分享是一方面，保存也是一方面。好了不说了，看下面具体分析了：

URL资源控制访问处理流程：

数据准备 ( 顺序不一定是按照下面来的 ) ：

第一步：用户登录的时候根据用户名从数据库中查出用户所具有的 GrantedAuthority[] 信息，将它复制给 Authentication 对象 (Authentication 中有一个 GrantedAuthority[] 的属性 ) ，权限信息都封装成了 GrantedAuthorityImpl 的对象。

简单的描述一下关系就是：

 

当然存的是 GrantedAuthorityImpl 对象，也就是说 ROLE_ADMIN 这些值都被进行封装了一下。

看一下顺序图：

 
 

 

  第二步：从数据库中查出资源与权限的对应信息，以 map 的形式保存，比如像这样：

 

注意从数据库中取出数据的第一次封装就是封装成下面的这种形式，权限都是以 ”,” 分隔的。

接下来进行第二步封装：

对 resourceMap 进行再次处理，主要是对上面的权限信息封装成 ConfigAttributeDefinition 对象，但是上面都是以 ”,” 分隔的字符串的形式，而我们查看 API 发现 ConfigAttributeDefinition 虽然有这样的构造函数，但是要求的是 a single attribute ：

public ConfigAttributeDefinition

(String

 attribute)

Creates a ConfigAttributeDefinition containing a single attribute

这时候我们就交给一个 ConfigAttributeEditor 的类进行处理：

它里面有这个方法：

            setValue ( new ConfigAttributeDefinition(StringUtils.commaDelimitedListToStringArray (s)));

看到这个没有

StringUtils.commonDelimitedListToStringArray(s) 没有，就用了这个。这样我们就通过再次构造得到了另外一个 Map

requestMap ，它存的就是这样的形式：

 

当然对以 map 中的 KEY ，也进行了封装处理，它们都被封装成了 RequestKey 对象的形式。

再通过提供 UrlMatcher 和 RequesetMap 我们构造了一个 DefaultFilterInvocationDefinitionSource 对象。

   在这里说一下，其实 ConfigAttributeDefinition 中保存的配置信息都存在一个 List 当中，而 List 当中存储的是 SecurityConfig 对象，而 SecurityConfig 对象是 ConfigAttribute 类型的。也就是所这样形式的配置信息：

ROLE_ADMIN,ROLE_USER 被处理成 String[] 形式存储到了 ConfigAttribute 对象中， ConfigAttribute 对象再存在 ConfigAttributeDefinition 对象的 List 属性中。

 

前期的准备工作算是做好了，现在进行相关处理了，这里我们主要使用的是 FilterSecurityInterceptor 来处理，我们给 FilterSecurityInterceptor 提供了我们已经准备好的这些东西，除了上面这两个以外还提供了一个 AccessDecisionManager( 决策管理者 ) ，这个是决定我们是否可以访问资源的决策器，当然使用的资源就是我们上面提供了这两个东西。

   当请求达到的时候，我们通过 FilterSecurityInterceptor 拦截到了请求，构造成了 FilterInvocation 对象，然后进行下面的处理：

第一步，通过这个 FilterInvocation 来取得 ConfigAttributeDefinition 对象，上面已经讲到对于资源和权限是以 map 形式存在的，并且权限信息是封装成了 ConfigAttributeDefinition 对象，

ConfigAttributeDefinition attr=objectObjectDefinitionSource().getAttributes(object); 通过 DefaultFilterInvocationDefinitionSource 类中的下面三个方法的顺序调用，我们就可以取得 URL 所对应的 ConfigAttributeDefinition 对象。

 

第二步：获得认证对象 :

Authentication authenticated=authenticateIfRequired() ，对于认证对象的获得这里就不再复述了文档中已经分析了。

现在 Authentication 和 ConfigAttributeDefinition 都已经准备好了，就可以进行决定是否可以访问了，这叫个 AccessDecisionManager 进行处理。

第三步：决策访问控制：

       accessDecisionManager.decide(authentication,filterInvocation,configAttributeDefinition);

这里提供一种处理方式：

 

 

  这里要说明一下关于没有权限之类的处理， Spring Security 是通过异常处理来实现的，捕捉异常根据异常信息跳转页面。

 

  这里只对URL资源控制进行分析了，如果我理解错了，希望大家给我改正。

 

 

评论

10 楼 zjut_ww 2011-03-03  

kongruxi 写道

写得不错
之前的一个很小的项目里面用到spring security
如果LZ早写这文章就可以减少点我用在学习spring security的时间了，呵呵

因为我这个小项目权限那块用的是User<-->Role<-->Authority，所以spring security实际上只会关心User拥有什么Authority，反而没有Role这个概念，这样理解应该没错吧？
不知spring security是不是认为大多数系统只会用到User<-->Role这样的结构，所以权限的控制判断默认是ROLE_XXX这样，个人觉得看起来很怪

其实spring security中的role就是你口中的authority。完全可以符合你的三层的权限控制结构

9 楼 天下智能 2011-01-27  

最近做项目也用到了Spring Security，好好学习一下，自己一个人做！

8 楼 JavaStudyEye 2011-01-27  

  感谢楼主，最近也想找本书 下载到 psp 里面，看，，正好啊

不错 不错，顶

7 楼 kongruxi 2011-01-26  

写得不错
之前的一个很小的项目里面用到spring security
如果LZ早写这文章就可以减少点我用在学习spring security的时间了，呵呵

因为我这个小项目权限那块用的是User<-->Role<-->Authority，所以spring security实际上只会关心User拥有什么Authority，反而没有Role这个概念，这样理解应该没错吧？
不知spring security是不是认为大多数系统只会用到User<-->Role这样的结构，所以权限的控制判断默认是ROLE_XXX这样，个人觉得看起来很怪

6 楼 yanxia611 2011-01-26  

上传一个例子 我们看看

5 楼 ctfzh 2011-01-26  

spring security3.1.x跟3.x以及之前的版本也有变化的。当时我整权限这块整了好久，现在终于整出了。抽空的时候我也整理下笔记出来。

4 楼 glovebx 2011-01-26  

多谢lz，学习一下先。

3 楼 cwx714 2011-01-25  

Spring Security3已经有些变动了，org.springframework.security包下的类都转移到org.springframework.security.core了，Authentication 中的属性也变为Set<GrantedAuthority>了。

2 楼 tianhandigeng 2011-01-25  

重新弄了一下，图出来了，文档中也有这些描述

1 楼 neverforget 2011-01-25  

图片没显示出来

文档不错 打印出来 公车上看