Spring Security详细配置文档格式.docx
《Spring Security详细配置文档格式.docx》由会员分享，可在线阅读，更多相关《Spring Security详细配置文档格式.docx（64页珍藏版）》请在冰点文库上搜索。
3.
<
filter-name>
springSecurityFilterChain<
/filter-name>
4.
filter-class>
org.springframework.web.filter.DelegatingFilterProxy<
/filter-class>
5.<
/filter>
6.<
filter-mapping>
7.
8.
url-pattern>
/*<
/url-pattern>
9.<
/filter-mapping>
--SpringsecurityFilter-->
<
这个Filter会拦截所有的URL请求，并且对这些URL请求进行SpringSecurity的验证。
注意，springSecurityFilterChain这个名称是由命名空间默认创建的用于处理web安全的一个内部的bean的id。
所以你在你的Spring配置文件中，不应该再使用这个id作为你的bean。
与Acegi的配置不同，Acegi需要自行声明一个Spring的bean来作为Filter的实现，而使用SpringSecurity后，无需再额外定义bean，而是使用<
http>
元素进行配置。
2.使用最小的<
配置
http
auto-config='
true'
>
2.
intercept-url
pattern="
/**"
access="
ROLE_USER"
/>
3.<
/http>
httpauto-config='
intercept-urlpattern="
access="
/>
这段配置表示：
我们要保护应用程序中的所有URL，只有拥有ROLE_USER角色的用户才能访问。
你可以使用多个<
intercept-url>
元素为不同URL的集合定义不同的访问需求，它们会被归入一个有序队列中，每次取出最先匹配的一个元素使用。
所以你必须把期望使用的匹配条件放到最上边。
3.配置UserDetailsService来指定用户和权限
接下来，我们来配置一个UserDetailsService来指定用户和权限：
authentication-provider>
user-service>
user
name="
downpour"
password="
authorities="
ROLE_USER,
ROLE_ADMIN"
robbin"
5.
QuakeWang"
6.
/user-service>
/authentication-provider>
username="
password="
authorities="
ROLE_USER,ROLE_ADMIN"
在这里，downpour拥有ROLE_USER和ROLE_ADMIN的权限，robbin拥有ROLE_USER权限，QuakeWang拥有ROLE_ADMIN的权限
4.小结
有了以上的配置，你已经可以跑简单的SpringSecurity的应用了。
只不过在这里，我们还缺乏很多基本的元素，所以我们尚不能对上面的代码进行完整性测试。
如果你具备Acegi的知识，你会发现，有很多Acegi中的元素，在SpringSecurity中都没有了，这些元素包括：
表单和基本登录选项、密码编码器、Remember-Me认证等等。
接下来，我们就来详细剖析一下SpringSecurity中的这些基本元素。
剖析基本配置元素
1.有关auto-config属性
在上面用到的auto-config属性，其实是下面这些配置的缩写：
form-login
anonymous
http-basic
logout
remember-me
8.<
form-login/>
anonymous/>
http-basic/>
logout/>
remember-me/>
这些元素分别与登录认证，匿名认证，基本认证，注销处理和remember-me对应。
他们拥有各自的属性，可以改变他们的具体行为。
这样，我们在Acegi中所熟悉的元素又浮现在我们的面前。
只是在这里，我们使用的是命名空间而已。
2.与Acegi的比较
我们仔细观察一下没有auto-config的那段XML配置，是不是熟悉多了？
让我们来将基于命名空间的配置与传统的Acegi的bean的配置做一个比较，我们会发现以下的区别：
1）基于命名空间的配置更加简洁，可维护性更强
例如，基于命名空间进行登录认证的配置代码，可能像这样：
login-page="
/login.jsp"
authentication-failure-url="
/login.jsp?
error=true"
default-target-url="
/work"
form-loginlogin-page="
authentication-failure-url="
default-target-url="
如果使用老的Acegi的Bean的定义方式，可能像这样：
bean
id="
authenticationProcessingFilter"
class="
org.acegisecurity.ui.webapp.AuthenticationProcessingFilter"
property
authenticationManager"
ref="
authenticationFailureUrl"
value="
error=1"
defaultTargetUrl"
filterProcessesUrl"
9.
/j_acegi_security_check"
10.
rememberMeServices"
11.<
/bean>
beanid="
class="
propertyname="
ref="
value="
value="
ref="
这样的例子很多，有兴趣的读者可以一一进行比较。
2）基于命名空间的配置，我们无需再担心由于过滤器链的顺序而导致的错误
以前，Acegi在缺乏默认内置配置的情况下，你需要自己来定义所有的bean，并指定这些bean在过滤器链中的顺序。
一旦顺序错了，很容易发生错误。
而现在，过滤器链的顺序被默认指定，你不需要在担心由于顺序的错误而导致的错误。
3.过滤器链在哪里
到目前为止，我们都还没有讨论过整个SpringSecurity的核心部分：
过滤器链。
在原本Acegi的配置中，我们大概是这样配置我们的过滤器链的：
filterChainProxy"
org.acegisecurity.util.FilterChainProxy"
filterInvocationDefinitionSource"
value>
CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
PATTERN_TYPE_APACHE_ANT
/common/**=#NONE#
/css/**=#NONE#
/images/**=#NONE#
/js/**=#NONE#
11.
/login.jsp=#NONE#
12.
/**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,securityContextHolderAwareRequestFilter,exceptionTranslationFilter,filterSecurityInterceptor
13.
/value>
14.
/property>
15.<
<
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
其中，每个过滤器链都将对应于Spring配置文件中的bean的id。
现在，在SpringSecurity中，我们将看不到这些配置，这些配置都被内置在<
节点中。
让我们来看看这些默认的，已经被内置的过滤器：
这些过滤器已经被Spring容器默认内置注册，这也就是我们不再需要在配置文件中定义那么多bean的原因。
同时，过滤器顺序在使用命名空间的时候是被严格执行的。
它们在初始化的时候就预先被排好序。
不仅如此，SpringSecurity规定，你不能替换那些<
元素自己使用而创建出的过滤器，比如HttpSessionContextIntegrationFilter,ExceptionTranslationFilter或FilterSecurityInterceptor。
当然，这样的规定是否合理，有待进一步讨论。
因为实际上在很多时候，我们希望覆盖过滤器链中的某个过滤器的默认行为。
而SpringSecurity的这种规定在一定程度上限制了我们的行为。
不过SpringSecurity允许你把你自己的过滤器添加到队列中，使用custom-filter元素，并且指定你的过滤器应该出现的位置：
beans:
myFilter"
com.mycompany.MySpecialAuthenticationFilter"
custom-filter
position="
AUTHENTICATION_PROCESSING_FILTER"
/beans:
bean>
class="
custom-filterposition="
不仅如此，你还可以使用after或before属性，如果你想把你的过滤器添加到队列中另一个过滤器的前面或后面。
可以分别在position属性使用"
FIRST"
或"
LAST"
来指定你想让你的过滤器出现在队列元素的前面或后面。
这个特性或许能够在一定程度上弥补SpringSecurity的死板规定，而在之后的应用中，我也会把它作为切入点，对资源进行管理。
另外，我需要补充一点的是，对于在http/intercept-url中没有进行定义的URL，将会默认使用系统内置的过滤器链进行权限认证。
所以，你并不需要在http/intercept-url中额外定义一个类似/**的匹配规则。
使用数据库对用户和权限进行管理
一般来说，我们都有使用数据库对用户和权限进行管理的需求，而不会把用户写死在配置文件里。
所以，我们接下来就重点讨论使用数据库对用户和权限进行管理的方法。
用户和权限的关系设计
在此之前，我们首先需要讨论一下用户（User）和权限（Role）之间的关系。
SpringSecurity在默认情况下，把这两者当作一对多的关系进行处理。
所以，在SpringSecurity中对这两个对象所采用的表结构关系大概像这样：
Java代码
1.CREATE
TABLE
users
（
username
VARCHAR（50）
NOT
NULL
PRIMARY
KEY,
password
NULL,
enabled
BIT
NULL
5.）;
7.CREATE
authorities
authority
10.）;
CREATETABLEusers（
usernameVARCHAR（50）NOTNULLPRIMARYKEY,
passwordVARCHAR（50）NOTNULL,
enabledBITNOTNULL
）;
CREATETABLEauthorities（
usernameVARCHAR（50）NOTNULL,
authorityVARCHAR（50）NOTNULL
不过这种设计方式在实际生产环境中基本上不会采用。
一般来说，我们会使用逻辑主键ID来标示每个User和每个Authorities（Role）。
而且从典型意义上讲，他们之间是一个多对多的关系，我们会采用3张表来表示，下面是我在MySQL中建立的3张表的schema示例：
`user`
`id`
int（11）
auto_increment,
`name`
varchar（255）
default
`password`
`disabled`
int
（1）
KEY
（`id`）
7.）
ENGINE=InnoDB
DEFAULT
CHARSET=utf8;
9.CREATE
`role`
13.）
15.CREATE
`user_role`
16.
`user_id`
17.
`role_id`
18.
（`user_id`,`role_id`）,
19.
UNIQUE
（`role_id`）,
20.
`FK143BF46AF6AD4381`
（`user_id`）,
21.
`FK143BF46A51827FA1`
22.
CONSTRAINT
FOREIGN
（`role_id`）
REFERENCES
（`id`）,
23.
升级会员 