acegi內(nèi)置了對CAS的支持。這里的CAS是3.0。建立CAS server是一個比較簡單的事情。CAS server就是一個標準的war文件，把它發(fā)布就可以運行。需要做的僅僅是調(diào)整登陸和其他一些頁面。先了解一下CAS如何實現(xiàn)SSO。
例子：原有系統(tǒng)A和系統(tǒng)B，現(xiàn)在在它們之間做SSO。
很顯然，系統(tǒng)A和B都是CAS client。首先是訪問系統(tǒng)A，干掉A的登陸頁面，在A的入口判斷有沒有Ticket(票據(jù)），如果沒有則重定向到CAS server，在CAS server提供Credential（大多數(shù)情況就是用戶名和密碼）。CAS server的作用非常簡單：就是來驗證用戶密碼。正確，則發(fā)送Ticket。CAS有5種Ticket，分別是TGC(通過cookie發(fā)送的ticket），ST（Service Ticket),PGT,PGTIOU,PT。其中PGT,PGTIOU,PT屬于代理ticket，這里不作討論。具體可以參考
http://www.tkk7.com/openssl/archive/2006/04/26/SSO_CASProxy.htmlTGC和ST的關(guān)系可以打個比方：
我去中央電視塔去玩，結(jié)果發(fā)現(xiàn)地下還有個海底世界。SSO前我是這么玩的：先去電視塔買張門票，玩完了；再去海底世界買張門票，玩完了。發(fā)現(xiàn)真累，兩個景點這么近還要買兩次門票，就不能搞個通票嗎？于是就SSO。于是這樣：我先去電視塔，門衛(wèi)告訴我你不能進去要買票，于是把我送到通票售票處（CAS server）買票（登錄），買吧，于是給了我兩張票，注意，是兩張，一張發(fā)到我手里，上面寫著僅限電視塔使用（ST）；靠，不是通票嗎，咋僅限電視塔使用？別急，還有一張票（TGC）通過cookie發(fā)送你看不見。人家說了保證沒問題，我咋辦，這是人家的規(guī)矩，那就先去玩吧。出了電視塔我直撲海底世界，
門衛(wèi)說要海底世界票，不會吧，我買的通票啊，門衛(wèi)說不著急，又把我送回通票售票處（CAS server），通票售票處（CAS server）一看，發(fā)現(xiàn)我有TGC，嘿嘿，這家伙買過票了不用再買（不用再登錄），于是換我一張票（ST）上面寫著僅限海底世界使用，于是我就拿著這張票又去海底世界了。于是我明白了啥是SSO了，不就是把買票改成換票了嗎？
比方完了，最開始的例子也就不往下繼續(xù)了。需要注意的是系統(tǒng)A和B整合SSO需要把A、B的用戶密碼集中管理，你說A中我的用戶名是張三，B中是李四，SSO能不能幫我自動識別，回答是不行的。
繼續(xù)Acegi的整合。
CAS server是做用戶密碼驗證，具體的權(quán)限授權(quán)的工作還是在各個單個系統(tǒng)里，也不應該交給它管。做用戶密碼驗證需要AuthenticationHandler。這個具體就是根據(jù)Credential返回一個boolean值來判斷你輸入的用戶密碼正不正確。acegi提供了一個實現(xiàn)。
以一個典型的web訪問來說明整個過程
1、用戶訪問一個受acegi安全保護的頁面或業(yè)務方法；
2、用戶沒有登陸的話顯然會拋出AuthenticationException
3、配置exceptionTranslationFilter捕獲這個異常重定向到CAS server登陸頁面
???????<bean?id="exceptionTranslationFilter"?class="org.acegisecurity.ui.ExceptionTranslationFilter">
????????????<property?name="authenticationEntryPoint"><ref?local="casProcessingFilterEntryPoint"/></property>
????????</bean>
????????
????????<bean?id="casProcessingFilterEntryPoint"?class="org.acegisecurity.ui.cas.CasProcessingFilterEntryPoint">
????????????<property?name="loginUrl"><value>https://my.company.com/cas/login</value></property>
????????????<property?name="serviceProperties"><ref?local="serviceProperties"/></property>
????????</bean>
????????
????????<bean?id="serviceProperties"?class="org.acegisecurity.ui.cas.ServiceProperties">
????????????<property?name="service"><value>https://server.company.com/myapp/j_acegi_cas_security_check</value></property>
????????????<property?name="sendRenew"><value>false</value></property>
????????</bean>serviceProperties里的service屬性即在CAS server登陸完畢后由CAS server重定向回來的頁面
??
https://my.company.com/cas/login?service=https%3A%2F%2Fserver.company.com%2Fmyapp%2Fj_acegi_cas_security_check4、CAS server檢查是否有TGC ，沒有則登陸，登陸后返回。這里屁股后面跟著的即ST，TGC通過cookie一并發(fā)送到客戶端。
??
https://server.company.com/myapp/j_acegi_cas_security_check?ticket=ST-0-jhsdfguwgeds5、配置casProcessingFilter來處理返回ST（和以前的authenticationProcessingFilter比較類似）
???<bean?id="casProcessingFilter"?class="org.acegisecurity.ui.cas.CasProcessingFilter">
????????<property?name="authenticationManager"><ref?local="authenticationManager"/></property>
????????<property?name="authenticationFailureUrl"><value>/casfailed.jsp</value></property>
????????<property?name="defaultTargetUrl"><value>/</value></property>
????????<property?name="filterProcessesUrl"><value>/j_acegi_cas_security_check</value></property>
????</bean> 6、配置authenticationManager
???<bean?id="authenticationManager"?class="org.acegisecurity.providers.ProviderManager">
??????<property?name="providers">
?????????<list>
????????????<ref?local="casAuthenticationProvider"/>
?????????</list>
??????</property>
???</bean>
???
??<bean?id="casAuthenticationProvider"?class="org.acegisecurity.providers.cas.CasAuthenticationProvider">
????????<property?name="casAuthoritiesPopulator"><ref?local="casAuthoritiesPopulator"/></property>
????????<property?name="casProxyDecider"><ref?local="casProxyDecider"/></property>
????????<property?name="ticketValidator"><ref?local="casProxyTicketValidator"/></property>
????????<property?name="statelessTicketCache"><ref?local="statelessTicketCache"/></property>
????????<property?name="key"><value>my_password_for_this_auth_provider_only</value></property>
????</bean>? 具體作用的是casAuthenticationProvider，casAuthenticationProvider通過 casProxyTicketValidator來校驗ST
????<bean?id="casProxyTicketValidator"?class="org.acegisecurity.providers.cas.ticketvalidator.CasProxyTicketValidator">
????????<property?name="casValidate"><value>https://my.company.com/cas/proxyValidate</value></property>
????????<property?name="serviceProperties"><ref?local="serviceProperties"/></property>
????</bean>? casProxyTicketValidator又具體實現(xiàn)調(diào)用了CAS Client library里的ProxyTicketValidator校驗ST，ProxyTicketValidator?就比較有意思了，它做了個HTTPS請求CAS server，結(jié)果還是CAS server來校驗ST（繞了一大圈）
?
https://my.company.com/cas/proxyValidate?service=https%3A%2F%2Fserver.company.com%2Fmyapp%2Fj_acegi_cas_security_check?重新回到CAS server，它接受到這個HTTPS請求，檢查ST是否與對這個service發(fā)行的ST吻合，吻合的話CAS server就會發(fā)回一個肯定的XML回復，里面包含了用戶名（username)。剩下的就EASY了，casProxyTicketValidator解析XML，casProxyDecider處理代理，casAuthoritiesPopulator根據(jù)解析后的XML獲得user，最后就是casAuthenticationProvider構(gòu)造Authentication（這里是CasAuthenticationToken）
7、重新回到casProcessingFilter，它將Authentication放入HttpSession
這樣就完成了整個過程
http://www.tkk7.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請注明出處：）
posted on 2006-08-29 12:31
ronghao 閱讀(6264)
評論(5) 編輯 收藏 所屬分類:
權(quán)限相關(guān)