❶ CAS的資料庫
化學文摘社提供若干化學相關信息資料庫，其中兩個最基本的資料庫是CAplus和Registry： CAplus包含世界范圍內的化學期刊和其他科學期刊上的化學相關文章的文獻目錄檢索信息以及摘要，超過2千7百萬條文獻和1.7億引用記錄。 Registry包含3千4百萬種無機及有機化學物質的15億余條屬性數據、1千4百萬條反應以及5千9百萬DNA序列。 化學物質屬性信息來自化學文摘社，使用CAS號對物質進行檢索。 DNA序列信息由化學文摘社和美國國家生物技術信息中心的GenBank共同提供。
❷ 在tomcat中配置CAS
CAS原理和協議
從結構上看，CAS包含兩個部分：CASServer和CASClient。CASServer需要獨立部署，主要負責對用戶的認證工作；CASClient負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到CASServer。圖1是CAS最基本的協議過程：
圖1.CAS基礎協議
CASClient與受保護的客戶端應用部署在一起，以Filter方式保護受保護的資源。對於訪問受保護資源的每個Web請求，CASClient會分析該請求的Http請求中是否包含ServiceTicket，如果沒有，則說明當前用戶尚未登錄，於是將請求重定向到指定好的CASServer登錄地址，並傳遞Service（也就是要訪問的目的資源地址），以便登錄成功過後轉回該地址。用戶在第3步中輸入認證信息，如果登錄成功，CASServer隨機產生一個相當長度、唯一、不可偽造的ServiceTicket，並緩存以待將來驗證，之後系統自動重定向到Service所在地址，並為客戶端瀏覽器設置一個TicketGrantedCookie（TGC），CASClient在拿到Service和新產生的Ticket過後，在第5，6步中與CASServer進行身份合適，以確保ServiceTicket的合法性。
在該協議中，所有與CAS的交互均採用SSL協議，確保，ST和TGC的安全性。協議工作過程中會有2次重定向的過程，但是CASClient與CASServer之間進行Ticket驗證的過程對於用戶是透明的。
另外，CAS協議中還提供了Proxy（代理）模式，以適應更加高級、復雜的應用場景，具體介紹可以參考CAS官方網站上的相關文檔。
准備工作
本文中的例子以tomcat5.5為例進行講解，下載地址：
http://tomcat.apache.org/download-55.cgi
到CAS官方網站下載CASServer和Client，地址分別為：
http://www.ja-sig.org/downloads/cas/cas-server-3.1.1-release.zip
http://www.ja-sig.org/downloads/cas-clients/cas-client-java-2.1.1.zip
部署CASServer
CASServer是一套基於Java實現的服務，該服務以一個JavaWebApplication單獨部署在與servlet2.3兼容的Web伺服器上，另外，由於Client與CASServer之間的交互採用Https協議，因此部署CASServer的伺服器還需要支持SSL協議。當SSL配置成功過後，像普通Web應用一樣將CASServer部署在伺服器上就能正常運行了，不過，在真正使用之前，還需要擴展驗證用戶的介面。
在Tomcat上部署一個完整的CASServer主要按照以下幾個步驟：
配置Tomcat使用Https協議
如果希望Tomcat支持Https，主要的工作是配置SSL協議，其配置過程和配置方法可以參考Tomcat的相關文檔。不過在生成證書的過程中，會有需要用到主機名的地方，CAS建議不要使用IP地址，而要使用機器名或域名。
部署CASServer
CASServer是一個Web應用包，將前面下載的cas-server-3.1.1-release.zip解開，把其中的cas-server-webapp-3.1.1.war拷貝到tomcat的webapps目錄，並更名為cas.war。由於前面已配置好tomcat的https協議，可以重新啟動tomcat，然後訪問：https://localhost:8443/cas，如果能出現正常的CAS登錄頁面，則說明CASServer已經部署成功。
雖然CASServer已經部署成功，但這只是一個預設的實現，在實際使用的時候，還需要根據實際概況做擴展和定製，最主要的是擴展認證(Authentication)介面和CASServer的界面。
擴展認證介面
CASServer負責完成對用戶的認證工作，它會處理登錄時的用戶憑證(Credentials)信息，用戶名/密碼對是最常見的憑證信息。CASServer可能需要到資料庫檢索一條用戶帳號信息，也可能在XML文件中檢索用戶名/密碼，還可能通過LDAPServer獲取等，在這種情況下，CAS提供了一種靈活但統一的介面和實現分離的方式，實際使用中CAS採用哪種方式認證是與CAS的基本協議分離開的，用戶可以根據認證的介面去定製和擴展。
擴展AuthenticationHandler
CAS提供擴展認證的核心是AuthenticationHandler介面，該介面定義如清單1下：
清單1.AuthenticationHandler定義
{
/**
*.
*@.
*@returntrueifvalid,returnfalseotherwise.
*@
*.
*/
booleanauthenticate(Credentialscredentials)throwsAuthenticationException;
/**
*
*provided.
*
*Credentialsobject.
*@.
*@,falseothewrise.
*/
booleansupports(Credentialscredentials);
}
該介面定義了2個需要實現的方法，supports()方法用於檢查所給的包含認證信息的Credentials是否受當前AuthenticationHandler支持；而authenticate()方法則擔當驗證認證信息的任務，這也是需要擴展的主要方法，根據情況與存儲合法認證信息的介質進行交互，返回boolean類型的值，true表示驗證通過，false表示驗證失敗。
CAS3中還提供了對AuthenticationHandler介面的一些抽象實現，比如，可能需要在執行authenticate()方法前後執行某些其他操作，那麼可以讓自己的認證類擴展自清單2中的抽象類：
清單2.定義
publicabstractclass
implementsAuthenticateHandler{
protectedLoglog=LogFactory.getLog(this.getClass());
(finalCredentialscredentials){
returntrue;
}
(finalCredentialscredentials,
finalbooleanauthenticated){
returnauthenticated;
}
(finalCredentialscredentials)
throwsAuthenticationException{
if(!preAuthenticate(credentials)){
returnfalse;
}
finalbooleanauthenticated=doAuthentication(credentials);
returnpostAuthenticate(credentials,authenticated);
}
(finalCredentialscredentials)
throwsAuthenticationException;
}
類新定義了preAuthenticate()方法和postAuthenticate()方法，而實際的認證工作交由doAuthentication()方法來執行。因此，如果需要在認證前後執行一些額外的操作，可以分別擴展preAuthenticate()和ppstAuthenticate()方法，而doAuthentication()取代authenticate()成為了子類必須要實現的方法。
由於實際運用中，最常用的是用戶名和密碼方式的認證，CAS3提供了針對該方式的實現，如清單3所示：
清單3.定義
publicabstractclassextends
{
...
(finalCredentialscredentials)
throwsAuthenticationException{
((UsernamePasswordCredentials)credentials);
}
(
)throwsAuthenticationException;
(){
returnthis.passwordEncoder;
}
(){
this.passwordEncoder=passwordEncoder;
}
...
}
基於用戶名密碼的認證方式可直接擴展自，驗證用戶名密碼的具體操作通過實現()方法達到，另外，通常情況下密碼會是加密過的，setPasswordEncoder()方法就是用於指定適當的加密器。
從以上清單中可以看到，doAuthentication()方法的參數是Credentials類型，這是包含用戶認證信息的一個介面，對於用戶名密碼類型的認證信息，可以直接使用UsernamePasswordCredentials，如果需要擴展其他類型的認證信息，需要實現Credentials介面，並且實現相應的介面，其具體方法可以借鑒UsernamePasswordCredentials和UsernamePassword。
JDBC認證方法
用戶的認證信息通常保存在資料庫中，因此本文就選用這種情況來介紹。將前面下載的cas-server-3.1.1-release.zip包解開後，在moles目錄下可以找到包cas-server-support-jdbc-3.1.1.jar，其提供了通過JDBC連接資料庫進行驗證的預設實現，基於該包的支持，我們只需要做一些配置工作即可實現JDBC認證。
JDBC認證方法支持多種資料庫，DB2,Oracle,Mysql,MicrosoftSQLServer等均可，這里以DB2作為例子介紹。並且假設DB2資料庫名：CASTest，資料庫登錄用戶名：db2user，資料庫登錄密碼：db2password，用戶信息表為：userTable，該表包含用戶名和密碼的兩個數據項分別為userName和password。
1.配置DataStore
打開文件%CATALINA_HOME%/webapps/cas/WEB-INF/deployerConfigContext.xml，添加一個新的bean標簽，對於DB2，內容如清單4所示：
清單4.配置DataStore
<beanid="casDataSource"class="org.apache.commons.dbcp.BasicDataSource">
<propertyname="driverClassName">
<value>com.ibm.db2.jcc.DB2Driver</value>
</property>
<propertyname="url">
<value>jdbc:db2://9.125.65.134:50000/CASTest</value>
</property>
<propertyname="username">
<value>db2user</value>
</property>
<propertyname="password">
<value>db2password</value>
</property>
</bean>
其中id屬性為該DataStore的標識，在後面配置AuthenticationHandler會被引用，另外，需要提供DataStore所必需的資料庫驅動程序、連接地址、資料庫登錄用戶名以及登錄密碼。
2.配置AuthenticationHandler
在cas-server-support-jdbc-3.1.1.jar包中，提供了3個基於JDBC的AuthenticationHandler，分別為,,。其中是用所給的用戶名和密碼去建立資料庫連接，根據連接建立是否成功來判斷驗證成功與否；通過配置一個SQL語句查出密碼，與所給密碼匹配；通過配置存放用戶驗證信息的表、用戶名欄位和密碼欄位，構造查詢語句來驗證。
使用哪個AuthenticationHandler，需要在deployerConfigContext.xml中設置，默認情況下，CAS使用一個簡單的username=password的AuthenticationHandler，在文件中可以找到如下一行：<beanclass="org.jasig.cas.authentication.handler.support.SimpleTestUsernamePassword
AuthenticationHandler"/>，我們可以將其注釋掉，換成我們希望的一個AuthenticationHandler，比如，使用或可以分別選取清單5或清單6的配置。
清單5.使用
<beanclass="org.jasig.cas.adaptors.jdbc.">
<propertyname="dataSource"ref="casDataSource"/>
<propertyname="sql"
value="(userName)=lower(?)"/>
</bean>
清單6.使用
<beanid=""
class="org.jasig.cas.adaptors.jdbc."
abstract="false"singleton="true"lazy-init="default"
autowire="default"dependency-check="default">
<propertyname="tableUsers">
<value>userTable</value>
</property>
<propertyname="fieldUser">
<value>userName</value>
</property>
<propertyname="fieldPassword">
<value>password</value>
</property>
<propertyname="dataSource"ref="casDataSource"/>
</bean>
另外，由於存放在資料庫中的密碼通常是加密過的，所以AuthenticationHandler在匹配時需要知道使用的加密方法，在deployerConfigContext.xml文件中我們可以為具體的AuthenticationHandler類配置一個property，指定加密器類，比如對於，可以修改如清單7所示：
清單7.添加passwordEncoder
<beanclass="org.jasig.cas.adaptors.jdbc.">
<propertyname="dataSource"ref="casDataSource"/>
<propertyname="sql"
value="(userName)=lower(?)"/>
<propertyname="passwordEncoder"ref="myPasswordEncoder"/>
</bean>
其中myPasswordEncoder是對清單8中設置的實際加密器類的引用：
清單8.指定具體加密器類
<beanid="passwordEncoder"
class="org.jasig.cas.authentication.handler.MyPasswordEncoder"/>
這里MyPasswordEncoder是根據實際情況自己定義的加密器，實現PasswordEncoder介面及其encode()方法。
3.部署依賴包
在以上配置完成以後，需要拷貝幾個依賴的包到cas應用下，包括：
將cas-server-support-jdbc-3.1.1.jar拷貝到%CATALINA_HOME%/webapps/cas/WEB-INF/lib目錄。
資料庫驅動，由於這里使用DB2，將%DB2_HOME%/java目錄下的db2java.zip（更名為db2java.jar）,db2jcc.jar,db2jcc_license_cu.jar拷貝到%CATALINA_HOME%/webapps/cas/WEB-INF/lib目錄。對於其他資料庫，同樣將相應資料庫驅動程序拷貝到該目錄。
DataStore依賴於commons-collections-3.2.jar,commons-dbcp-1.2.1.jar,commons-pool-1.3.jar，需要到apache網站的Commons項目下載以上3個包放進%CATALINA_HOME%/webapps/cas/WEB-INF/lib目錄。
擴展CASServer界面
CAS提供了2套默認的頁面，分別為「default」和「simple」，分別在目錄「cas/WEB-INF/view/jsp/default」和「cas/WEB-INF/view/jsp/simple」下。其中default是一個稍微復雜一些的頁面，使用CSS，而simple則是能讓CAS正常工作的最簡化的頁面。
在部署CAS之前，我們可能需要定製一套新的CASServer頁面，添加一些個性化的內容。最簡單的方法就是拷貝一份default或simple文件到「cas/WEB-INF/view/jsp」目錄下，比如命名為newUI，接下來是實現和修改必要的頁面，有4個頁面是必須的：
casConfirmView.jsp:當用戶選擇了「warn」時會看到的確認界面
casGenericSuccess.jsp:在用戶成功通過認證而沒有目的Service時會看到的界面
casLoginView.jsp:當需要用戶提供認證信息時會出現的界面
casLogoutView.jsp:當用戶結束CAS單點登錄系統會話時出現的界面
CAS的頁面採用Spring框架編寫，對於不熟悉Spring的使用者，在修改之前需要熟悉該框架。
頁面定製完過後，還需要做一些配置從而讓CAS找到新的頁面，拷貝「cas/WEB-INF/classes/default_views.properties」，重命名為「cas/WEB-INF/classes/newUI_views.properties」，並修改其中所有的值到相應新頁面。最後是更新「cas/WEB-INF/cas-servlet.xml」文件中的viewResolver，將其修改為如清單9中的內容。
清單9.指定CAS頁面
<beanid="viewResolver"
class="org.springframework.web.servlet.view.ResourceBundleViewResolver"p:order="0">
<propertyname="basenames">
<list>
<value>${cas.viewResolver.basename}</value>
<value>newUI_views</value>
</list>
</property>
</bean>
部署客戶端應用
單點登錄的目的是為了讓多個相關聯的應用使用相同的登錄過程，本文在講解過程中構造2個簡單的應用，分別以casTest1和casTest2來作為示例，它們均只有一個頁面，顯示歡迎信息和當前登錄用戶名。這2個應用使用同一套登錄信息，並且只有登錄過的用戶才能訪問，通過本文的配置，實現單點登錄，即只需登錄一次就可以訪問這兩個應用。
與CASServer建立信任關系
假設CASServer單獨部署在一台機器A，而客戶端應用部署在機器B上，由於客戶端應用與CASServer的通信採用SSL，因此，需要在A與B的JRE之間建立信任關系。
首先與A機器一樣，要生成B機器上的證書，配置Tomcat的SSL協議。其次，下載http://blogs.sun.com/andreas/entry/no_more_unable_to_find的InstallCert.java，運行「javaInstallCertcompA:8443」命令，並且在接下來出現的詢問中輸入1。這樣，就將A添加到了B的truststore中。如果多個客戶端應用分別部署在不同機器上，那麼每個機器都需要與CASServer所在機器建立信任關系。
配置CASFilter
准備好應用casTest1和casTest2過後，分別部署在B和C機器上，由於casTest1和casTest2，B和C完全等同，我們以casTest1在B機器上的配置做介紹，假設A和B的域名分別為domainA和domainB。
將cas-client-java-2.1.1.zip改名為cas-client-java-2.1.1.jar並拷貝到casTest1/WEB-INF/lib目錄下，修改web.xml文件，添加CASFilter，如清單10所示：
清單10.添加CASFilter
<web-app>
...
<filter>
<filter-name>CASFilter</filter-name>
<filter-class>e.yale.its.tp.cas.client.filter.CASFilter</filter-class>
<init-param>
<param-name>e.yale.its.tp.cas.client.filter.loginUrl</param-name>
<param-value>https://domainA:8443/cas/login</param-value>
</init-param>
<init-param>
<param-name>e.yale.its.tp.cas.client.filter.validateUrl</param-name>
<param-value>https://domainA:8443/cas/serviceValidate</param-value>
</init-param>
<init-param>
<param-name>e.yale.its.tp.cas.client.filter.serverName</param-name>
<param-value>domainB:8080</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>CASFilter</filter-name>
<url-pattern>/protected-pattern/*</url-pattern>
</filter-mapping>
...
</web-app>
對於所有訪問滿足casTest1/protected-pattern/路徑的資源時，都要求到CASServer登錄，如果需要整個casTest1均受保護，可以將url-pattern指定為「/*」。
從清單10可以看到，我們可以為CASFilter指定一些參數，並且有些是必須的，表格1和表格2中分別是必需和可選的參數：
表格1.CASFilter必需的參數
參數名作用
e.yale.its.tp.cas.client.filter.loginUrl指定CAS提供登錄頁面的URL
e.yale.its.tp.cas.client.filter.validateUrl指定CAS提供serviceticket或proxyticket驗證服務的URL
e.yale.its.tp.cas.client.filter.serverName指定客戶端的域名和埠，是指客戶端應用所在機器而不是CASServer所在機器，該參數或serviceUrl至少有一個必須指定
e.yale.its.tp.cas.client.filter.serviceUrl該參數指定過後將覆蓋serverName參數，成為登錄成功過後重定向的目的地址
表格2.CASFilter可選參數
參數名作用
e.yale.its.tp.cas.client.filter.proxyCallbackUrl用於當前應用需要作為其他服務的代理(proxy)時獲取ProxyGrantingTicket的地址
e.yale.its.tp.cas.client.filter.authorizedProxy用於允許當前應用從代理處獲取proxytickets，該參數接受以空格分隔開的多個proxyURLs，但實際使用只需要一個成功即可。當指定該參數過後，需要修改validateUrl到proxyValidate，而不再是serviceValidate
e.yale.its.tp.cas.client.filter.renew如果指定為true，那麼受保護的資源每次被訪問時均要求用戶重新進行驗證，而不管之前是否已經通過
e.yale.its.tp.cas.client.filter.wrapRequest如果指定為true，那麼CASFilter將重新包裝HttpRequest,並且使getRemoteUser()方法返回當前登錄用戶的用戶名
e.yale.its.tp.cas.client.filter.gateway指定gateway屬性
傳遞登錄用戶名
CAS在登錄成功過後，會給瀏覽器回傳Cookie，設置新的到的ServiceTicket。但客戶端應用擁有各自的Session，我們要怎麼在各個應用中獲取當前登錄用戶的用戶名呢？CASClient的Filter已經做好了處理，在登錄成功後，就可以直接從Session的屬性中獲取，如清單11所示：
清單11.在Java中通過Session獲取登錄用戶名
//以下兩者都可以
session.getAttribute(CASFilter.CAS_FILTER_USER);
session.getAttribute("e.yale.its.tp.cas.client.filter.user");
在JSTL中獲取用戶名的方法如清單12所示：
清單12.通過JSTL獲取登錄用戶名
<c:outvalue="${sessionScope[CAS:'e.yale.its.tp.cas.client.filter.user']}"/>
另外，CAS提供了一個CASFilterRequestWrapper類，該類繼承自HttpServletRequestWrapper，主要是重寫了getRemoteUser()方法，只要在前面配置CASFilter的時候為其設置「e.yale.its.tp.cas.client.filter.wrapRequest」參數為true，就可以通過getRemoteUser（）方法來獲取登錄用戶名，具體方法如清單13所示：
清單13.通過CASFilterRequestWrapper獲取登錄用戶名
=newCASFilterRequestWrapper(request);
out.println("Thelogonuser:"+reqWrapper.getRemoteUser());