命名空间被设计为捕获框架的最常见用途，并提供在应用程序中启用它们的简化和简洁语法。该设计基于框架内的大规模依赖关系，并且可以划分为以下区域：

我们将在下面的章节中介绍如何配置这些。

你需要做的第一件事是将下面的过滤器声明添加到 web.xml 文件中：

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

这为 Spring Security web 基础结构提供了一个钩子。DelegatingFilterProxy 是一个 Spring Framework 类，它委托给在应用程序上下文中定义为 Spring bean 的过滤器实现。在这种情况下，bean 被命名为 "springSecurityFilterChain"，它是由名称空间创建的内部基础设施 bean，用于处理 web 安全。注意，你不应该自己使用这个 bean 名称。一旦将此添加到 web.xml 中，就可以开始编辑应用程序上下文文件。Web 安全服务是使用 <http> 元素配置的。

开始启用 web 安全所需的全部是

<http>
<intercept-url pattern="/**" access="hasRole('USER')" />
<form-login />
<logout />
</http>

也就是说，我们希望应用程序中的所有 URL 都受到保护，要求角色 ROLE_USER 来访问它们，我们希望使用具有用户名和密码的表单登录到应用程序，并且我们希望注册一个注销 URL，该 URL 允许我们注销应用程序。<http> 元素是所有与 web 相关的命名空间功能的父级。<intercept-url> 元素使用 ant 路径样式语法定义与传入请求的 URL 匹配的模式 ^[2]。你还可以使用正则表达式匹配作为替代（参见命名空间附录以获得更多的详细信息）。access 属性定义与给定模式匹配的请求的访问要求。使用默认配置，这通常是一个逗号分隔的角色列表，其中必须允许用户发出请求。前缀 "ROLE_" ”是一个标记，表示应该与用户权限进行简单的比较。换言之，应该使用正常的基于角色的检查。Spring Security 中的访问控制不限于使用简单的角色（因此使用前缀来区分不同类型的安全属性）。稍后我们将看到解释如何改变脚注：[access 属性中逗号分隔值的解释取决于所使用的 –1— 的实现。在 Spring Security 3.0 中，属性也可以用 –2— 填充。

	Note
	你可以使用多个 <intercept-url> 元素来为不同的 URL 集定义不同的访问需求，但是将按照列出的顺序评估它们，并使用第一个匹配。所以你必须把最特定的匹配放在最上面。还可以添加 method 属性来将匹配限制为特定的 HTTP 方法（GET、POST、PUT 等）。

若要添加一些用户，可以直接在命名空间中定义一组测试数据：

<authentication-manager>
<authentication-provider>
	<user-service>
	<!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that
	NoOpPasswordEncoder should be used. This is not safe for production, but makes reading
	in samples easier. Normally passwords should be hashed using BCrypt -->
	<user name="jimi" password="{noop}jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
	<user name="bob" password="{noop}bobspassword" authorities="ROLE_USER" />
	</user-service>
</authentication-provider>
</authentication-manager>

这是一个安全的存储相同密码的例子。密码的前缀是 {bcrypt}，以指示 DelegatingPasswordEncoder（支持任何配置的 PasswordEncoder 进行匹配）使用 BCrypt 散列密码：

<authentication-manager>
<authentication-provider>
	<user-service>
	<user name="jimi" password="{bcrypt}$2a$10$ddEWZUl8aU0GdZPPpy7wbu82dvEw/pBpbRvDQRqA41y6mK1CoH00m"
			authorities="ROLE_USER, ROLE_ADMIN" />
	<user name="bob" password="{bcrypt}$2a$10$/elFpMBnAYYig6KRR5bvOOYeZr1ie1hSogJryg9qDlhza4oCw1Qka"
			authorities="ROLE_USER" />
	<user name="jimi" password="{noop}jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
	<user name="bob" password="{noop}bobspassword" authorities="ROLE_USER" />
	</user-service>
</authentication-provider>
</authentication-manager>

上面的配置定义了两个用户，它们的密码以及它们在应用程序中的角色（用于访问控制）。还可以使用 user-service 上的 properties 属性从标准属性文件加载用户信息。有关文件格式的更多详细信息，请参阅内存中的身份验证的章节。使用 <authentication-provider> 元素意味着身份验证管理器将使用用户信息来处理身份验证请求。你可以具有多个 <authentication-provider> 元素来定义不同的身份验证源，每个元素将依次进行咨询。

在这时，你应该能够启动你的应用程序，并且你将需要登录以继续进行。试一试，或者尝试使用项目附带的教程示例应用程序。

你可能想知道在提示你登录时，登录表单来自哪里，因为我们没有提到任何 HTML 文件或 JSP。事实上，由于我们没有显式地为登录页面设置 URL，Spring Security 根据启用的特性和为处理提交的登录的 URL 使用标准值，自动生成一个 URL，用户在登录后将发送到默认目标 URL，依此类推在。但是，命名空间提供了大量支持，允许你自定义这些选项。例如，如果你想提供自己的登录页面，可以使用：

<http>
<intercept-url pattern="/login.jsp*" access="IS_AUTHENTICATED_ANONYMOUSLY"/>
<intercept-url pattern="/**" access="ROLE_USER" />
<form-login login-page='/login.jsp'/>
</http>

还请注意，我们添加了一个额外的 intercept-url 元素，用于说明对登录页面的任何请求都应该对匿名用户可用 ^[3]，并且还添加了 AuthenticatedVoter 类，以获取关于如何处理值 IS_AUTHENTICATED_ANONYMOUSLY 的更多细节。否则，请求将被模式 /** 匹配，并且不可能访问登录页本身！这是一个常见的配置错误，将导致应用程序中的无限循环。如果你的登录页面看起来被保护，Spring Security 将在日志中发出警告。通过为模式定义一个单独的 http 元素，还可以使与特定模式匹配的所有请求完全绕过安全过滤器链，如下所示：

<http pattern="/css/**" security="none"/>
<http pattern="/login.jsp*" security="none"/>

<http use-expressions="false">
<intercept-url pattern="/**" access="ROLE_USER" />
<form-login login-page='/login.jsp'/>
</http>

在 Spring Security 3.1 中，现在可以使用多个 http 元素来为不同的请求模式定义单独的安全过滤器链配置。如果从 http 元素中省略了模式属性，则匹配所有请求。创建一个非安全模式是这种语法的一个简单示例，其中模式映射到一个空的过滤器链 ^[4]。我们将在安全过滤器链的章节中更详细地了解这个新的语法。

重要的是要认识到，这些不安全的请求将完全忽略任何与 Spring Security web 相关的配置或附加属性，例如 requires-channel，因此在请求期间你将无法访问关于当前用户的信息或调用安全方法。如果你仍然希望使用安全过滤器链，请使用 access='IS_AUTHENTICATED_ANONYMOUSLY' 作为替代方案。

如果要使用基础身份验证而不是表单登录，则将配置更改为

<http use-expressions="false">
<intercept-url pattern="/**" access="ROLE_USER" />
<http-basic />
</http>

然后，基础身份验证将优先，在用户试图访问受保护的资源时，它将用于提示登录。如果你希望使用表单登录，例如通过嵌入在另一个网页中的登录表单，则该配置中仍然可以使用表单登录。

<http pattern="/login.htm*" security="none"/>
<http use-expressions="false">
<intercept-url pattern='/**' access='ROLE_USER' />
<form-login login-page='/login.htm' default-target-url='/home.htm'
		always-use-default-target='true' />
</http>

logout 元素通过导航到特定 URL 添加对日志记录的支持。默认注销 URL 是 /logout，但可以使用 logout-url 属性将其设置为其它内容。关于其它可用属性的更多信息可以在命名空间附录中找到。

在实践中，你需要比添加到应用程序上下文文件中的几个名称更可扩展的用户信息源。最有可能的是，你希望将用户信息存储在像数据库或 LDAP 服务器之类的东西中。LDAP 命名空间配置是在 LDAP 章节中处理的，所以我们不会在这里覆盖它。如果你有 Spring Security 的 UserDetailsService 的自定义实现，在你的应用程序上下文中称为 "myUserDetailsService"，那么你可以使用

<authentication-manager>
	<authentication-provider user-service-ref='myUserDetailsService'/>
</authentication-manager>

如果你想使用一个数据库，那么你可以使用

<authentication-manager>
<authentication-provider>
	<jdbc-user-service data-source-ref="securityDataSource"/>
</authentication-provider>
</authentication-manager>

其中 "securityDataSource" 是应用程序上下文中 DataSource bean 的名称，指向包含标准 Spring Security 用户数据表的数据库。或者，你可以配置 Spring Security JdbcDaoImpl bean，并使用 user-service-ref 属性指向它：

<authentication-manager>
<authentication-provider user-service-ref='myUserDetailsService'/>
</authentication-manager>

<beans:bean id="myUserDetailsService"
	class="org.springframework.security.core.userdetails.jdbc.JdbcDaoImpl">
<beans:property name="dataSource" ref="dataSource"/>
</beans:bean>

还可以使用标准的 AuthenticationProvider beans，如下所示

<authentication-manager>
	<authentication-provider ref='myAuthenticationProvider'/>
</authentication-manager>

其中 myAuthenticationProvider 是应用程序上下文中实现 AuthenticationProvider 的 bean 的名称。可以使用多个 authentication-provider 元素，在这种情况下，将按照声明提供者的顺序查询提供者。有关如何使用命名空间配置 Spring Security AuthenticationManager 的更多详细信息，请参阅 小节 6.6, “身份验证管理器和命名空间”。

<beans:bean name="bcryptEncoder"
	class="org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder"/>

<authentication-manager>
<authentication-provider>
	<password-encoder ref="bcryptEncoder"/>
	<user-service>
	<user name="jimi" password="$2a$10$ddEWZUl8aU0GdZPPpy7wbu82dvEw/pBpbRvDQRqA41y6mK1CoH00m"
			authorities="ROLE_USER, ROLE_ADMIN" />
	<user name="bob" password="$2a$10$/elFpMBnAYYig6KRR5bvOOYeZr1ie1hSogJryg9qDlhza4oCw1Qka"
			authorities="ROLE_USER" />
	</user-service>
</authentication-provider>
</authentication-manager>

有关记住我命名空间配置的信息，请参阅单独的记住我章节。

如果你的应用程序同时支持 HTTP 和 HTTPS，并且你要求只能通过 HTTPS 访问特定的 URL，那么使用 <intercept-url> 上的 requires-channel 属性直接支持这一点：

<http>
<intercept-url pattern="/secure/**" access="ROLE_USER" requires-channel="https"/>
<intercept-url pattern="/**" access="ROLE_USER" requires-channel="any"/>
...
</http>

有了这种配置，如果用户试图使用 HTTP 访问 "/secure/**" 模式匹配的任何内容，则首先会将其重定向到 HTTPS URL ^[5]。可用的选项是 "http"、"https" 或 "any"。使用 "any" 值意味着可以使用 HTTP 或 HTTPS。

如果应用程序使用非标准端口进行 HTTP 和/或 HTTPS，则可以指定端口映射列表如下：

<http>
...
<port-mappings>
	<port-mapping http="9080" https="9443"/>
</port-mappings>
</http>

请注意，为了真正安全，应用程序根本不应该使用 HTTP 或者在 HTTP 和 HTTPS 之间切换。它应该从 HTTPS（用户输入 HTTPS URL）开始，并在整个过程中使用安全连接，以避免中间人攻击的任何可能性。

命名空间支持 OpenID 登录，而不是基于正常形式的登录，除了一个简单的更改：

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

然后你应该向 OpenID 提供者（例如 myopenid.com）注册自己，并将用户信息添加到内存中的 <user-service>：

<user name="http://jimi.hendrix.myopenid.com/" authorities="ROLE_USER" />

你应该能够使用 myopenid.com 站点进行身份验证。还可以通过在 openid-login 元素上设置 user-service-ref 属性来选择特定的 UserDetailsService bean 以使用 OpenID。有关的更多详细信息，请参阅上一节 身份验证提供者。注意，我们在上面的用户配置中省略了密码属性，因为这组用户数据仅用于为用户加载权限。在内部将生成一个随机密码，防止你在配置的其它地方意外地使用此用户数据作为身份验证源。

<openid-login>
<attribute-exchange>
	<openid-attribute name="email" type="http://axschema.org/contact/email" required="true"/>
	<openid-attribute name="name" type="http://axschema.org/namePerson"/>
</attribute-exchange>
</openid-login>

OpenIDAuthenticationToken token =
	(OpenIDAuthenticationToken)SecurityContextHolder.getContext().getAuthentication();
List<OpenIDAttribute> attributes = token.getAttributes();

有关如何自定义 header 元素的其它信息，请参阅参考文档的小节 21, 安全的 HTTP 响应报头部分。

如果你以前使用过 Spring Security，你将知道框架维护了一系列过滤器以便应用其服务。你可能希望将自己的过滤器添加到特定位置的堆栈中，或者使用 Spring Security 过滤器，其中当前没有命名空间配置选项（例如，CAS）。或者你可能希望使用标准命名空间过滤器的定制版本，比如由 <form-login> 元素创建的 UsernamePasswordAuthenticationFilter，它利用了显式使用 bean 的一些额外配置选项。由于过滤器链不直接暴露，你如何使用命名空间配置来实现这一点？

在使用命名空间时，过滤器的顺序总是严格执行的。在创建应用程序上下文时，过滤器 bean 根据命名空间处理代码进行排序，标准 Spring Security 过滤器在命名空间中都有别名和众所周知的位置。

	Note
	在以前的版本中，排序是在创建过滤器实例之后在应用程序上下文的后处理期间进行的。在版本 3.0+ 中，排序是在 bean 实例化级别之前完成的，在实例化类之前。这暗示了如何向堆栈中添加自己的过滤器，因为在解析 <http> 元素期间必须知道整个过滤器列表，所以语法在 3.0 中略有改变。

创建过滤器的过滤器、别名和命名空间元素/属性如表格 6.1, “标准过滤器别名和排序”所示。过滤器按它们在过滤器链中出现的顺序列出。

可以使用 custom-filter 元素和这些名称之一来指定筛选器应该出现在：

<http>
<custom-filter position="FORM_LOGIN_FILTER" ref="myFilter" />
</http>

<beans:bean id="myFilter" class="com.mycompany.MySpecialAuthenticationFilter"/>

如果希望在堆栈中的另一个过滤器之前或之后插入过滤器，也可以使用 after 或 before 属性。名称 "FIRST" 和 "LAST" 可以与 position 属性一起使用，以指示希望过滤器分别出现在整个堆栈之前或之后。

	Avoiding filter position conflicts
	如果插入自定义过滤器，该过滤器可能与由命名空间创建的标准过滤器占用的位置相同，那么重要的是不要错误地包含命名空间版本。删除任何要替换的功能创建过滤器的元素。 注意，不能替换通过使用 <http> 元素本身创建的过滤器 - SecurityContextPersistenceFilter、ExceptionTranslationFilter 或 FilterSecurityInterceptor。默认情况下添加了一些其它的过滤器，但你可以禁用它们。默认情况下添加 AnonymousAuthenticationFilter，除非禁用了会话固定保护，否则还将向过滤器链添加 SessionManagementFilter。

如果要替换需要身份验证入口点的命名空间过滤器（即，身份验证过程由未经身份验证的用户尝试访问安全资源触发），则还需要添加自定义入口点 bean。

这个元素用于在应用程序中启用基于注解的安全性（通过在元素上设置适当的属性），并且还用于将跨整个应用程序上下文应用的安全切入点声明分组在一起。仅声明一个 <global-method-security> 元素。下面的声明将支持 Spring Security 的 @Secured：

<global-method-security secured-annotations="enabled" />

将注解添加到方法（在类或接口上）将相应地限制对该方法的访问。Spring Security 的本地注解支持定义了该方法的一组属性。这些将传递给 AccessDecisionManager，以便它做出实际决策：

public interface BankService {

@Secured("IS_AUTHENTICATED_ANONYMOUSLY")
public Account readAccount(Long id);

@Secured("IS_AUTHENTICATED_ANONYMOUSLY")
public Account[] findAccounts();

@Secured("ROLE_TELLER")
public Account post(Account account, double amount);
}

JSR-250 注解可以启用使用

<global-method-security jsr250-annotations="enabled" />

这些是基于标准的，并且允许应用简单的基于角色的约束，但是没有强大的 Spring Security 的本地注解。若要使用基于表达式的新语法，将使用

<global-method-security pre-post-annotations="enabled" />

等效的 Java 代码将是

public interface BankService {

@PreAuthorize("isAnonymous()")
public Account readAccount(Long id);

@PreAuthorize("isAnonymous()")
public Account[] findAccounts();

@PreAuthorize("hasAuthority('ROLE_TELLER')")
public Account post(Account account, double amount);
}

如果需要定义超出根据用户权限列表检查角色名称的简单规则，那么基于表达式的注解是一个不错的选择。

	Note
	带注解的方法将只对定义为 Spring bean 的实例（在启用方法安全性的应用程序上下文中）进行保护。如果希望保护 Spring 没有创建的实例（例如，使用 new 操作符），则需要使用 AspectJ。

	Note
	你可以在同一个应用程序中启用多于一种类型的注解，但是对于任何接口或类，都应该只使用一种类型，否则行为将不被很好地定义。如果找到两个适用于特定方法的注解，那么将只应用其中一个。

<global-method-security>
<protect-pointcut expression="execution(* com.mycompany.*Service.*(..))"
	access="ROLE_USER"/>
</global-method-security>

如果需要使用更复杂的访问控制策略，那么很容易为方法和 Web 安全设置备选方案。

对于方法安全，可以通过将 global-method-security 的 access-decision-manager-ref 属性设置为应用程序上下文中适当的 AccessDecisionManager bean 的 id 来实现这一点：

<global-method-security access-decision-manager-ref="myAccessDecisionManagerBean">
...
</global-method-security>

web 安全的语法是相同的，但是在 http 元素上：

<http access-decision-manager-ref="myAccessDecisionManagerBean">
...
</http>