国产∨亚洲V天堂无码久久久,亚洲国产精品综合久久网络,国产亚洲蜜芽精品久久

Acegi Security -- Spring下最優秀的安全系統

一 Acegi安全系統介紹

Acegi是Spring Framework 下最成熟的安全系統，它提供了強大靈活的企業級安全服務，如完善的認證和授權機制，Http資源訪問控制，Method 調用訪問控制，Access Control List (ACL) 基于對象實例的訪問控制，Yale Central Authentication Service (CAS) 耶魯單點登陸，X509 認證，當前所有流行容器的認證適配器，Channel Security頻道安全管理等功能。

1.1 網站資源

官方網站     http://acegisecurity.sourceforge.net
論壇            http://forum.springframework.org/forumdisplay.php?f=33
Jira              http://opensource.atlassian.com/projects/spring/browse/SEC

1.2 多方面的安全控制粒度

URL 資源訪問控制
http://apps:8080/index.htm -> for public
http://apps:8080/user.htm -> for authorized user
方法調用訪問控制
public void getData() -> all user
public void modifyData() -> supervisor only
對象實例保護
order.getValue() < $100 -> all user
order.getValue() > $100 -> supervisor only

1.3 非入侵式安全架構

基于Servlet Filter和Spring aop, 使商業邏輯和安全邏輯分開，結構更清晰
使用Spring 來代理對象，能方便地保護方法調用

1.4 其它安全架構

Acegi只是安全框架之一，其實還存在其它優秀的安全框架可供選擇：

JAAS ：http://java.sun.com/products/jaas/
Seraph: http://opensource.atlassian.com/seraph/
jSai - Servlet Security : http://oss.ipov.org/jsai/
Gabriel : http://gabriel.codehaus.org/
JOSSO : http://www.josso.org/
Kasai: http://www.manentiasoftware.com/kasai/goToHome.action
jPAM : http://jpam.sourceforge.net/
OpenSAML : http://www.opensaml.org/

二 Acegi安全系統的配置

Acegi 的配置看起來非常復雜,但事實上在實際項目的安全應用中我們并不需要那么多功能,清楚的了解Acegi配置中各項的功能，有助于我們靈活的運用Acegi于實踐中。

2.1 在Web.xml中的配置

1) FilterToBeanProxy
　　Acegi通過實現了Filter接口的FilterToBeanProxy提供一種特殊的使用Servlet Filter的方式，它委托Spring中的Bean -- FilterChainProxy來完成過濾功能，這好處是簡化了web.xml的配置，并且充分利用了Spring IOC的優勢。FilterChainProxy包含了處理認證過程的filter列表，每個filter都有各自的功能。

    <filter>
        <filter-name>Acegi Filter Chain Proxy</filter-name>
        <filter-class>org.acegisecurity.util.FilterToBeanProxy</filter-class>
        <init-param>
            <param-name>targetClass</param-name>
            <param-value>org.acegisecurity.util.FilterChainProxy</param-value>
        </init-param>
    </filter>

2) filter-mapping
　　<filter-mapping>限定了FilterToBeanProxy的URL匹配模式,只有*.do和*.jsp和/j_acegi_security_check 的請求才會受到權限控制，對javascript,css等不限制。

   <filter-mapping>
      <filter-name>Acegi Filter Chain Proxy</filter-name>
      <url-pattern>*.do</url-pattern>
    </filter-mapping>
    
    <filter-mapping>
      <filter-name>Acegi Filter Chain Proxy</filter-name>
      <url-pattern>*.jsp</url-pattern>
    </filter-mapping>
    
    <filter-mapping>
      <filter-name>Acegi Filter Chain Proxy</filter-name>
      <url-pattern>/j_acegi_security_check</url-pattern>
    </filter-mapping>

3) HttpSessionEventPublisher
　　<listener>的HttpSessionEventPublisher用于發布HttpSessionApplicationEvents和HttpSessionDestroyedEvent事件給spring的applicationcontext。

    <listener>
        <listener-class>org.acegisecurity.ui.session.HttpSessionEventPublisher</listener-class>
    </listener>

2.2 在applicationContext-acegi-security.xml中

2.2.1 FILTER CHAIN

