1. 360極速瀏覽器使用cas單點登錄慢解決辦法
360極速瀏覽器使用cas單點解決辦法：
1、打開360極速瀏覽器，點擊瀏覽器右上方「自定義和控制360極速瀏覽器」圖標，在下方的菜單中點擊打開「選項」頁面。
2、進入選項頁面後看向左側的菜單欄中，點擊「高級設置」這一項切換到對應的設置頁面。
3、在右側的高級設置內容中可以看到「隱私設置」這一項，點擊右側的「清除上網痕跡」按鈕。
4、在彈出的「清除上網痕跡」窗口中將「清除這段時間的數據」修改為全部，然後勾選「清除緩存」這一項，其它的選項則可以選擇性的勾選，然後點「清除」按鈕就可以將緩存清除了。
2. 在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());
3. CAS架構與原理簡介
HTTP是無狀態協議，客戶端與服務端之間的每次通信都是獨立的，而會話機制可以讓服務端鑒別每次通訊過程中的客戶端是否是同一個，從而保證業務的關聯性。 Session是伺服器使用一種類似於散列表的結構，用來保存用戶會話所需要的信息.Cookie作為瀏覽器緩存，存儲Session ID以達到會話跟蹤的目的。
SSO 單點登錄，是企業為了解決在相互信任的系統上實現一次登錄的解決方案。SSO將一個企業內部所有域中的用戶登錄和用戶帳號管理集中到一起，SSO的好處顯而易見：
CAS是SSO解決方案裡面比較成熟的架構，是耶魯大學發起的一個開源架構，其旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。CAS 具有以下特點：
下圖是 CAS 最基本的協議過程：
CAS架構包括兩部分：CAS Server和CAS Client。
以下是CAS應用之間交互過程的詳細時序圖與說明。
4. VS2010 此方法顯式使用的 CAS 策略已被 .NET Framework 棄用。NetFx40_LegacySecurityPolicy 配置開關
將
<NetFx40_LegacySecurityPolicy enabled="true"/>
作為第一項添加到C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config文件中的<runtime>標簽下，保存文件
5. 登錄那點事
client：提供用戶名和密碼或者是其他的認證憑證
server：驗證client提供的認證憑證，記錄登錄狀態
過程：訪問系統時，client必須輸入用戶名和密碼，server進行驗證，驗證通過後server建立一個叫做session的東西，然後把sessionId通過cookie發送給瀏覽器，下次登錄的時候會帶著cookie一起發過來，server從cookie中拿到sessionId就知道已經登錄啦。
cookie和session的作用就是保持client和server的交互狀態，這樣一來可以將無狀態的通信轉化成有狀態的交互，也就是讓server有了「記憶」能力。
現在有三個服務，需要輸入三次用戶信息，但是如果有成百上千的服務呢？HOW???
參考上面簡單登錄的原理：服務端如何有了「記憶」能力呢：在client和server之間引入了一個中間層（cookie或者是session）。（題外話：計算機世界的99%的問題都可以通過一個引入一個中間層來解決）
所有我們可以想到一個可行的解決方案：對這個「中間層」做共享。
比如說先登錄了A，就有了一個cookie，然後在用cookie去登錄其他的系統。但是這樣明顯是有問題的：
1，cookie不能跨域，比如說a.com產生的cookie是不能傳遞給b.com的
2，就算cookie可以傳遞，但是其他系統並沒有session來校驗這個cookie。
解決方案：
1.cookie做共享可以掛到同一個一級域名下，比如A叫a.corp.com，B叫b.corp.com，C叫c.corp.com，這樣cookie不就能共享了嘛
2，將session也做共享，從內存裡面拿出來，放入一個大家都能訪問的中間層裡面，比如說redis。（題外話：又是中間層）
像下面這樣：
可以解決多系統登錄的問題么？可以解決！！！ 但是
1，要共享cookie就必須讓所有的系統都在同一個域名下
2，多用戶賬號的存在。比如張三登錄了A，然後去登錄B，通過這種方式的話B需要去校驗張三這個用戶的合法性，此張三可能未必是彼張三！各個業務系統必須自己去維護自己系統的用戶，而且用戶信息還不止一個。
HOW？？？？
Single Sign One ：單點登錄
消除多用戶信息的問題，不用各個業務系統自己去維護用戶信息，建立一個統一的用戶認證中心（中間層：又是我哈哈哈），所有用戶的認證工作都交給這個認證中心來完成。各個子業務只需要負責實現自己的業務即可，不在需要關心用戶、認證等細節。
大致流程如下：
用戶第一次訪問A系統：www.a.corp.com，這個時候如果A發現用戶沒有登錄的話，那他需要做的一項操作就是重定向認證中心：www.sso.com/login?redirect=www.a.corp.com。
其中www.sso.com/login就是認證中心的登錄地址，redirect=www.a.corp.com就是登錄完成後需要跳轉到的地址。在認證中心登錄之後認證中心會做以下幾件事情：
1，建立一個session
2，發放ticket
3，重定向到你的地址，並在瀏覽器種下cookie信息。注意這個cookie是認證中心伺服器的cookie哦。如：ssoid=1,domain=sso.com
需要注意的有兩點：
1，進行了兩次重定向。第一次是重定向到SSO的伺服器，第二次是重定向我們的後端伺服器。
2，流程完成後再瀏覽器種了兩個cookie，一個是sso伺服器的cookie，一個是子系統A的cookie。
接下來我們訪問B系統：
這個時候會有三個cookie：
1，認證中心的cookie domain: sso.com
2，A系統的cookie domain： a.corp.com
3, B系統的cookie domain： b.corp.com
本質上就是保存了一個認證中心的cookie和多個子系統的cookie。一般我們稱SSO的cookie的對應的會話成為全局會話，各自子系統cookie對應的會話稱為局部會話。
概述
CAS（Central Authentication Service） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。
特性
1、 開源的、多協議的 SSO 解決方案；Protocols：Custom Protocol、CAS、OAuth、OpenID、RESTful API、SAML1.1、SAML2.0 等。
2、 支持多種認證機制：Active Directory、JAAS、JDBC、LDAP、X.509 Certificates 等；
3、 安全策略：使用票據（Ticket）來實現支持的認證協議；
4、 支持授權：可以決定哪些服務可以請求和驗證服務票據（Service Ticket）；
5、 提供高可用性：通過把認證過的狀態數據存儲在 TicketRegistry 組件中，這些組件有很多支持分布式環境的實現，如：BerkleyDB、Default 、EhcacheTicketRegistry、JDBCTicketRegistry、JBOSS TreeCache、JpaTicketRegistry、MemcacheTicketRegistry 等；
6、 支持多種客戶端： Java、 .Net、 PHP、 Perl、 Apache, uPortal 等。
體系結構
從結構上看，CAS 包含兩個部分：CAS Server 和 CAS Client，CAS 需要獨立部署，主要負責對用戶的認證工作，CAS Server 會處理用戶名 / 密碼等憑證 (Credentials)。
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。CAS Client一般與 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包請求 Service Ticket
術語
Ticket Granting ticket (TGT) ：可以認為是CAS Server根據用戶名密碼生成的一張票，存在server端
Ticket-granting cookie (TGC) ：其實就是一個cookie，存放用戶身份信息，由server發給client端
Service ticket (ST) ：由TGT生成的一次性票據，用於驗證，只能用一次。相當於server發給client一張票，然後client拿著這是個票再來找server驗證，看看是不是server簽發的。就像是我給了你一張我的照片，然後你拿照片再來問我，這個照片是不是你。。。沒錯，就是這么無聊。
安全性
TGC安全性：
對於一個 CAS 用戶來說，最重要是要保護它的 TGC，如果 TGC 不慎被 CAS Server 以外的實體獲得，Hacker 能夠找到該 TGC，然後冒充 CAS 用戶訪問所有授權資源。從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。TGT 的存活周期默認為 120 分鍾。
ST安全性：
ST（Service Ticket）是通過 Http 傳送的，因此網路中的其他人可以 Sniffer 到其他人的 Ticket。CAS 通過以下幾方面來使 ST 變得更加安全：
1、 ST 只能使用一次
CAS 協議規定，無論 Service Ticket 驗證是否成功， CAS Server 都會清除服務端緩存中的該 Ticket，從而可以確保一個 Service Ticket 不被使用兩次。
2、 ST 在一段時間內失效
CAS 規定 ST 只能存活一定的時間，然後 CAS Server 會讓它失效。默認有效時間為 5 分鍾。
3、 ST 是基於隨機數生成的
ST 必須足夠隨機，如果 ST 生成規則被猜出，Hacker 就等於繞過 CAS 認證，直接訪問對應的服務。
流程
上圖是3個登錄場景，分別為：第一次訪問www.qian.com、第二次訪問、以及登錄狀態下第一次訪問mail.qian.com。
第一次訪問www.qian.com
標號1： 用戶訪問http://www.qian.com，經過他的第一個過濾器：org.jasig.cas.client.authentication.AuthenticationFilter（cas提供，在web.xml中配置）。主要作用：判斷是否登錄，如果沒有登錄則重定向到認證中心
標號2： www.qian.com發現用戶沒有登錄，則返回瀏覽器重定向地址。
首先可以看到我們請求www.qian.com，之後瀏覽器返回狀態碼302，然後讓瀏覽器重定向到cas.qian.com並且通過get的方式添加參數service，該參數目的是登錄成功之後會要重定向回來，因此需要該參數。並且你會發現，其實server的值就是編碼之後的我們請求www.qian.com的地址。
標號3： 瀏覽器接收到重定向之後發起重定向，請求cas.qian.com。
標號4： 認證中心cas.qian.com接收到登錄請求，返回登陸頁面。
上圖就是標號3的請求，以及標號4的響應。請求的URL是標號2返回的URL。之後認證中心就展示登錄的頁面，等待用戶輸入用戶名密碼。
標號5： 用戶在cas.qian.com的login頁面輸入用戶名密碼，提交。
標號6 ：伺服器接收到用戶名密碼，則驗證是否有效，驗證邏輯可以使用cas-server提供現成的，也可以自己實現。
上圖就是標號5的請求，以及標號6的響應了。當cas.qian.com即csa-server認證通過之後，會返回給瀏覽器302，重定向的地址就是Referer中的service參數對應的值。後邊並通過get的方式挾帶了一個ticket令牌，這個ticket就是ST（數字3處）。同時會在Cookie中設置一個CASTGC，該cookie是網站cas.qian.com的cookie，只有訪問這個網站才會攜帶這個cookie過去。
Cookie中的CASTGC：向cookie中添加該值的目的是當下次訪問cas.qian.com時，瀏覽器將Cookie中的TGC攜帶到伺服器，伺服器根據這個TGC，查找與之對應的TGT。從而判斷用戶是否登錄過了，是否需要展示登錄頁面。TGT與TGC的關系就像SESSION與Cookie中SESSIONID的關系。點擊這里了解Java如何操作Cookie。
TGT：Ticket Granted Ticket（俗稱大令牌，或者說票根，他可以簽發ST）
TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根據他可以找到TGT。
ST：Service Ticket （小令牌），是TGT生成的，默認是用一次就生效了。也就是上面數字3處的ticket值。
標號7 ：瀏覽器從cas.qian.com哪裡拿到ticket之後，就根據指示重定向到www.qian.com，請求的url就是上面返回的url。
標號8 ：www.qian.com在過濾器中會取到ticket的值，然後通過http方式調用cas.qian.com驗證該ticket是否是有效的。
標號9 ：cas.qian.com接收到ticket之後，驗證，驗證通過返回結果告訴www.qian.com該ticket有效。
標號10 ：www.qian.com接收到cas-server的返回，知道了用戶合法，展示相關資源到用戶瀏覽器上。
第二次訪問www.qian.com
標號11 ：用戶發起請求，訪問www.qian.com。會經過cas-client，也就是過濾器，因為第一次訪問成功之後www.qian.com中會在session中記錄用戶信息，因此這里直接就通過了，不用驗證了。
標號12 ：用戶通過許可權驗證，瀏覽器返回正常資源。
訪問mail.qian.com
標號13 ：用戶在www.qian.com正常上網，突然想訪問mail.qian.com，於是發起訪問mail.qian.com的請求。
標號14 ：mail.qian.com接收到請求，發現第一次訪問，於是給他一個重定向的地址，讓他去找認證中心登錄。
上圖可以看到，用戶請求mail.qian.com，然後返回給他一個網址，狀態302重定向，service參數就是回來的地址。
標號15 ：瀏覽器根據14返回的地址，發起重定向，因為之前訪問過一次了，因此這次會攜帶上次返回的Cookie：TGC到認證中心。
標號16 ：認證中心收到請求，發現TGC對應了一個TGT，於是用TGT簽發一個ST，並且返回給瀏覽器，讓他重定向到mail.qian.com
可以發現請求的時候是攜帶Cookie：CASTGC的，響應的就是一個地址加上TGT簽發的ST也就是ticket。
標號17 ：瀏覽器根據16返回的網址發起重定向。
標號18 ：mail.qian.com獲取ticket去認證中心驗證是否有效。
標號19 ：認證成功，返回在mail.qian.com的session中設置登錄狀態，下次就直接登錄。
標號20 ：認證成功之後就反正用想要訪問的資源了。
配置filter
我們需要在應用的web.xml文件中配置四個Filter，這四個Filter必須按照固定的順序來進行配置，而且它們必須配置在應用的其它Filter之前。它們的先後順序要求如下：
1、AuthenticationFilter
casServerLoginUrl用來指定Cas Server登錄地址，serverName或service用來指定認證成功後需要跳轉地址。
2、TicketValidationFilter
請求通過AuthenticationFilter的認證之後，如果請求中攜帶了參數ticket則將會由TicketValidationFilter來對攜帶的ticket進行校驗。 TicketValidationFilter只是對驗證ticket的這一類Filter的統稱，其並不對應Cas Client中的一個具體類型。Cas Client中有多種驗證ticket的Filter，
都繼承自，它們的驗證邏輯都是一致的，都有實現，不同的是使用的TicketValidator不一樣。這里我們使用Cas10TicketValidationFilter，也可以使用或Saml11TicketValidationFilter。
3、
用於將每一個請求對應的HttpServletRequest封裝為其內部定義的CasHttpServletRequestWrapper，該封裝類將利用之前保存在Session或request中的Assertion對象重寫HttpServletRequest的getUserPrincipal()、getRemoteUser()和isUserInRole()方法。
這樣在我們的應用中就可以非常方便的從HttpServletRequest中獲取到用戶的相關信息
4、AssertionThreadLocalFilter
AssertionThreadLocalFilter可以在應用的其它地方獲取Assertion對象，找個過濾器會把Assertion對象存放到當前的線程變數中，我們在程序的任何地方都可以從線程變數中獲取當前Assertion，就不需要再從Session或request中進行解析了。這個線程變數是由AssertionHolder持有的，我們在獲取當前的 Assertion時也只需要通過AssertionHolder的getAssertion()方法獲取即可
6. 什麼是CAS
CAS意為列地址選通脈沖(Column Address Strobe 或者Column Address Select),CAS控制著從收到命令到執行命令的間隔時間，通常為2，2.5,3這個幾個時鍾周期。在整個內存矩陣中，因為CAS按列地址管理物理地址，因此在穩定的基礎上，這個非常重要的參數值越低越好。過程是這樣的，在內存陣列中分為行和列，當命令請求到達內存後，首先被觸發的是tRAS (Active to Precharge Delay)，數據被請求後需預先充電，一旦tRAS被激活後，RAS才開始在一半的物理地址中定址，行被選定後，tRCD初始化，最後才通過CAS找到精確的地址。整個過程也就是先行定址再列定址。從CAS開始到CAS結束就是現在講解的CAS延遲了。因為CAS是定址的最後一個步驟，所以在內存參數中它是最重要的。
7. cas是什麼
CAS是Central Authentication Service的縮寫，中央認證服務，一種獨立開放指令協議。CAS 是耶魯大學（Yale University）發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。
從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。
相關信息：
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。對於訪問受保護資源的每個 Web 請求，CAS Client 會分析該請求的 Http 請求中是否包含 Service Ticket，如果沒有，則說明當前用戶尚未登錄。
於是將請求重定向到指定好的 CAS Server 登錄地址，並傳遞 Service （也就是要訪問的目的資源地址），以便登錄成功過後轉回該地址。用戶在第 3 步中輸入認證信息，如果登錄成功，CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket，並緩存以待將來驗證，之後系統自動重定向到 Service 所在地址。
並為客戶端瀏覽器設置一個 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新產生的 Ticket 過後，在第 5，6 步中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。