技術背景知識: JA-SIG CAS服務環(huán)境搭建,請參考 :JA-SIG(CAS)學習筆記1 JA-SIG CAS業(yè)務架構介紹,請參考 :JA-SIG(CAS)學習筆記2 HTTPS所涉及的Java安全證書知識,請參考 :Java keytool 安全證書學習筆記 CAS技術框架 CAS Server 目前,我們使用的CAS Server 3.1.1的是基于Spring Framework編寫的,因此在CAS服務器端的配置管理中,絕大多數(shù)是Spring式的Java Bean XML配置。CAS 的服務器提供了一套易于定制的用戶認證器接口,用戶可以根據(jù)自身企業(yè)的在線系統(tǒng)的認證方式,來定制自己的認證邏輯。不論是傳統(tǒng)的用戶名/密碼方式,還是基 于安全證書的方式;是基于關系數(shù)據(jù)庫的存儲,還是采用LDAP服務器,CAS Server給我們提供了這些常用的驗證器模板代碼,只要稍作修改,便可靈活使用了。 對于廣大的中國企業(yè)用戶而言,另一個需要定制的功能莫過于全中文、企業(yè)特色的用戶身份認證頁面了。CAS Server提供了兩套系統(tǒng)界面,一套是默認的CAS英文標準頁面,另一套則是專門提供給用戶來定制修改的。(PS:老外們做事情就是人性化啊~~)那么 對CAS Server端的后續(xù)學習,我們將圍繞著身份認證模塊定制和界面定制這兩方面展開。 CAS Client 客戶端我們使用的是CAS Client 2.1.1。雖然在官方網(wǎng)站上已出現(xiàn)了3.1.0版本的下載,但該版本地代碼已經(jīng)完全重寫,使用的package和類名同2.1.1大相徑庭了,最關鍵的 是,該版本暫時沒有對應的API說明文檔。雖然咖啡我對程序版本懷有極大的“喜新厭舊”的心態(tài),但安全起見,還是先2.1.1吧,相信3.1.0的文檔耶 魯大學的大牛們已經(jīng)在整理了,期待中…… CAS Client2.1.1.jar中的代碼是相當精煉的,有興趣的朋友建議閱讀一下源碼。Jar包中的代碼分成三個大部分 1. edu.yale.its.tp.cas.util 包,其中只有一個工具類 SecureURL.java 用來訪問HTTPS URL 2. edu.yale.its.tp.cas.proxy包,用來處理Proxy Authentication代理認證的3個類,其中ProxyTicketReceptor.java是 接收PGT回調(diào)的servlet,在下文中我們會提及。 3. edu.yale.its.tp.cas.client包,其中包含了CAS Filter ,Tag Library等主要的認證客戶端工具類,我們在后面會進行重點介紹。 針對CAS Client的學習,我們的重點將放在CAS Filter 和ProxyTicketReceptor 的配置以及在Java SE環(huán)境下,直接使用 ServiceTicketValidator進行Ticket認證實現(xiàn)上。 CAS服務器端應用 定制適合你的身份認證程序 通過前面的學習,我們了解了CAS具有一個良好而強大的SSO功能框架。接下來,我們要學習如何將實際企業(yè)應用中的身份認證同CAS進行整合。 簡單的說,要將現(xiàn)有企業(yè)應用中的認證集成到CAS Server中,只要實現(xiàn)一個名為AuthenticationHandler的一個認證處理Java接口就行。以下是該接口的源代碼: Java代碼
這里我們要說明一下Credentials這個CAS的概念。所謂Credentials是由外界提供給CAS來證明自身身份的信息,簡單的如一 個用戶名/密碼對就是一個Credentials,或者一個經(jīng)過某種加密算法生成的密文證書也可以是一個Credentials。在程序的實現(xiàn) 上,Credentials被聲明為一個可序列化的接口,僅僅起著標識作用,源代碼如下: Java代碼
CAS的API中,已經(jīng)為我們提供了一個最常用的實現(xiàn)UsernamePasswordCredentials 用戶名/密碼憑證,代碼如下: Java代碼
很簡單不是嗎?就是存儲一個用戶名和密碼的java bean而已。 接下來,我們將一個Credentials傳給一個AuthenticationHandler進行認證,首先調(diào)用boolean supports(Credentials credentials)方法察看當前傳入的Credentials實例,AuthenticationHandler實例現(xiàn)是否支持它?如果支持,再調(diào) 用boolean authenticate(Credentials credentials)方法進行認證。由于用戶名/密碼方式是最常用的認證方法,因此CAS為我們提供了一個現(xiàn)成的基于該方式的抽象認證處理類 AbstractUsernamePasswordAuthenticationHandler。通常我們只需要繼承該類,并實現(xiàn)其中的 authenticateUsernamePasswordInternal方法即可。下面我們給出一個Demo的實現(xiàn)類,它的校驗邏輯很簡單——僅校驗 用戶名的字符長度是否與密碼的相等(這里密碼是一個表示長度的整數(shù)),如果相等則認為認證通過,請看代碼: Java代碼
介紹到這里,大家應該清楚如何定制自己的AuthenticationHandler類了吧!這里要附帶說明的是,在CAS Server的擴展API中已經(jīng)提供了大量常用認證形式的實現(xiàn)類,它們同CAS Server的war包一同分發(fā): cas-server-support-generic-3.1.1.jar ——使用Map記錄用戶認證信息的實現(xiàn) cas-server-support-jdbc-3.1.1.jar —— 基于Spring JDBC的數(shù)據(jù)庫實現(xiàn)(我們常用的) cas-server-support-ldap-3.1.1.jar —— 基于LDAP的用戶認證實現(xiàn) 更多其他形式的實現(xiàn)各位看官有興趣的,可以一一閱讀源碼。 配置你的身份認證程序 完成了定制認證類的代碼編寫,接下來就是要讓CAS Server來調(diào)用它了。在CAS的框架中,對程序的配置都是使用Spring Framework的xml文件,這對于熟悉Spring的程序員而言算駕輕就熟了。 配置文件位于應用部署目錄的WEB-INF子目錄下——deployerConfigContext.xml。在bean id=authenticationManager 的 authenticationHandlers屬性中配置我們的AuthenticationHandlers: 引用 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"> <bean id="authenticationManager" class="org.jasig.cas.authentication.AuthenticationManagerImpl"> 。。。 。。。 <property name="authenticationHandlers"> <list> <bean class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-ref="httpClient" /> <!—下面就是系統(tǒng)默認的驗證器配置,你可以替換它,或者增加一個新的handler --> <bean class="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler" /> </list> </property> </bean> 。。。 。。。 </beans> 我們發(fā)現(xiàn)authenticationHandlers屬性是一個list,在這個list中可以配置多個 AuthenticationHandlers。這些AuthenticationHandlers形成了一個驗證器鏈,所有提交給CAS的 Credentials信息將通過這個驗證器鏈的鏈式過濾,只要這鏈中有一個驗證器通過了對Credentials的驗證,就認為這個 Credentials是合法的。這樣的設計使得我們可以很輕松的整合不同驗證體系的已有應用到同一個CAS上,比如:A驗證器負責校驗alpha系統(tǒng)提 交的Credentials,它是基于LDAP服務器的;B驗證器負責校驗beta系統(tǒng)提交的Credentials,它是一個傳統(tǒng)的RDB用戶表認 證;C驗證器負責校驗gamma系統(tǒng)提交的基于RSA證書加密的Credentials。3種完全不同的用戶身份認證通過配置就可以統(tǒng)一在同一個CAS服 務內(nèi),很好很強大,不是嗎??! 定制身份驗證登錄界面 CAS Server在顯示界面層view使用了“主題Theme”的概念。在{project.home}/webapp/WEB-INF/view/jsp /目錄下,系統(tǒng)默認提供了兩套得UI —— default和simple 。default方案使用了CSS等相對復雜得界面元素,而simple方案提供了最簡化的界面表示方式。在整個的CAS Server服務器端,有四個界面是我們必須要實現(xiàn)的: casConfirmView.jsp —— 確認信息(警告信息)頁面 casGenericSuccess.jsp —— 登陸成功提示頁面 casLoginView.jsp —— 登錄輸入頁面 casLogoutView.jsp —— SSO登出提示頁面 這些都是標準的jsp頁面,如何實現(xiàn)他們,完全由您說了算,除了名字不能改。 CAS為view的展示提供了3個級別的定制方式,讓我們從最直觀簡單的開始吧。 1. 采用文件覆蓋方式:直接修改default中的頁面或者將新寫好的四個jsp文件覆蓋到default目錄中。這種方式最直觀和簡單,但咖啡建議各位在使用這種方式前將原有目錄中的文件備份一下,以備不時之需。 2. 修改UI配置文件,定位UI目錄:在CAS Server端/webapp/WEB-INF/classes/ 目錄下,有一個名為default_views.properties的屬性配置文件,你可以通過修改配置文件中的各個頁面文件位置,指向你新UI文件, 來達到修改頁面展示的目的。 3. 修改配置文件的配置文件,這話看起來有點別扭,其實一點不難理解。在方法2中的default_views.properties文件是一整套的UI頁面 配置。如果我想保存多套的UI頁面配置就可以寫多個的properties文件來保存這些配置。在CAS Server端/webapp/WEB-INF/目錄下有cas-servlet.xml和cas.properties兩個文件,cas- servlet.xml使用了cas.properties文件中的cas.viewResolver.basename屬性來定義view屬性文件的名 字,因此你可以選者直接修改cas-servlet.xml中的viewResolver 下的basenames屬性,或者修改cas.properties中的cas.viewResolver.basename屬性,指定新的 properties文件名,這樣可以輕松的替換全套UI。 CAS客戶端配置及API應用 CASFilter的配置 對于大部分web應用而言,使用CAS集成統(tǒng)一認證是相對簡單的事,只要為需要認證的URL配置 edu.yale.its.tp.cas.client.filter.CASFilter認證過濾器。下面我們就針對過濾器的配置進行說明。首先參看一 下Filter的基本配置: 引用 <web-app> ... <filter> <filter-name>CAS Filter</filter-name> <filter-class>edu.yale.its.tp.cas.client.filter.CASFilter</filter-class> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.loginUrl</param-name> <param-value>https://secure.its.yale.edu/cas/login<;/param-value> </init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.validateUrl</param-name> <param-value>https://secure.its.yale.edu/cas/serviceValidate<;/param-value> </init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name> <param-value>your server name and port (e.g., www.yale.edu:8080)</param-value> </init-param> </filter> <filter-mapping> <filter-name>CAS Filter</filter-name> <url-pattern>/requires-cas-authetication/*</url-pattern> </filter-mapping> ... </web-app> 上述配置中的init-param是filter的3個必備的屬性,下面這張表則是filter全部屬性的詳細說明: ![]() ProxyTicketReceptor的配置 大家還記得在前面我們說過的Proxy Authentication中的call back URL嗎?ProxyTicketReceptor是部署在client端的一個servlet,提供server端回傳PGT和PGTIOU的。它的xml部署如下: 引用 <web-app> ... <servlet> <servlet-name>ProxyTicketReceptor</servlet-name> <servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class> <init-param> <param-name>edu.yale.its.tp.cas.proxyUrl</param-name> <param-value>https://secure.its.yale.edu/cas/proxy<;/param-value> </init-param> </servlet> <servlet-mapping> <servlet-name>ProxyTicketReceptor</servlet-name> <url-pattern>/CasProxyServlet</url-pattern> </servlet-mapping> ... </webapp> 這里要說明的是它的參數(shù)edu.yale.its.tp.cas.proxyUrl。在服務端通過ProxyTicketReceptor將 PGT和PGTIOU傳給客戶端后,ProxyTicketReceptor在進行Proxy Authentication的過程中需要向服務端請求一個ProxyTicket(PT),這個proxyUrl就是服務端的請求入口了。(關于 Proxy Authentication的運作原理,參見JA-SIG(CAS)學習筆記2 ) CAS Client端的API應用1.用戶可以通過以下兩種方式的任意一種,從JSP或servlet中獲取通過認證的用戶名: 引用 String username = (String)session.getAttribute(CASFilter.CAS_FILTER_USER); 或者 String username = (String)session.getAttribute("edu.yale.its.tp.cas.client.filter.user"); 2.獲得更完整的受認證用戶信息對象CASReceipt Java Bean,可以使用以下語句的任一: 引用 CASReceipt receipt = (CASReceipt )session.getAttribute(CASFilter.CAS_FILTER_RECEIPT); 或者 CASReceipt receipt = (CASReceipt )session.getAttribute("edu.yale.its.tp.cas.client.filter.receipt"); 3.手工編碼使用CAS Java Object進行用戶驗證,使用ServiceTicketValidator或者 ProxyTicketValidator(代理認證模式下),在servlet中對用戶身份進行驗證。 3-1.ServiceTicketValidator Java代碼
3-2.ProxyTicketValidator Java代碼
在這里,我們假設上下文環(huán)境中的用戶已經(jīng)通過了CAS登錄認證,被重定向到當前的servlet下,我們在servlet中獲取ticket憑 證,servlet的URL對用戶身份進行確認。如果上下文參數(shù)中無法獲取ticket憑證,我們就認為用戶尚未登錄,那么,該servlet必須負責將 用戶重定向到CAS的登錄頁面去。 初戰(zhàn)告捷 到今天為止,我們已經(jīng)通過JA-SIG學習筆記的1-3部分,對CAS這個開源SSO的框架有了個大體的了解和初步的掌握,希望這些知識能為各位步入CAS殿堂打開一扇的大門。咖啡希望在今后的工作應用中,能同大家一塊共同探討,進一步深入了解CAS。 |