　　FilterChainProxy會按順序來調用這些filter,使這些filter能享用Spring ioc的功能, CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON定義了url比較前先轉為小寫， PATTERN_TYPE_APACHE_ANT定義了使用Apache ant的匹配模式

    <bean id="filterChainProxy" class="org.acegisecurity.util.FilterChainProxy">
        <property name="filterInvocationDefinitionSource">
            <value>
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT
               /**=httpSessionContextIntegrationFilter,authenticationProcessingFilter,
basicProcessingFilter,rememberMeProcessingFilter,anonymousProcessingFilter,
 exceptionTranslationFilter,filterInvocationInterceptor
            </value>
        </property>
    </bean>

2.2.2 基礎認證

1) authenticationManager
　　起到認證管理的作用，它將驗證的功能委托給多個Provider，并通過遍歷Providers, 以保證獲取不同來源的身份認證，若某個Provider能成功確認當前用戶的身份，authenticate()方法會返回一個完整的包含用戶授權信息的Authentication對象，否則會拋出一個AuthenticationException。
Acegi提供了不同的AuthenticationProvider的實現,如：
        DaoAuthenticationProvider 從數據庫中讀取用戶信息驗證身份
        AnonymousAuthenticationProvider 匿名用戶身份認證
        RememberMeAuthenticationProvider 已存cookie中的用戶信息身份認證
        AuthByAdapterProvider 使用容器的適配器驗證身份
        CasAuthenticationProvider 根據Yale中心認證服務驗證身份, 用于實現單點登陸
        JaasAuthenticationProvider 從JASS登陸配置中獲取用戶信息驗證身份
        RemoteAuthenticationProvider 根據遠程服務驗證用戶身份
        RunAsImplAuthenticationProvider 對身份已被管理器替換的用戶進行驗證
        X509AuthenticationProvider 從X509認證中獲取用戶信息驗證身份
        TestingAuthenticationProvider 單元測試時使用

每個認證者會對自己指定的證明信息進行認證，如DaoAuthenticationProvider僅對UsernamePasswordAuthenticationToken這個證明信息進行認證。

<bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
        <property name="providers">
            <list>
                <ref local="daoAuthenticationProvider"/>
                <ref local="anonymousAuthenticationProvider"/>
                <ref local="rememberMeAuthenticationProvider"/>
            </list>
        </property>
</bean>

2) daoAuthenticationProvider
　　進行簡單的基于數據庫的身份驗證。DaoAuthenticationProvider獲取數據庫中的賬號密碼并進行匹配，若成功則在通過用戶身份的同時返回一個包含授權信息的Authentication對象，否則身份驗證失敗，拋出一個AuthenticatiionException。

    <bean id="daoAuthenticationProvider" class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
        <property name="userDetailsService" ref="jdbcDaoImpl"/>
        <property name="userCache" ref="userCache"/>
        <property name="passwordEncoder" ref="passwordEncoder"/>
   </bean>

3) passwordEncoder
　　使用加密器對用戶輸入的明文進行加密。Acegi提供了三種加密器:
PlaintextPasswordEncoder—默認，不加密，返回明文.
ShaPasswordEncoder—哈希算法(SHA)加密
Md5PasswordEncoder—消息摘要(MD5)加密

<bean id="passwordEncoder" class="org.acegisecurity.providers.encoding.Md5PasswordEncoder"/>

4) jdbcDaoImpl
　　用于在數據中獲取用戶信息。 acegi提供了用戶及授權的表結構，但是您也可以自己來實現。通過usersByUsernameQuery這個SQL得到你的(用戶ID,密碼,狀態信息);通過authoritiesByUsernameQuery這個SQL得到你的(用戶ID,授權信息)

 <bean id="jdbcDaoImpl" class="org.acegisecurity.userdetails.jdbc.JdbcDaoImpl">
        <property name="dataSource" ref="dataSource"/>
        <property name="usersByUsernameQuery">
            <value>select loginid,passwd,1 from users where loginid = ?</value>
        </property>
        <property name="authoritiesByUsernameQuery">
            <value>select u.loginid,p.name from users u,roles r,permissions p,user_role ur,role_permis rp where u.id=ur.user_id and r.id=ur.role_id and p.id=rp.permis_id and
                r.id=rp.role_id and p.status='1' and u.loginid=?</value>
        </property>
</bean>

5) userCache　& resourceCache
　　緩存用戶和資源相對應的權限信息。每當請求一個受保護資源時，daoAuthenticationProvider就會被調用以獲取用戶授權信息。如果每次都從數據庫獲取的話，那代價很高，對于不常改變的用戶和資源信息來說，最好是把相關授權信息緩存起來。(詳見 2.6.3 資源權限定義擴展 )
userCache提供了兩種實現: NullUserCache和EhCacheBasedUserCache, NullUserCache實際上就是不進行任何緩存，EhCacheBasedUserCache是使用Ehcache來實現緩功能。

    <bean id="userCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
        <property name="cacheManager" ref="cacheManager"/>
        <property name="cacheName" value="userCache"/>
    </bean>
    <bean id="userCache" class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache" autowire="byName">
        <property name="cache" ref="userCacheBackend"/>
      </bean>
    <bean id="resourceCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
        <property name="cacheManager" ref="cacheManager"/>
        <property name="cacheName" value="resourceCache"/>
    </bean>
    <bean id="resourceCache" class="org.springside.modules.security.service.acegi.cache.ResourceCache" autowire="byName">
        <property name="cache" ref="resourceCacheBackend"/>
    </bean>

6) basicProcessingFilter
　　用于處理HTTP頭的認證信息，如從Spring遠程協議(如Hessian和Burlap)或普通的瀏覽器如IE,Navigator的HTTP頭中獲取用戶信息，將他們轉交給通過authenticationManager屬性裝配的認證管理器。如果認證成功，會將一個Authentication對象放到會話中，否則，如果認證失敗，會將控制轉交給認證入口點(通過authenticationEntryPoint屬性裝配)

    <bean id="basicProcessingFilter" class="org.acegisecurity.ui.basicauth.BasicProcessingFilter">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="authenticationEntryPoint" ref="basicProcessingFilterEntryPoint"/>
    </bean>

7) basicProcessingFilterEntryPoint
　　通過向瀏覽器發送一個HTTP401(未授權)消息，提示用戶登錄。
處理基于HTTP的授權過程，在當驗證過程出現異常后的"去向"，通常實現轉向、在response里加入error信息等功能。

 <bean id="basicProcessingFilterEntryPoint" class="org.acegisecurity.ui.basicauth.BasicProcessingFilterEntryPoint">
        <property name="realmName" value="SpringSide Realm"/>
</bean>

8) authenticationProcessingFilterEntryPoint
　　當拋出AccessDeniedException時，將用戶重定向到登錄界面。屬性loginFormUrl配置了一個登錄表單的URL,當需要用戶登錄時，authenticationProcessingFilterEntryPoint會將用戶重定向到該URL

 <bean id="authenticationProcessingFilterEntryPoint" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilterEntryPoint">
        <property name="loginFormUrl">
            <value>/security/login.jsp</value>
        </property>
        <property name="forceHttps" value="false"/>
</bean>

2.2.3 HTTP安全請求

1) httpSessionContextIntegrationFilter
　　每次request前 HttpSessionContextIntegrationFilter從Session中獲取Authentication對象，在request完后, 又把Authentication對象保存到Session中供下次request使用,此filter必須其他Acegi filter前使用，使之能跨越多個請求。

<bean id="httpSessionContextIntegrationFilter" class="org.acegisecurity.context.HttpSessionContextIntegrationFilter"></bean>
    <bean id="httpRequestAccessDecisionManager" class="org.acegisecurity.vote.AffirmativeBased">
        <property name="allowIfAllAbstainDecisions" value="false"/>
        <property name="decisionVoters">
            <list>
                <ref bean="roleVoter"/>
            </list>
        </property>
</bean>

2) httpRequestAccessDecisionManager
　　經過投票機制來決定是否可以訪問某一資源(URL或方法)。allowIfAllAbstainDecisions為false時如果有一個或以上的decisionVoters投票通過,則授權通過。可選的決策機制有ConsensusBased和UnanimousBased

    <bean id="httpRequestAccessDecisionManager" class="org.acegisecurity.vote.AffirmativeBased">
        <property name="allowIfAllAbstainDecisions" value="false"/>
        <property name="decisionVoters">
            <list>
                <ref bean="roleVoter"/>
            </list>
        </property>
    </bean>

3) roleVoter
　　必須是以rolePrefix設定的value開頭的權限才能進行投票,如AUTH_ , ROLE_

    <bean id="roleVoter" class="org.acegisecurity.vote.RoleVoter">
        <property name="rolePrefix" value="AUTH_"/>
   </bean>

4）exceptionTranslationFilter
　　異常轉換過濾器，主要是處理AccessDeniedException和AuthenticationException，將給每個異常找到合適的"去向"

   <bean id="exceptionTranslationFilter" class="org.acegisecurity.ui.ExceptionTranslationFilter">
        <property name="authenticationEntryPoint" ref="authenticationProcessingFilterEntryPoint"/>
    </bean>

5) authenticationProcessingFilter
　　和servlet spec差不多,處理登陸請求.當身份驗證成功時，AuthenticationProcessingFilter會在會話中放置一個Authentication對象，并且重定向到登錄成功頁面
         authenticationFailureUrl定義登陸失敗時轉向的頁面
         defaultTargetUrl定義登陸成功時轉向的頁面
         filterProcessesUrl定義登陸請求的頁面
         rememberMeServices用于在驗證成功后添加cookie信息

    <bean id="authenticationProcessingFilter" class="org.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="authenticationFailureUrl">
            <value>/security/login.jsp?login_error=1</value>
        </property>
        <property name="defaultTargetUrl">
            <value>/admin/index.jsp</value>
        </property>
        <property name="filterProcessesUrl">
            <value>/j_acegi_security_check</value>
        </property>
        <property name="rememberMeServices" ref="rememberMeServices"/>
    </bean>

6) filterInvocationInterceptor
　　在執行轉向url前檢查objectDefinitionSource中設定的用戶權限信息。首先，objectDefinitionSource中定義了訪問URL需要的屬性信息(這里的屬性信息僅僅是標志，告訴accessDecisionManager要用哪些voter來投票)。然后，authenticationManager掉用自己的provider來對用戶的認證信息進行校驗。最后，有投票者根據用戶持有認證和訪問url需要的屬性，調用自己的voter來投票，決定是否允許訪問。

    <bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
        <property name="objectDefinitionSource" ref="filterDefinitionSource"/>
    </bean>

7) filterDefinitionSource (詳見 2.6.3 資源權限定義擴展)
　　自定義DBFilterInvocationDefinitionSource從數據庫和cache中讀取保護資源及其需要的訪問權限信息

<bean id="filterDefinitionSource" class="org.springside.modules.security.service.acegi.DBFilterInvocationDefinitionSource">
        <property name="convertUrlToLowercaseBeforeComparison" value="true"/>
        <property name="useAntPath" value="true"/>
        <property name="acegiCacheManager" ref="acegiCacheManager"/>
</bean>

2.2.4 方法調用安全控制

(詳見 2.6.3 資源權限定義擴展)

1) methodSecurityInterceptor
　　在執行方法前進行攔截，檢查用戶權限信息
2) methodDefinitionSource
　　自定義MethodDefinitionSource從cache中讀取權限

   <bean id="methodSecurityInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
        <property name="objectDefinitionSource" ref="methodDefinitionSource"/>
    </bean>
    <bean id="methodDefinitionSource" class="org.springside.modules.security.service.acegi.DBMethodDefinitionSource">
        <property name="acegiCacheManager" ref="acegiCacheManager"/>
    </bean>

2.3 Jcaptcha驗證碼

采用 http://jcaptcha.sourceforge.net 作為通用的驗證碼方案，請參考SpringSide中的例子，或網上的：
http://www.coachthrasher.com/page/blog?entry=jcaptcha_with_appfuse。

差沙在此過程中又發現acegi logout filter的錯誤，進行了修正。

另外它默認提供的圖片比較難認，我們custom了一個美觀一點的版本。

三 Acegi安全系統擴展

相信side對Acegi的擴展會給你耳目一新的感覺,提供完整的擴展功能,管理界面,中文注釋和靠近企業的安全策略。side只對Acegi不符合企業應用需要的功能進行擴展,盡量不改動其余部分來實現全套權限管理功能,以求能更好地適應Acegi升級。

3.1 基于角色的權限控制(RBAC)

Acegi 自帶的 sample 表設計很簡單: users表{username,password,enabled} authorities表{username,authority},這樣簡單的設計無法適應復雜的權限需求,故SpringSide選用RBAC模型對權限控制數據庫表進行擴展。 RBAC引入了ROLE的概念,使User(用戶)和Permission(權限)分離,一個用戶擁有多個角色,一個角色擁有有多個相應的權限,從而減少了權限管理的復雜度,可更靈活地支持安全策略。

同時,我們也引入了resource(資源)的概念,一個資源對應多個權限，資源分為ACL,URL,和FUNTION三種。注意，URL和FUNTION的權限命名需要以AUTH_開頭才會有資格參加投票, 同樣的ACL權限命名需要ACL_開頭。

3.2 管理和使用EhCache

3.2.1 設立緩存

在SpringSide里的 Acegi 擴展使用 EhCache 就作為一種緩存解決方案,以緩存用戶和資源的信息和相對應的權限信息。

首先需要一個在classpath的 ehcache.xml 文件，用于配置 EhCache。

<ehcache>
       <defaultCache
            maxElementsInMemory="10000"
            eternal="false"
            overflowToDisk="true"
            timeToIdleSeconds="0"
            timeToLiveSeconds="0"
            diskPersistent="false"
            diskExpiryThreadIntervalSeconds= "120"/> 
    <!-- acegi cache-->
    <cache name="userCache"
           maxElementsInMemory="10000"
           eternal="true"
           overflowToDisk= "true"/>
    <!-- acegi cache-->   
    <cache name="resourceCache"
           maxElementsInMemory="10000"
           eternal="true"
           overflowToDisk="true"/>
</ehcache>

maxElementsInMemory設定了允許在Cache中存放的數據數目，eternal設定Cache是否會過期，overflowToDisk設定內存不足的時候緩存到硬盤，timeToIdleSeconds和timeToLiveSeconds設定緩存游離時間和生存時間，diskExpiryThreadIntervalSeconds設定緩存在硬盤上的生存時間，注意當eternal="true"時，timeToIdleSeconds，timeToLiveSeconds和diskExpiryThreadIntervalSeconds都是無效的。

<defaultCache>是除制定的Cache外其余所有Cache的設置，針對Acegi 的情況, 專門設置了userCache和resourceCache，都設為永不過期。在applicationContext-acegi-security.xml中相應的調用是

<bean id="userCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
        <property name="cacheManager" ref="cacheManager"/>
        <property name="cacheName" value="  userCache"/>
    </bean>
    <bean id="userCache" class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache" autowire="byName">
        <property name="cache" ref="userCacheBackend"/>
    </bean>
    <bean id="resourceCacheBackend" class="org.springframework.cache.ehcache.EhCacheFactoryBean">
        <property name="cacheManager" ref="cacheManager"/>
        <property name="cacheName" value="  resourceCache"/>
    </bean>
    <bean id="resourceCache" class="org.springside.modules.security.service.acegi.cache.ResourceCache" autowire="byName">
        <property name="cache" ref="resourceCacheBackend"/>
    </bean>
<bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"/>

"cacheName" 就是設定在ehcache.xml 中相應Cache的名稱。
userCache使用的是Acegi 的EhCacheBasedUserCache(實現了UserCache接口), resourceCache是SpringSide的擴展類
public interface UserCache   {
    public UserDetails getUserFromCache   (String username);
    public void putUserInCache   (UserDetails user);
    public void removeUserFromCache   (String username);
}
public class ResourceCache   {
    public ResourceDetails getAuthorityFromCache   (String resString) {...   }
    public void putAuthorityInCache   (ResourceDetails resourceDetails) {...  }
    public void removeAuthorityFromCache   (String resString) {... }
    public List getUrlResStrings() {... }
    public List getFunctions() {.. }
}
UserCache 就是通過EhCache對UserDetails 進行緩存管理, 而ResourceCache 是對ResourceDetails 類進行緩存管理
public interface UserDetails   extends Serializable {
    public boolean isAccountNonExpired();
    public boolean isAccountNonLocked();
    public GrantedAuthority[] getAuthorities();
    public boolean isCredentialsNonExpired();
    public boolean isEnabled();
    public String getPassword();
    public String getUsername();
}
public interface ResourceDetails   extends Serializable {
    public String getResString();
    public String getResType();
    public GrantedAuthority[] getAuthorities();
}
UserDetails 包含用戶信息和相應的權限，ResourceDetails 包含資源信息和相應的權限。
public interface GrantedAuthority     {
    public String getAuthority   ();
}
     GrantedAuthority 就是權限信息，在Acegi 的 sample 里GrantedAuthority 的信息如ROLE_USER, ROLE_SUPERVISOR, ACL_CONTACT_DELETE, ACL_CONTACT_ADMIN等等，網上也有很多例子把角色作為GrantedAuthority ，但事實上看看ACL 就知道， Acegi本身根本就沒有角色這個概念，GrantedAuthority 包含的信息應該是權限，對于非ACL的權限用 AUTH_ 開頭更為合理, 如SpringSide里的 AUTH_ADMIN_LOGIN, AUTH_BOOK_MANAGE 等等。 
3.2.2 管理緩存
     使用AcegiCacheManager對userCache和resourceCache進行統一緩存管理。當在后臺對用戶信息進行修改或賦權的時候, 在更新數據庫同時就會調用acegiCacheManager相應方法, 從數據庫中讀取數據并替換cache中相應部分,使cache與數據庫同步。
public class AcegiCacheManager extends BaseService {
    private ResourceCache resourceCache   ;
    private UserCache userCache   ;
    /**
     * 修改User時更改userCache  
     */ 
    public void modifyUserInCache   (User user, String orgUsername) {...    }
    /**
     * 修改Resource時更改resourceCache  
     */ 
    public void modifyResourceInCache   (Resource resource, String orgResourcename) {...    }
    /**
     *   修改權限時同時修改userCache和resourceCache
     */ 
    public void modifyPermiInCache   (Permission permi, String orgPerminame) {...  }
    /**
     * User授予角色時更改userCache  
     */
    public void authRoleInCache   (User user) {...    }
    /**
     * Role授予權限時更改userCache和resourceCache  
     */ 
    public void authPermissionInCache   (Role role) {...  }
    /**
     * Permissioni授予資源時更改resourceCache  
     */ 
    public void authResourceInCache   (Permission permi) {...  }
    /**
     *   初始化userCache
     */ 
    public void initUserCache   () {...  }
    /**
     *   初始化resourceCache
     */ 
    public void initResourceCache   () {... }
    /**
     *  獲取所有的url資源
     */ 
    public List getUrlResStrings   () {...  }
    /**
     * 獲取所有的Funtion資源  
     */ 
    public List getFunctions   () {...  }
    /**
     * 根據資源串獲取資源  
     */ 
    public ResourceDetails getAuthorityFromCache   (String resString) {...  }
    
 ......


}
 
