狂奔 lion

Spring Security 2 中動態(tài)角色權(quán)限的實(shí)現(xiàn)

安全框架的主體包括兩部分即驗(yàn)權(quán)和授權(quán)。Spring Security2可以很好的實(shí)現(xiàn)這兩個過程。Spring Security2對其前身acegi最大的改進(jìn)是提供了自定義的配置標(biāo)簽，通過Security的命名空間定義了http和authentication-provider等標(biāo)簽，這樣做的好處是極大地簡化了框架的配置，并很好地隱藏了框架實(shí)現(xiàn)的細(xì)節(jié)，在配置的表述上也更清晰，總體上提高了框架的易用性。

然而，該框架默認(rèn)的權(quán)限配置方式在xml中，又因?yàn)樾掳姹倦[藏了實(shí)現(xiàn)細(xì)節(jié)，在動態(tài)權(quán)限的擴(kuò)展上，能力變小了。在驗(yàn)權(quán)過程中，遇到的問題不多。但在授權(quán)時，如果是acegi，人們可以通過繼承AbstractFilterInvocationDefinitionSource類實(shí)現(xiàn)在授權(quán)（即資源角色和用戶角色的匹配）前，針對資源的角色的獲取。而新版本因?yàn)橛眯聵?biāo)簽進(jìn)行了整合，這個過程被默認(rèn)的類實(shí)現(xiàn)隱藏掉了，包括過濾器，資源獲取和角色定義等過程都由框架來實(shí)現(xiàn)，于是很多人在使用Spring Security2時也想通過改動DefaultFilterInvocationDefinitionSource對資源的獲取來實(shí)現(xiàn)數(shù)據(jù)庫或文件中的動態(tài)的角色。不過這樣的改動侵入性比較高，而且還保留了acegi的痕跡，也違背了開閉的原則。

其實(shí)，我們完全可以通過Spring Security2 accessManager提供的自定義投票機(jī)制來解決這個問題，這樣既不影響現(xiàn)有的基于URL的配置，還可以加入自己的動態(tài)的權(quán)限配置。

         其實(shí)現(xiàn)策略如下：

1 定義類DynamicRoleVoter實(shí)現(xiàn)AccessDecisionVoter，注入實(shí)現(xiàn)接口DynamicRoleProvider（用來定義獲取角色的方法）的提供動態(tài)角色的類

2 在兩個supports方法中返回true

3 在vote方法中，有三個參數(shù)(Authentication authentication, Object object,

ConfigAttributeDefinition config) 通過第一個獲取用戶的權(quán)限集合，第二個可以獲取到資源對象，進(jìn)而通過DynamicRoleProvider獲取到角色集合進(jìn)行匹配。

4 在配置文件中加入DynamicRoleVoter，如下：

<beans:bean id="accessDecisionManager" class="org.springframework.security.vote.AffirmativeBased">
<beans:property name="decisionVoters">
<beans:list>
<beans:bean class="org.springframework.security.vote.RoleVoter" />
<beans:bean class="org.springframework.security.vote.AuthenticatedVoter" />
<beans:bean class="DynamicRoleVoter">
    <beans:property name="dynamicRoleProvider">
        <beans:ref local="dynamicRoleProvider"/>
</beans:property>
</beans:bean>
</beans:list>
</beans:property>
</beans:bean>
<beans:bean id=” dynamicRoleProvider” class=”…”>
    ……
</beans:bean>

posted on 2009-03-04 12:55 楊一 閱讀(5074) 評論(0)  編輯  收藏 所屬分類: HLD