spring security与cas 集成（中）续

继上一个篇

spring security与cas 集成（中）

 所述，本文我们进行spring security的资源管理的扩展，从上篇的spring-security.xml的配置文件中我们可以清晰的看到关于用户的管理，就是
     <user-service id="userService">
        <user name="scott" password="scott" authorities="ROLE_USER" />

    </user-service>

这个配置中，一共有两个方面的用户信息，一是用户的基本信息，比如name,password; 二是这个用户的基本权限，或者说是这个用户被赋的权限。而对于系统的资源管理，我们并不十分的清楚spring security是如何管理的，但是我们也能够猜测到是在这个配置中：

<http entry-point-ref="casEntryPoint" >
     <intercept-url pattern="/**" access="ROLE_USER" />
        <custom-filter ref="requestSingleLogoutFilter" before="LOGOUT_FILTER" />
        <custom-filter ref="singleLogoutFilter" before="CAS_FILTER" />
        <custom-filter ref="casAuthenticationFilter" position="CAS_FILTER" />
        <logout logout-success-url="/cas-logout.jsp" />
    </http>
的 <intercept-url pattern="/**" access="ROLE_USER" /> 这个配置来管理的，
为了更清楚的让大家有个直观的认识，现在变换一个配置，以助于后面的理解（如果你有一个web工程，能够按照我现在配置运行起来，那么你后续会更
容易理解）.
如何变换配置呢？将
<http entry-point-ref="casEntryPoint" >
     <intercept-url pattern="/**" access="ROLE_USER" />
        <custom-filter ref="requestSingleLogoutFilter" before="LOGOUT_FILTER" />
        <custom-filter ref="singleLogoutFilter" before="CAS_FILTER" />
        <custom-filter ref="casAuthenticationFilter" position="CAS_FILTER" />
        <logout logout-success-url="/cas-logout.jsp" />
    </http>
变为：
    <http entry-point-ref="casEntryPoint">
        <custom-filter ref="requestSingleLogoutFilter" before="LOGOUT_FILTER" />
        <custom-filter ref="singleLogoutFilter" before="CAS_FILTER" />
        <custom-filter ref="casAuthenticationFilter" position="CAS_FILTER" />
        <custom-filter ref="fsi" before="FILTER_SECURITY_INTERCEPTOR" />
        <logout logout-success-url="/cas-logout.jsp" />
    </http>
    <b:bean id="fsi"
        class="org.springframework.security.web.access.intercept.FilterSecurityInterceptor">
        <b:property name="authenticationManager" ref="authenticationManager" />
        <b:property name="accessDecisionManager" ref="affirmativeBased" />
        <b:property name="securityMetadataSource" >
             <filter-invocation-definition-source>
                   <intercept-url pattern="/**" access="ROLE_USER" />
             </filter-invocation-definition-source>
        </b:property>
    </b:bean>
    <b:bean class="org.springframework.security.access.vote.AffirmativeBased"
        id="affirmativeBased">
        <b:property name="decisionVoters">
            <b:list>
                <b:ref bean="roleVoter" />
            </b:list>
        </b:property>
    </b:bean>
    <b:bean id="roleVoter" class="org.springframework.security.access.vote.RoleVoter"/>
其他不变，变更完毕。
这个变更之后的配置与原配置是等价（至少在功能上这样，要想更好的理解这个配置的更改，则需详细的理解spring security的filter chain）。但是更改之后的配置让我们更容易去理解spring security是如何管理资源。如何去理解呢？我们可以进行猜测，即
系统在启动的时候，会加载fsi这个bean,并解析相应的资源管理规则，<intercept-url pattern="/**" access="ROLE_USER" /> 即访问任何资源需要有ROLE_USER角色才可以。而当用户scott,初次访问系统时，由于web.xml中所配置的springSecurityFilterChain,会拦截相应的访问地址，让用户重定向到cas server去进行用户认证，当认证成功之后，系统会加载
  <user-service id="userService">
        <user name="scott" password="scott" authorities="ROLE_USER" />
    </user-service>
  解析用户的基本信息，及用户的权限。当用户scott访问一个资源，则系统根据request 请求信息，获取相关资源的信息，根据这个信息获取到这个资源需要哪些权限（在我们这个配置中，访问任何资源只需要ROLE_USER即可），然后与用户的权限进行对比，满足相应的规则则认为能够访问，否则不能访问相应的资源（在本文的配置中

是对于资源需要的角色列表中，只要有一个用户满足，即可访问这个资源，即roleVoter的配置）。

如何后续我们需要将资源,用户存入数据库，则只需要向spring-security提供两个的信息，一是资源及访问资源所需的角色；二是用户基本信息及用户所拥有的角色（或称为权限）。关于这个扩展我们在下篇来完成。