Spring官方网址：http://www.springsource.org/

spring-security下载地址：

http://static.springsource.org/spring-security/site/downloads.html

我以其自带的一个简单例子来介绍一下吧，因为这个例子配置不对的话极易报错（这个例子是个打包的War文件，但与文档中的又不一样，所以极易出错），我会对出现的错误给予出错原因及解决方法。

首先通过spring-security地址下载到最新版的spring-security-3.0.2.RELEASE.zip，然后解压开来，在解压开的目录dist中，你会看到如下一些文件：

看到spring-security-samples-tutorial-3.0.2.RELEASE.war了吗？我就以这个为例，把这个包拷贝 到你Web服务器（如Tomcat）的webapps目录下，启动服务器后，会生成一个spring-security-samples- tutorial-3.0.2.RELEASE项目，可以把名字改短一点方便访问，比如我这里改名为：spring-security，这样通过http://127.0.0.1/spring-security可以直接访问了。

进入目录WEB-INF，可以看到如上的一些文件，其中，applicationContext-security.xml是权限控制配置文件，所 有的权限控制都是在其中配置的，bank-servlet.xml是系统的上下文配置文件，可以在其中配置访问路径映射（类似于Struts-1.x中的 struts-config.xml或struts-2.x中的struts.xml文件），也可以在其中进行一些装配等工作，属于spring级的，与 安全配置没多大关系。

具体的文件内容我就不展示了，因为可以自己打开看，我这里只说要注意的一些地方：

1、在web.xml中的配置

服务启动时加载applicationContext-security.xml文件：

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>

/WEB-INF/applicationContext-security.xml

</param-value>

</context-param>

要过滤链接的形式

<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-class与Spring2.0的不同之处，如果你了解Spring2.0的话，的确，在Spring2.0中为：

<filter-name>acegiFilterChain</filter-name>

<filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>

这就是3.0与2.0改变很大的一个地方，2.0用的为Acegi，后来Acegi嵌入到了Spring中，成为了Spring Security，所以包的路径也都改变了！

2、在applicationContext-security.xml中的配置

				<http use-expressions="true">

<intercept-url pattern="/secure/extreme/**" access="hasRole('ROLE_SUPERVISOR')"/>

<intercept-url pattern="/secure/**" access="isAuthenticated()" />

<!-- Disable web URI authorization, as we're using <global-method-security> and have @Secured the services layer instead

<intercept-url pattern="/listAccounts.html" access="isRememberMe()" />

<intercept-url pattern="/post.html" access="hasRole('ROLE_TELLER')" />

-->

<intercept-url pattern="/**" access="permitAll" />

<form-login />

<logout />

<remember-me />

<!--

Uncomment to enable X509 client authentication support

<x509 />

-->

<!-- Uncomment to limit the number of sessions a user can have -->

<session-management invalid-session-url="/timeout.jsp">

<concurrency-control max-sessions="1" error-if-maximum-exceeded="true" />

</session-management>

</http>

上面这段是初用者比较容易出错的地方，这其实也是写这篇文章的主要原因之一，注意到第一行的黑体字：

<http use-expressions=”true”>

表示这里的配置可以使用一种表达式，这种表达式就是类似于isAuthenticated()这样的写法，在后面会看到与这种写法不一样但同样可以达到相同效果的写法。

intercept-url表示要拦截的url形式，比如