3.3 資源權限定義擴展
     Acegi給出的sample里,資源權限對照關系是配置在xml中的,試想一下如果你的企業安全應用有500個用戶,100個角色權限的時候,維護這個xml將是個繁重無比的工作,如何動態更改用戶權限更是個頭痛的問題。
   <bean id="contactManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
      <property name="authenticationManager"><ref bean="authenticationManager"/></property>
      <property name="accessDecisionManager"><ref local="businessAccessDecisionManager"/></property>
      <property name="afterInvocationManager"><ref local="afterInvocationManager"/></property>
      <property name="objectDefinitionSource">
         <value>
            sample.contact.ContactManager.create=ROLE_USER
            sample.contact.ContactManager.getAllRecipients=ROLE_USER
            sample.contact.ContactManager.getAll=ROLE_USER,AFTER_ACL_COLLECTION_READ
            sample.contact.ContactManager.getById=ROLE_USER,AFTER_ACL_READ
            sample.contact.ContactManager.delete=ACL_CONTACT_DELETE
            sample.contact.ContactManager.deletePermission=ACL_CONTACT_ADMIN
            sample.contact.ContactManager.addPermission=ACL_CONTACT_ADMIN
         </value>
      </property>
   </bean>
  <bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
      <property name="authenticationManager"><ref bean="authenticationManager"/></property>
      <property name="accessDecisionManager"><ref local="httpRequestAccessDecisionManager"/></property>
      <property name="objectDefinitionSource">
         <value>
       CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
       PATTERN_TYPE_APACHE_ANT
       /index.jsp=ROLE_ANONYMOUS,ROLE_USER
       /hello.htm=ROLE_ANONYMOUS,ROLE_USER
       /logoff.jsp=ROLE_ANONYMOUS,ROLE_USER
       /switchuser.jsp=ROLE_SUPERVISOR
       /j_acegi_switch_user=ROLE_SUPERVISOR
       /acegilogin.jsp*=ROLE_ANONYMOUS,ROLE_USER
       /**=ROLE_USER
         </value>
      </property>
   </bean>
 對如此不Pragmatic的做法,SpringSide進行了擴展, 讓Acegi 能動態讀取數據庫中的權限資源關系。
3.3.1 Aop Invocation Authorization
    <bean id="methodSecurityInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
        <property name="objectDefinitionSource" ref="methodDefinitionSource"/>
    </bean>
    <bean id="methodDefinitionSource" class="org.springside.security.service.acegi.DBMethodDefinitionSource">
        <property name="acegiCacheManager" ref="acegiCacheManager"/>
    </bean>
     研究下Aceig的源碼,ObjectDefinitionSource的實際作用是返回一個ConfigAttributeDefinition對象，而Acegi Sample 的方式是用MethodDefinitionSourceEditor把xml中的文本Function資源權限對應關系信息加載到MethodDefinitionMap ( MethodDefinitionSource 的實現類 )中, 再組成ConfigAttributeDefinition，而我們的擴展目標是從緩存中讀取信息來組成ConfigAttributeDefinition。
     MethodSecurityInterceptor是通過調用AbstractMethodDefinitionSource的lookupAttributes(method)方法獲取ConfigAttributeDefinition。所以我們需要實現自己的ObjectDefinitionSource，繼承AbstractMethodDefinitionSource并實現其lookupAttributes方法,從緩存中讀取資源權限對應關系組成并返回ConfigAttributeDefinition即可。SpringSide中的DBMethodDefinitionSource類的部分實現如下 :
public class DBMethodDefinitionSource extends AbstractMethodDefinitionSource {
......
    protected ConfigAttributeDefinition lookupAttributes(Method mi) {
        Assert.notNull(mi, "lookupAttrubutes in the DBMethodDefinitionSource is null");
        String methodString = mi.getDeclaringClass().getName() + "." + mi.getName();
        if (!acegiCacheManager.isCacheInitialized()) {
            //初始化Cache
            acegiCacheManager.initResourceCache();
        }
        //獲取所有的function
        List methodStrings = acegiCacheManager.getFunctions();
        Set auths = new HashSet();
        //取權限的合集
        for (Iterator iter = methodStrings.iterator(); iter.hasNext();) {
            String mappedName = (String) iter.next();
            if (methodString.equals(mappedName)
                    || isMatch(methodString, mappedName)) {
                ResourceDetails resourceDetails = acegiCacheManager.getAuthorityFromCache(mappedName);
                if (resourceDetails == null) {
                    break;
                }
                GrantedAuthority[] authorities = resourceDetails.getAuthorities();
                if (authorities == null || authorities.length == 0) {
                    break;
                }
                auths.addAll(Arrays.asList(authorities));
            }
        }
        if (auths.size() == 0)
            return null;
        ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor();
        String authoritiesStr = " ";
        for (Iterator iter = auths.iterator(); iter.hasNext();) {
            GrantedAuthority authority = (GrantedAuthority) iter.next();
            authoritiesStr += authority.getAuthority() + ",";
        }
        String authStr = authoritiesStr.substring(0, authoritiesStr.length() - 1);
        configAttrEditor.setAsText(authStr);
       //組裝并返回ConfigAttributeDefinition
        return (ConfigAttributeDefinition) configAttrEditor.getValue();
    }
    ......
}
要注意幾點的是: 
1) 初始化Cache是比較浪費資源的，所以SpringSide中除第一次訪問外的Cache的更新是針對性更新。
2) 因為method采用了匹配方式(詳見 isMatch() 方法) , 即對于*Book和save*這兩個資源來說，只要當前訪問方法是Book結尾或以save開頭都算匹配得上，所以應該取這些能匹配上的資源的相對應的權限的合集。
3) 使用ConfigAttributeEditor 能更方便地組裝ConfigAttributeDefinition。 
3.3.2 Filter Invocation Authorization
    <bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor">
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="httpRequestAccessDecisionManager"/>
        <property name="objectDefinitionSource" ref="filterDefinitionSource"/>
    </bean>

    <bean id="filterDefinitionSource" class="org.springside.security.service.acegi.DBFilterInvocationDefinitionSource">
        <property name="convertUrlToLowercaseBeforeComparison" value="true"/>
        <property name="useAntPath" value="true"/>
        <property name="acegiCacheManager" ref="acegiCacheManager"/>
    </bean>
     PathBasedFilterInvocationDefinitionMap和RegExpBasedFilterInvocationDefinitionMap都是 FilterInvocationDefinitionSource的實現類,當PATTERN_TYPE_APACHE_ANT字符串匹配上時時,FilterInvocationDefinitionSourceEditor 選用PathBasedFilterInvocationDefinitionMap 把xml中的文本URL資源權限對應關系信息加載。
     FilterSecurityInterceptor通過FilterInvocationDefinitionSource的lookupAttributes(url)方法獲取ConfigAttributeDefinition。 所以，我們可以通過繼承FilterInvocationDefinitionSource的抽象類AbstractFilterInvocationDefinitionSource，并實現其lookupAttributes方法,從緩存中讀取URL資源權限對應關系即可。SpringSide的DBFilterInvocationDefinitionSource類部分實現如下:
public class DBFilterInvocationDefinitionSource extends AbstractFilterInvocationDefinitionSource {

......
    public ConfigAttributeDefinition lookupAttributes(String url) {
        if (!acegiCacheManager.isCacheInitialized()) {
            acegiCacheManager.initResourceCache();
        }

        if (isUseAntPath()) {
            // Strip anything after a question mark symbol, as per SEC-161.
            int firstQuestionMarkIndex = url.lastIndexOf("?");
            if (firstQuestionMarkIndex != -1) {
                url = url.substring(0, firstQuestionMarkIndex);
            }
        }
        List urls = acegiCacheManager.getUrlResStrings();
        //URL資源倒敘排序
        Collections.sort(urls);
        Collections.reverse(urls);
        //是否先全部轉為小寫再比較
        if (convertUrlToLowercaseBeforeComparison) {
            url = url.toLowerCase();
        }
        GrantedAuthority[] authorities = new GrantedAuthority[0];
        for (Iterator iterator = urls.iterator(); iterator.hasNext();) {
            String resString = (String) iterator.next();
            boolean matched = false;
              //可選擇使用AntPath和Perl5兩種不同匹配模式   
            if (isUseAntPath()) {
                matched = pathMatcher.match(resString, url);
            } else {
                Pattern compiledPattern;
                Perl5Compiler compiler = new Perl5Compiler();
                try {
                    compiledPattern = compiler.compile(resString,
                            Perl5Compiler.READ_ONLY_MASK);
                } catch (MalformedPatternException mpe) {
                    throw new IllegalArgumentException(
                            "Malformed regular expression: " + resString);
                }
                matched = matcher.matches(url, compiledPattern);
            }
            if (matched) {
                ResourceDetails rd = acegiCacheManager.getAuthorityFromCache(resString);
                authorities = rd.getAuthorities();
                break;
            }
        }
        if (authorities.length > 0) {
            String authoritiesStr = " ";
            for (int i = 0; i < authorities.length; i++) {
                authoritiesStr += authorities[i].getAuthority() + ",";
            }
            String authStr = authoritiesStr.substring(0, authoritiesStr
                    .length() - 1);
            ConfigAttributeEditor configAttrEditor = new ConfigAttributeEditor();
            configAttrEditor.setAsText(authStr);
            return (ConfigAttributeDefinition) configAttrEditor.getValue();
        }
        return null;
    }

......
 }
繼承AbstractFilterInvocationDefinitionSource注意幾點：
1)  需要先把獲取回來的URL資源按倒序派序，以達到 a/b/c/d.* 在 a/.* 之前的效果(詳見 Acegi sample 的applicationContext-acegi-security.xml 中的filterInvocationInterceptor的注釋)，為的是更具體的URL可以先匹配上，而獲取具體URL的權限，如a/b/c/d.*權限AUTH_a, AUTH_b 才可查看,  a/.* 需要權限AUTH_a 才可查看，則如果當前用戶只擁有權限AUTH_b,則他只可以查看a/b/c/d.jsp 而不能察看a/d.jsp。
2) 基于上面的原因，故第一次匹配上的就是當前所需權限，而不是取權限的合集。
3) 可以選用AntPath 或 Perl5 的資源匹配方式，感覺AntPath匹配方式基本足夠。
4) Filter 權限控制比較適合于較粗顆粒度的權限，如設定某個模塊下的頁面是否能訪問等，對于具體某個操作如增刪修改，是否能執行，用Method  Invocation 會更佳些，所以注意兩個方面一起控制效果更好
 
3.4 授權操作
     RBAC模型中有不少多對多的關系，這些關系都能以一個中間表的形式來存放，而Hibernate中可以不建這中間表對應的hbm.xml , 以資源與權限的配置為例，如下:
<hibernate-mapping package="org.springside.modules.security.domain">
    <class name="Permission" table="PERMISSIONS" dynamic-insert="true" dynamic-update="true">
        <cache usage="nonstrict-read-write"/>
        <id name="id" column="ID">
            <generator class="native"/>
        </id>
        <property name="name" column="NAME" not-null="true"/>
        <property name="descn" column="DESCN"/>
        <property name="operation" column="OPERATION"/>
        <property name="status" column="STATUS"/>
        <set name="roles" table="ROLE_PERMIS" lazy="true" inverse="true" cascade="save-update" batch-size="5">
            <key>
                <column name="PERMIS_ID" not-null="true"/>
            </key>
            <many-to-many class="Role" column="ROLE_ID" outer-join="auto"/>
        </set>
        <set name="resources" table="PERMIS_RESC" lazy="true" inverse="false" cascade="save-update" batch-size="5">
            <key>
                <column name="PERMIS_ID" not-null="true"/>
            </key>
            <many-to-many class="Resource" column="RESC_ID"/>
        </set>
    </class>
</hibernate-mapping>
<hibernate-mapping package="org.springside.modules.security.domain">
    <class name="Resource" table="RESOURCES" dynamic-insert="true" dynamic-update="true">
        <cache usage="nonstrict-read-write"/>
        <id name="id" column="ID">
            <generator class="native"/>
        </id>
        <property name="name" column="NAME" not-null="true"/>
        <property name="resType" column="RES_TYPE" not-null="true"/>
        <property name="resString" column="RES_STRING" not-null="true"/>
        <property name="descn" column="DESCN"/>
        <set name="permissions" table="PERMIS_RESC" lazy="true" inverse="true" cascade="save-update" batch-size="5">
            <key>
                <column name="RESC_ID" not-null="true"/>
            </key>
            <many-to-many class="Permission" column="PERMIS_ID" outer-join="auto"/>
        </set>
    </class>
</hibernate-mapping>
配置時注意幾點:
1) 因為是分配某個權限的資源，所以權限是主控方，把inverse設為false，資源是被控方inverse設為true
2) cascade是"save-update"，千萬別配成delete
3) 只需要 permission.getResources().add(resource)， permission.getResources()..remove(resource) 即可很方便地完成授權和取消授權操作
 
四 Acegi ACL使用
4.1 基本概念
      在google中搜索'acl'會找到很多相關的介紹，而且涉及的范圍也特別廣泛。ACL是(Access Control List)的縮寫，顧名思義，ACL是‘訪問控制列表’的意思。通俗點說，ACL保存了所有用戶或角色對資源的訪問權限。最典型的ACL實現是流行操作系統(window, unix)的文件訪問控制系統，精確定義了某個用戶或角色對某個特定文件的讀、寫、執行等權限，更通俗的例子是可以定義某個管理員只能管一部分的訂單，而另一個管理員只能管另一部分的。
4.2 Acegi ACL配置
Acegi好早就實現了ACL（好像是0.5），但是使用起來確實有點麻煩，所以用的不是太廣泛。這里簡單的說明一下使用方法，希望有更多的朋友來試試。

首先要理解Acegi里面Voter的概念，ACL正是在一個Voter上擴展起來的。現來看一下AclVoter的配置。


    <bean id="aclBeanReadVoter" class="org.acegisecurity.vote.BasicAclEntryVoter">
        <property name="processConfigAttribute">
            <value>ACL_READ</value>
        </property>
        <property name="processDomainObjectClass">
            <value>org.springside.modules.security.acl.domain.AclDomainAware</value>
        </property>
        <property name="aclManager">
            <ref local="aclManager"/>
        </property>
        <property name="requirePermission">
            <list>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
            </list>
        </property>
    </bean>

    ACL_READ指的是這個Voter對哪些SecurityConfig起作用，我們可以把ACL_READ配置在想要攔截的Method上。比方說我們要攔截readOrder這個方法，以實現ACL控制，可以這樣配置。
orderManager.readOrder=ACL_READ
    
processDomainObjectClass指出哪些DomainObject是要進行ACL校驗的。
    
aclManager是一個比較重要的概念，主要負責在權限列表中根據用戶和DomainObject取得acl列表。
    
requirePermission指出要進行這個操作必須具備的acl權限，比方說read操作就必須有ADMINISTRATION或READ兩個權限。

其實整個過程看下來比較清晰，下面來看一下AclManager如何配置。

    <!-- ========= ACCESS CONTROL LIST LOOKUP MANAGER DEFINITIONS ========= -->

    <bean id="aclManager" class="org.acegisecurity.acl.AclProviderManager">
        <property name="providers">
            <list>
                <ref local="basicAclProvider"/>
            </list>
        </property>
    </bean>

    <bean id="basicAclProvider" class="org.acegisecurity.acl.basic.BasicAclProvider">
        <property name="basicAclDao">
            <ref local="basicAclExtendedDao"/>
        </property>
    </bean>

    <bean id="basicAclExtendedDao" class="org.acegisecurity.acl.basic.jdbc.JdbcExtendedDaoImpl">
        <property name="dataSource">
            <ref bean="dataSource"/>
        </property>
    </bean>

很明顯ACLManager繼承了Acegi的一貫風格，Provider可以提供多種取得ACL訪問列表的途徑，默認的是用basicAclProvider在數據庫中取得。既然提到了數據庫，那我們就來看一下Acegi默認提供的ACL在數據庫里的保存表結構：



    acl_object_identity表存放了所有受保護的domainObject的信息。其中object_identity字段保存了domainObject的class和id，默認的保存格式是：domainClass:domainObjectId。
    
acl_permission 就是ACL權限列表了，recipient 是用戶或角色信息，mask表示了這個用戶或角色對這個domainObject的訪問權限。注意這些信息的保存格式都是可以根據自己的需要改變的。

這樣讀取和刪除的時候Acegi就能很好的完成攔截工作，但是讀取一個List的時候，如何才能把該用戶不能操作的domainObject剔除掉呢？這就需要afterInvocationManager來完成這個工作。下面來看下配置：

    <!-- ============== "AFTER INTERCEPTION" AUTHORIZATION DEFINITIONS =========== -->

    <bean id="afterInvocationManager" class="org.acegisecurity.afterinvocation.AfterInvocationProviderManager">
        <property name="providers">
            <list>
                <ref local="afterAclCollectionRead"/>
            </list>
        </property>
    </bean>
    <!-- Processes AFTER_ACL_COLLECTION_READ configuration settings -->
    <bean id="afterAclCollectionRead" class="org.acegisecurity.afterinvocation.BasicAclEntryAfterInvocationCollectionFilteringProvider">
        <property name="aclManager">
            <ref local="aclManager"/>
        </property>
        <property name="requirePermission">
            <list>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.ADMINISTRATION"/>
                <ref local="org.acegisecurity.acl.basic.SimpleAclEntry.READ"/>
            </list>
        </property>
    </bean>

afterAclCollectionRead會在攔截的方法執行結束的時候執行。主要的作用就是在返回的List中挨個檢查domainObject的操作權限，然后根據requirePermission來剔除不符合的domainObject。
4.3 使用RuleEngine設置的ACL規則
在SpringSide里使用了RuleEngine來設置ACL規則，具體規則見
bookstore-sample\resources\rules\drl
 
五 FAQ 
5.1 FAQ

    Q:   能否脫離Spring框架來使用Acegi?
A:  雖然Acegi 沒有要求必須使用Spring Framework，但事實上Acegi很大程度上利用了Spring的IOC和AOP,很難脫離Spring的單獨使用。
    
Q:  Acegi有對xfire的支持嗎?
A: 有,詳見http://jira.codehaus.org/browse/XFIRE-389
    
Q: 為何無論怎么設置都返回到登陸頁面無法成功登陸?
A:  檢查登陸頁面或登陸失敗頁面是否只有ROLE_ANONYMOUS權限

5.2 Acegi 補習班
要了解Acegi,首先要了解以下幾個重要概念： 

    
    Authentication 
Authentication對象包含了principal, credentials 和 authorities(authorities要賦予給principal的),同時也可以包含一些附加的認證請求信息,如TCP/IP地址和Session id等。 
    

    SecurityContextHolder
SecurityContextHolder包含ThreadLocal私有屬性用于存取SecurityContext, SecurityContext包含Authentication私有屬性, 看以下一段程序
    

public void getSecurityContextInformations() {
  SecurityContext sc = SecurityContextHolder.getContext();
  Authentication auth = sc.getAuthentication();
  Object principal = auth.getPrincipal();
  if (principal instanceof UserDetails) {
   //用戶密碼
   String password = ((UserDetails) principal).getPassword();
   //用戶名稱
   String username = ((UserDetails) principal).getUsername();
   //用戶權限
   GrantedAuthority[] authorities = ((UserDetails) principal).getAuthorities();
   for (int i = 0; i < authorities.length; i++) {
    String authority = authorities[i].getAuthority();
   }
  }
  Object details = auth.getDetails();
  if (details instanceof WebAuthenticationDetails) {
   //用戶session id
   String SessionId = ((WebAuthenticationDetails) details).getSessionId();
  }
 }

    
    
AuthenticationManager
通過Providers驗證在當前 ContextHolder中的Authentication對象是否合法。
    
AccessDecissionManager
經過投票機制來審批是否批準操作
    
RunAsManager
當執行某個操作時,RunAsManager可選擇性地替換Authentication對象
    
Interceptors
攔截器(如FilterSecurityInterceptor,JoinPoint,MethodSecurityInterceptor等)用于協調授權,認證等操作


 
CREATE TABLE acl_object_identity (
id IDENTITY NOT NULL,
object_identity VARCHAR_IGNORECASE(250) NOT NULL,
parent_object INTEGER,
acl_class VARCHAR_IGNORECASE(250) NOT NULL,
CONSTRAINT unique_object_identity UNIQUE(object_identity),
FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id)
);
CREATE TABLE acl_permission (
id IDENTITY NOT NULL,
acl_object_identity INTEGER NOT NULL,
recipient VARCHAR_IGNORECASE(100) NOT NULL,
mask INTEGER NOT NULL,
CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient),
FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id)
);

posted on 2007-06-28 10:50 junky 閱讀(957) 評論(0) 編輯收藏所屬分類: security

新用戶注冊刷新評論列表


只有注冊用戶登錄后才能發表評論。




網站導航: 博客園 IT新聞 Chat2DB C++博客博問管理
相關文章: Windows下架設Subversion服務器(轉) CAS中使用自己的Credentials（轉） 14.1 Acegi眼中的領域對象 14.2 實施保護領域對象的重要步驟 Acegi Security -- Spring下最優秀的安全系統(轉) 在Acegi中使用ACL(轉) Acegi ACL使用說明 Acegi簡介 Acegi 參考手冊(V1.0.4) 翻譯 Acegi Security -- Spring下最優秀的安全系統

Junky's IT Notebook

導航

隨筆分類(224)

文章分類(5)

隨筆檔案(228)

文章檔案(7)

統計

留言簿(8)

積分與排名

WebSphere Studio

閱讀排行榜

評論排行榜

Acegi Security -- Spring下最優秀的安全系統

1.1 網站資源

1.2 多方面的安全控制粒度

1.3 非入侵式安全架構

1.4 其它安全架構

2.1 在Web.xml中的配置

2.2 在applicationContext-acegi-security.xml中

2.2.1 FILTER CHAIN

2.2.2 基礎認證

2.2.3 HTTP安全請求

2.2.4 方法調用安全控制

2.3 Jcaptcha驗證碼

3.1 基于角色的權限控制(RBAC)

3.2 管理和使用EhCache

3.2.1 設立緩存

3.2.2 管理緩存

3.3 資源權限定義擴展

3.3.1 Aop Invocation Authorization

3.3.2 Filter Invocation Authorization

3.4 授權操作

4.1 基本概念

4.2 Acegi ACL配置

4.3 使用RuleEngine設置的ACL規則

5.1 FAQ

5.2 Acegi 補習班