<intercept-url pattern=”/secure/**” access=”isAuthenticated()” />

表示根目录下的secure目录需要经过验证后才能访问的。

<form-login />是Spring Security自动为你生成的一个简陋的登录页面，即使你没有创建任何登录页面，当然你也可以修改，但不建议你修改，因为你可以不使用默认的，可以采用 如下方式：<form-login login-page=’/ login.html’/>自定义一个登录页面。

其他的说明可以参考一个翻译的中文文档：

http://www.family168.com/tutorial/springsecurity3/html/ns-config.html

3、容易出错的地方

在上面的翻译文档（也是翻译自官方文档）或英文官方文档中，给出的与上面例子功能相似的说明大概是这样的：

  <http auto-config='true'>

    <intercept-url pattern="/**" access="ROLE_USER" />

  </http>

注意到与上面例子不同的地方了吗？

还是注意第一行，这回不是<http use-expressions=”true”>而是<http auto-config=’true’>了，而下面的配置

<intercept-url pattern=”/**” access=”ROLE_USER” />也与上面的写法不同，事实上如果是<http use-expressions=”true”>的话，这句access=”ROLE_USER”就是错的，正确的写法就应该为：hasRole(‘ROLE_USER’)。

这不得不说这是Spring Security的文档与例子不搭配的一个低级错误，因为当一个使用者在打开例子又看到文档说明时，他往往不知道这两者有何区别，就如同我刚使用的时候一样，我在使用<http use-expressions=”true”>的同时，将access=”ROLE_USER”这种写法也写了进来，结果可想而知，报了错！报错信息诸如：

org.apache.jasper.JasperException: java.lang.IllegalArgumentException: Failed to evaluate
expression 'ROLE_SUPERVISOR'

就是说use-expressions这种表示法是不认识access=”ROLE_USER”这种写法的，另外，当使用了<http use-expressions=”true”>时，一定要在配置中至少有一个符合use-expressions的表示法，否则就会报类似如下错误：

org.springframework.expression.spel.SpelEvaluationException: EL1008E:(pos 0): Field or property
'ROLE_SUPERVISOR' cannot be found on object of type 'org.springframework.security.web.access.
expression.WebSecurityExpressionRoot'

这个简单的配置例子大概就写这么多吧，最后说说我对Spring Security的看法，我个人觉得Spring Security的功能的确是很强大，考虑得也非常全面，几乎什么都想替使用者做完，但正是它的这点，我觉得倒是它的缺点，在我了解它并配置的过程中，我 个人觉得是非常复杂繁琐的，而且它现在的文档支持也并不好，正如上面所看到的一样，文档与例子中的写法都不一致。事实上，使用者并不希望它什么都做到，比 如它做的那个缺省登录页面，那个有意义吗？使用者比如我，其实就是希望一个很简单的权限判断，比如我打开某一个链接，然后你告诉我访问者有无权限访问，给 我返回一个类似true或false的结果就够了！至于其他的事情，我是如何的处理后续过程并不用Spring Security操心的，但很显然，子猴认为Spring Security在这点上做得并不好。

请注意：在2.0.0之前，Spring Security称为Acegi Security。老的Acegi Security提供了一个ACL模块，放在org.[acegisecurity/springsecurity].acl包下。这个老的现在已经被抛弃，并可能会在将来的Spring Security发行版中去掉。本章讨论新的ACL模块，官方推荐在Spring Security 2.0.0或更高版本中使用，它被置于org.springframework.security.acls包下。

复杂的应用常常会有需要定义访问权限——不只是在web请求和方法调用水平的控制。而是安全决议需要由“who (Authentication), where (MethodInvocation) and what (SomeDomainObject)”构成。也就是说，授权决议还要考虑方法调用中的实际域对象。

想象你正在为宠物诊所设计一个应用。你的基于Spring的应用主要有两组用户：宠物诊所的职员和客户。职员可以访问所有数据，但客户只能看到自己的客户记录。为了使这个例子更加有趣一点，你的客户可以让其它客户看他们的客户记录，例如他们"puppy preschool"的顾问或本地"Pony Club"的总裁。以Spring Security为基础，你有几个方式可以选择：

1.      编写一个自己的业务方法强制安全控制。你可以从Customer域对象中获取一个有访问权限用户的集合。可以用SecurityContextHolder.getContext().getAuthentication()来访问Authentication对象。

2.      编写一个 AccessDecisionVoter ，通过 Authentication 中储存的 GrantedAuthority[] 来控制安全检查。这意味着你的 AuthenticationManager 要把代表用户对域对象访问权限的 GrantedAuthority []填充到Authentication对象中去。

3.      编写一个AccessDecisionVoter来强制安全控制，直接打开目标Customer域对象。这意味着你的voter需要访问DAO来获取Customer对象。它接着会访问Customer对象集合来进行安全决议。

这些方法都是合情合理的。但是，第一个方法把你的授权检查和业务代码耦合到一起了。带来的主要问题包括提高了单元测试的难度，以及Customer授权逻辑很难在其它地方重用。从Authentication中获取GrantedAuthority[]是好的，但是面对数量很大的Customers时也是不行的。如果用户访问的Customers数量可能达到5,000个（在这个例子里不大可能，但是想象如果是一个很大的Pony Club里的兽医！），构建Authentication需要耗费的内存和时间可能不是你想要的。最后一种方法，编写代码从外部直接打开Customer，可能是这3个方法里最好的一个。它成功分离了关注点，也没有滥用内存和CPU，但还是效率很低，AccessDecisionVoter和最终的业务方法都要自己来调用DAO方法来获取Customer对象。一次业务方法调用要访问两次DAO很明显也不是你想要的。另外，上面提到的每一种方法你都要自己从头来编写自己的访问控制列表（ACL）持久化和业务逻辑。

幸运地，还有另外一个选择，下面我们来讨论一下这个选择。

24.2. 关键概念

Spring Security的ACL服务发布为spring-security-acl-xxx.jar。要使用Spring Security的域对象安全，你要把这个包加入到你的classpath中。

Spring Security的域对象安全以访问控制列表（ACL）为核心概念。你系统里的每个域对象都有自己的ACL，这个ACL记录了谁能或不能访问该域对象。Spring Security为你的应用带来3个主要的ACL相关能力。

·         提供一条可以高效地为你所有的域对象获取ACL条目（以及修改ACL）的途径；

·         提供一条在方法被调用前保证给定用户有访问你的域对象许可的途径；

·         提供一条在方法被调用后保证给定用户有访问你的域对象许可的途径；

正如第一点所说，Spring Security的ACL模块的主要能力之一是提供一个高性能获取ACL的途径。这个ACL repository的能力是非常重要的，因为你系统中的每一个域对象可能有若干个访问控制条目，每个ACL又可能是从其他ACL继承而来——树型结构（这很常用，Spring Security提供了很容易使用的支持）。Spring Security的ACL模块已经很小心的考虑了设计以满足高性能的ACL检索，它利用了可插接的缓存模块，死锁最小化的数据库更新，独立于ORM框架（我们使用直接JDBC），适当的包装，以及透明的数据库更新。

数据库的设计是以ACL模块的操作为中心的，让我们来看看该模块的实现里缺省使用的4个主要数据表。下面列出在一个典型的Spring Security ACL部署中的数据表，以数据量大小排序，行数最多的在最后面：

·         ACL_SID使我们能够在系统中唯一定义任何principal或authority（“SID”表示“Security IDentity”）。主键是ID，SID的文字表示，以及一个表示该SID是principal名还是GrantedAuthority的标识。每个principal或GrantedAuthority都有一个对应的记录。当在接受许可的上下文中使用的时候，SID通常被称为“接收者（recipient）”。

·         ACL_CLASS使我们能够在系统中唯一定义任何域对象类。主键是ID，然后是CLASS（java类名）。每个我们想要为其存储ACL许可的类有一个记录。

·         ACL_OBJECT_IDENTITY存储系统里每个域对象实例的信息。其中的列包括ID；一个到表ACL_CLASS 的外键OBJECT_ID_CLASS；一个使我们知道是为哪个ACL_CLASS类实例提供信息的唯一标识OBJECT_ID_IDENTITY；父对象，一个到ACL_SID的外键OWNER_SID表示该域对象的所有者；ENTRIES_INHERITING表示是否允许ACL条目从ACL父条目继承。

·         最后，ACL_ENTRY存储为每个recipient分配的权限。它的列包括一个到表ACL_OBJECT_IDENTITY的外键，recipient(例如一个到ACL_SID的外键)，是否需要审计，以及一个表示许可是授予还是拒绝的“整数位掩码”（许可可能包括多个方面，如view, edit, delete）。每个recipient对每个域对象的许可都有一个记录

上一段中提到，ACL系统使用了“整数位掩码”。不要担心，你不需要知道这些数字指向的具体位移来使用ACL系统，只需要知道我们有32个开关可以打开或关闭就可以了（一个int数值4个byte，共32个bits）。每一个位代表一个permission，缺省地，这些permission是：读（bit 0），写（bit 1），创建（bit 2），删除（bit 3）和管理（bit 4）。如果你要使用其他permission，可以很容易的实现自己的permission实例，ACL框架的其余部分不需要具备你定义的扩展的知识，即可完成操作。

明白我们采用这种“整数位掩码”对你的系统中域对象的数量是完全没有影响这一点是很重要的。我们的permission只能使用32个bit，但是你可以有数以十亿计的域对象（这也意味着会有数以十亿计的记录在ACL_OBJECT_IDENTITY表中，ACL_ENTRY表的记录则更多）。我们特别说明这一点是因为发现有些用户错误的以为我们要为每个潜在的域对象使用一个bit，这是不对的。

现在我们已经提供了一个ACL系统的基本概览，以及在表结构上看起来的样子，现在让我们来看看关键接口。关键接口列表如下：

·         Acl：每一个域对象有且仅有一个ACL的对象，它内部拥有AccessControlEntry，并知道Acl的所有者。Acl不直接指向域对象，而是指向一个ObjectIdentity。Acl是存储在ACL_OBJECT_IDENTITY表中的。

·         AccessControlEntry ：一个 Acl 包含多个 AccessControlEntry ，在ACL框架中，我们常常把它简称为ACE。每个ACE都指向一组Permission，Sid和Acl。ACE可以是granting或non-granting的，同时包含有审计的相关设置。ACE保存在ACL_ENTRY表中。

·         Permission ： Permission 表示一个不可变的位掩码，并为位掩码机制和信息输出提供方便的功能。上面提到的 5 个基本的 Permission (bits 0 到 4)包含在BasePermission类中。

·         Sid ： ACL 模块需要参照到 principal 和 GrantedAuthority[] 。 Sid 接口提供实际安全对象（如 principal, role, group 等等）和 Acl 中实际内容的间接联系，简称“安全身份”。普通的实现包括有 PrincipalSid （在 Authentication 中表示一个 principal ）和 GrantedAuthoritySid 。安全身份信息放在 ACL_SID表中。

·         ObjectIdentity ： ACL 模块中，内部用 ObjectIdentity 来表示每个域对象。缺省的实现是 ObjectIdentityImpl 。

·         AclService ：用于获取 ObjectIdentity 适用的 Acl 。在包含的实现（ JdbcAclService ）中，获取操作委派给 LookupStrategy 。 LookupStrategy 为获取 ACL 信息提供高度优化的策略，使用批获取（ BasicLookupStrategy ），也支持用户实现以提供更好的性能，例如层次化查询和类似的以性能为中心的非 ANSI SQL 能力。

·         MutableAclService ：允许修改 Acl 以便进行持久化，如果不是为了这个可以不必使用这个接口。

请注意我们提供的AclService和相关的数据库类都是使用ANSI SQL的。因此可以工作在所有主流数据库服务器上。在编写本文的时候，已经在Hypersonic SQL, PostgreSQL, Microsoft SQL Server 和 Oracle上测试过。

Spring Security发行包中有两个例子可以用来演示ACL模块。其一是Contacts例子，另外一个是Document Management System (DMS)。我们建议你仔细看看这些例子。

24.3. 入门

要开始使用Spring Security的ACL能力，你需要把你的ACL保存在某个地方。这要通过Spring实例化一个DataSource。然后该数据源被注入到JdbcMutableAclService和BasicLookupStrategy。后者提供了高性能的ACL获取能力，前者提供了可改变的能力。请参考发行包中任何一个例子来了解如何进行配置。你还需要往上一节中提到的四个表中填充数据（参考ACL例子看相关SQL语句）。

创建所需数据表并实例化JdbcMutableAclService后，你还要确认你的领域模型支持与Spring Security ACL包互操作。很可能ObjectIdentityImpl已经提供了足够的支持，它提供了多种可用的方式。大部分的域对象会包含一个public Serializable getId()方法。如果返回类型是long，或者和long兼容（例如int），你就不需要烦ObjectIdentity的问题了。ACL模块的很多部分都依赖于long identifier。如果没有使用long（或int，byte等），你有机会要重新实现几个类。我们不打算在Spring Security ACL模块中支持非long identifier，因为long和所有的数据库sequence兼容，也是最为常用的identifier数据类型，同时有足够的长度支持通常的应用场景。

下面的代码展示如何创建一个Acl，或修改一个已存在的Acl：

				// Prepare the information we'd like in our access control entry (ACE)
		

				ObjectIdentity oi = new ObjectIdentityImpl(Foo.class, new Long(44));
		

				Sid sid = new PrincipalSid("Samantha");
		

				Permission p = BasePermission.ADMINISTRATION;
		

				// Create or update the relevant ACL
		

				MutableAcl acl = null;
		

				try {
		

				 acl = (MutableAcl) aclService.readAclById(oi);
		

				} catch (NotFoundException nfe) {
		

				 acl = aclService.createAcl(oi);
		

				}
		

				// Now grant some permissions via an access control entry (ACE)
		

				acl.insertAce(acl.getEntries().length, p, sid, true);
		

				aclService.updateAcl(acl);
		

在上面的例子中，我们获取的ACL是和一个标识（identifer）为44的"Foo"域对象联系在一起的。我们增加一个ACE以便一个叫"Samantha"的principal能"administer"该对象。除了insertAce方法，这段代码不需要再多加说明。它的第一个参数是新的ACE要插入到Acl的什么位置。上面的例子中，我们把它放到最后。最后一个参数是一个表示该ACE授权或拒绝的boolean值。大部分时候应该为授权（true），但是如果为拒绝（false），该permission会被有效的关闭。

Spring Security没有在DAO或repository中为自动创建、更新或删除ACL提供任何特别集成。你要为域对象编写像上面这样的代码。在你的业务层中使用AOP来自动集成ACL信息和你业务层操作是值得考虑的。我们发现这是一种很有效的方式。