cas協議

㈠ 有人知道 cas單點登錄系統是怎麼樣取得proxyticket的

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());

㈡ CAS的原理和協議

從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。圖1 是 CAS 最基本的協議過程：
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 的合法性。
在該協議中，所有與 CAS 的交互均採用 SSL 協議，確保，ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向的過程，但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的。
另外，CAS 協議中還提供了 Proxy （代理）模式，以適應更加高級、復雜的應用場景，具體介紹可以參考 CAS 官方網站上的相關文檔。

㈢ cas認證是什麼認證

CAS是Central Authentication Service的縮寫，中央認證服務，一種獨立開放指令協議。

CAS 是Yale大學發起的一個開源項目，旨在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。

特點

1、開源的企業級單點登錄解決方案。

2、CAS Server 為需要獨立部署的 Web 應用。

3、CAS Client 支持非常多的客戶端(這里指單點登錄系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

原理和協議

從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；

CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。圖 是 CAS 最基本的協議過程：

傳遞登錄用戶名

CAS 在登錄成功過後，會給瀏覽器回傳 Cookie，設置新的到的 Service Ticket。但客戶端應用擁有各自的 Session，我們要怎麼在各個應用中獲取當前登錄用戶的用戶名呢？

CAS Client 的 Filter 已經做好了處理，在登錄成功後，就可以直接從 Session 的屬性中獲取，如清單 11 所示：

清單 11. 在 Java 中通過 Session 獲取登錄用戶名

1// 以下兩者都可以

2session.getAttribute(CASFilter.CAS_FILTER_USER);

3session.getAttribute("e.yale.its.tp.cas.client.filter.user");

在 JSTL 中獲取用戶名的方法如清單 12 所示：

清單 12. 通過 JSTL 獲取登錄用戶名

1 <c:out value="${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 獲取登錄用戶名

2 out.println("The logon user:" + reqWrapper.getRemoteUser());

㈣ 如何查看 cas 是http協議還是https

cas4.0版本的deployerConfigContext.xml配置文件中默認有一段配置
<bean id="proxyAuthenticationHandler" class="org.jasig.cas.authentication.handler.support." p:httpClient-ref="httpClient" />
默認是使用https協議
如果版增加了權屬性 p :requireSecure="false"就是使用http協議

㈤ cas是什麼意思

看語境了

CAS=Channel Associated Signaling，隨路信令
CAS = Chinese Academy of Sciences，中國科學院，我國國家科學技術方面最高學術機構和全國自然科學與高新技術綜合研究發展中心。
[美國化學文摘服務社logo]

美國化學文摘服務社logo
CAS = Central Authentication Service，中央認證服務，一種獨立開始指令協議。
CAS= Court of Arbitration for Sports, 國際奧委會體育仲裁院
CAS = Chemical Abstracts Service，美國化學文摘服務社，美國化學會（American Chemical Society）下屬組織。
CAS = Channel Associated Signaling，通道合並信號，一類電腦通訊信號。
[美國傷害保險協會標志]

美國傷害保險協會標志
CAS = Casualty Actuarial Society，傷害保險協會，美國的一個專業保險協會。
CAS = China Accounting Standards，中國企業會計准則。
CAS = Civil Aid Service，香港民眾安全服務隊，中國香港的一個市民援助機構。

[香港民眾安全服務隊標志]

香港民眾安全服務隊標志
CAS = Close Air Support，近距離空中支援，近距離空中支援是以空中單元協助附近友軍的一種軍事戰術。
CAS = Code Access Security，代碼訪問安全，Microsoft .NET framework中的概念。
CAS = Cognitive Assessment System，認知評估系統，系一個給孩子的學院評估測試。

[斯溫伯恩大學天體物理和超級電腦中心標志]

斯溫伯恩大學天體物理和超級電腦中心標志
CAS = Centre for Astrophysics and Supercomputing，澳大利亞斯溫伯恩大學的天體物理和超級電腦中心。
CAS（Computer Assisted Surgery），電腦輔助手術，系將電腦技術運用在手術中。
CAS（Conditional Access System），有條件訪問系統，系一種選擇性數字媒體傳輸系統。
CAS（Console Access Server），控制台訪問伺服器，系提供電腦設備系統控制台訪問的一種設備或伺服器。

[消耗報警系統]

消耗報警系統
CAS（Consumer Alert System），消耗報警系統，系一種間諜軟體或廣告軟體。
CAS（Content-Addressable Storage），內容定址存儲，系一種數據存儲機構。
CAS = Column Address Strobe，或Column Address Strobe latency、Column Address Select latency，列地址選通脈沖。
CAS = Client Access，用戶端訪問角色，亦縮寫為CA。
CAS = Certification Authority，證書頒發機構，公鑰基礎結構的一個關鍵組件。
CAS = Classic Arts Showcase，美國經典藝術展播電視頻道，該頻道是一個宣傳精緻藝術品的美國非經營性衛星電視頻道。

[美國經典藝術展播電視頻道標志]

美國經典藝術展播電視頻道標志
CAS = Communication Automation System，通訊自動化系統，一種智能小區中通訊自動化系統，包括數字信息網路、語言與傳真功能、有線電視、公用天線系統。
CAS = Compare-and-Swap，比較和交換，一種特殊的處理器指令。
CAS = Complete Active Space，完全活動空間，在量子化學中分子軌道的一種分類。
CAS = Complex Adaptive System，復雜適應系統，復雜系統的特殊案例。
CAS = Computer Algebra System，計算機代數系統，一種簡化符號數學的軟體程序。

[國際體育仲裁法庭標志]

國際體育仲裁法庭標志
CAS = Court of Arbitration for Sports，國際體育仲裁法庭，為判決設計體育項目爭議的一個國際仲裁機構。
CAS = Cowboy Action Shooting，牛仔戰斗射擊，一項競技射擊運動。
CAS（Cycle Accurate Simulator），周期精確級模擬器，模擬微結構循環精確級的一種電腦程序。

[肇慶加美學校標志]

肇慶加美學校標志
CAS（Canadian-American School），加美學校，有時也特指肇慶加美學校，一所由加拿大教育發展（中國）有限公司於1995年創辦的私立學校。
CAS =China Association for Standardization. 中國標准協會
CAS =Class A Surface，汽車A面，汽車外覆蓋件曲率要求
CAS =Computer Aided Styling，計算機輔助造型。繼CAD/CAE/CAM後又一新技術
CAS =China All Star，中國全明星隊。多指競技類項目的國際比賽中出自全國不同俱樂部的人所組成的代表中國的團隊。
CAS=Cost Accounting Standards ,成本會計准則，成本計算標准
CAS=Composition adjustments by sealed argon ,化學加熱，鋼包精煉時做調溫用

㈥ nginx cas單點登錄受影響嗎

1.1. What is CAS ？
CAS （ Central Authentication Service ） 是 Yale 大學發起的一個企業級的、開源的項目，旨在為 Web 應用系統提供一種可靠的單點登錄解決方法（屬於 Web SSO ）。
CAS 開始於 2001 年， 並在 2004 年 12 月正式成為 JA-SIG 的一個項目。
1.2. 主要特性
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 等。

2. SSO 單點登錄原理
本文內容主要針對 Web SSO 。
2.1. 什麼是SSO
單點登錄（ Single Sign-On , 簡稱 SSO ）是目前比較流行的服務於企業業務整合的解決方案之一， SSO 使得在多個應用系統中，用戶只需要 登錄一次 就可以訪問所有相互信任的應用系統。
2.2. SSO 原理
2.2.1. SSO 體系中的角色
一般 SSO 體系主要角色有三種：
1、 User （多個）
2、 Web 應用（多個）
3、 SSO 認證中心（ 1 個 ）
2.2.2. SSO 實現模式的原則
SSO 實現模式一般包括以下三個原則：
1、 所有的認證登錄都在 SSO 認證中心進行；
2、 SSO 認證中心通過一些方法來告訴 Web 應用當前訪問用戶究竟是不是已通過認證的用戶；
3、 SSO 認證中心和所有的 Web 應用建立一種信任關系，也就是說 web 應用必須信任認證中心。（單點信任）
2.2.3. SSO 主要實現方式
SSO 的主要實現方式有：
1、 共享 cookies
基於共享同域的 cookie 是 Web 剛開始階段時使用的一種方式，它利用瀏覽同域名之間自動傳遞 cookies 機制，實現兩個域名之間系統令牌傳遞問題；另外，關於跨域問題，雖然 cookies 本身不跨域，但可以利用它實現跨域的 SSO 。如：代理、暴露 SSO 令牌值等。
缺點：不靈活而且有不少安全隱患，已經被拋棄。
2、 Broker-based( 基於經紀人 )
這種技術的特點就是，有一個集中的認證和用戶帳號管理的伺服器。經紀人給被用於進一步請求的電子身份存取。中央資料庫的使用減少了管理的代價，並為認證提供一個公共和獨立的 " 第三方 " 。例如 Kerberos 、 Sesame 、 IBM KryptoKnight （憑證庫思想 ) 等。 Kerberos 是由麻省理工大學發明的安全認證服務，已經被 UNIX 和 Windows 作為默認的安全認證服務集成進操作系統。
3、 Agent-based （基於代理人）
在這種解決方案中，有一個自動地為不同的應用程序認證用戶身份的代理程序。這個代理程序需要設計有不同的功能。比如，它可以使用口令表或加密密鑰來自動地將認證的負擔從用戶移開。代理人被放在伺服器上面，在伺服器的認證系統和客戶端認證方法之間充當一個 " 翻譯 " 。例如 SSH 等。
4、 Token-based
例如 SecureID,WebID ，現在被廣泛使用的口令認證，比如 FTP 、郵件伺服器的登錄認證，這是一種簡單易用的方式，實現一個口令在多種應用當中使用。
5、 基於網關
6、 基於 SAML
SAML(Security Assertion Markup Language ，安全斷言標記語言）的出現大大簡化了 SSO ，並被 OASIS 批准為 SSO 的執行標准 。開源組織 OpenSAML 實現了 SAML 規范。

3. CAS 的基本原理
3.1. 結構體系
從結構體系看， CAS 包括兩部分： CAS Server 和 CAS Client 。
3.1.1. CAS Server
CAS Server 負責完成對用戶的認證工作 , 需要獨立部署 , CAS Server 會處理用戶名 / 密碼等憑證 (Credentials) 。
3.1.2. CAS Client
負責處理對客戶端受保護資源的訪問請求，需要對請求方進行身份認證時，重定向到 CAS Server 進行認證。（原則上，客戶端應用不再接受任何的用戶名密碼等 Credentials ）。
CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護受保護的資源。
3.2. CAS 原理和協議
3.2.1. 基礎模式
基礎模式 SSO 訪問流程主要有以下步驟：
1. 訪問服務： SSO 客戶端發送請求訪問應用系統提供的服務資源。
2. 定向認證： SSO 客戶端會重定向用戶請求到 SSO 伺服器。
3. 用戶認證：用戶身份認證。
4. 發放票據： SSO 伺服器會產生一個隨機的 Service Ticket 。
5. 驗證票據： SSO 伺服器驗證票據 Service Ticket 的合法性，驗證通過後，允許客戶端訪問服務。
6. 傳輸用戶信息： SSO 伺服器驗證票據通過後，傳輸用戶認證結果信息給客戶端。
下面是 CAS 最基本的協議過程：

cas基礎協議圖
基礎協議圖

如上圖： CAS Client 與受保護的客戶端應用部署在一起，以 Filter 方式保護 Web 應用的受保護資源，過濾從客戶端過來的每一個 Web 請求，同時， CAS Client 會分析 HTTP 請求中是否包含請求 Service Ticket( ST 上圖中的 Ticket) ，如果沒有，則說明該用戶是沒有經過認證的；於是 CAS Client 會重定向用戶請求到 CAS Server （ Step 2 ），並傳遞 Service （要訪問的目的資源地址）。 Step 3 是用戶認證過程，如果用戶提供了正確的 Credentials ， CAS Server 隨機產生一個相當長度、唯一、不可偽造的 Service Ticket ，並緩存以待將來驗證，並且重定向用戶到 Service 所在地址（附帶剛才產生的 Service Ticket ） , 並為客戶端瀏覽器設置一個 Ticket Granted Cookie （ TGC ） ； CAS Client 在拿到 Service 和新產生的 Ticket 過後，在 Step 5 和 Step6 中與 CAS Server 進行身份核實，以確保 Service Ticket 的合法性。
在該協議中，所有與 CAS Server 的交互均採用 SSL 協議，以確保 ST 和 TGC 的安全性。協議工作過程中會有 2 次重定向 的過程。但是 CAS Client 與 CAS Server 之間進行 Ticket 驗證的過程對於用戶是透明的（使用 HttpsURLConnection ）。
CAS 請求認證時序圖如下：
cas認證時序圖
3.2.1. CAS 如何實現 SSO
當用戶訪問另一個應用的服務再次被重定向到 CAS Server 的時候， CAS Server 會主動獲到這個 TGC cookie ，然後做下面的事情：
1) 如果 User 持有 TGC 且其還沒失效，那麼就走基礎協議圖的 Step4 ，達到了 SSO 的效果；
2) 如果 TGC 失效，那麼用戶還是要重新認證 ( 走基礎協議圖的 Step3) 。

3.2.2. CAS 代理模式
該模式形式為用戶訪問 App1 ， App1 又依賴於 App2 來獲取一些信息，如： User -->App1 -->App2 。
這種情況下，假設 App2 也是需要對 User 進行身份驗證才能訪問，那麼，為了不影響用戶體驗（過多的重定向導致 User 的 IE 窗口不停地閃動 ) ， CAS 引入了一種 Proxy 認證機制，即 CAS Client 可以代理用戶去訪問其它 Web 應用。
代理的前提是需要 CAS Client 擁有用戶的身份信息 ( 類似憑據 ) 。之前我們提到的 TGC 是用戶持有對自己身份信息的一種憑據，這里的 PGT 就是 CAS Client 端持有的對用戶身份信息的一種憑據。憑借 TGC ， User 可以免去輸入密碼以獲取訪問其它服務的 Service Ticket ，所以，這里憑借 PGT ， Web 應用可以代理用戶去實現後端的認證，而 無需前端用戶的參與 。
下面為代理應用（ helloService ）獲取 PGT 的過程： （註： PGTURL 用於表示一個 Proxy 服務，是一個回調鏈接； PGT 相當於代理證； PGTIOU 為取代理證的鑰匙，用來與 PGT 做關聯關系；）
cas代理PGT獲取
如上面的 CAS Proxy 圖所示， CAS Client 在基礎協議之上，在驗證 ST 時提供了一個額外的 PGT URL( 而且是 SSL 的入口 ) 給 CAS Server ，使得 CAS Server 可以通過 PGT URL 提供一個 PGT 給 CAS Client 。
CAS Client 拿到了 PGT(PGTIOU-85 … ..ti2td) ，就可以通過 PGT 向後端 Web 應用進行認證。
下面是代理認證和提供服務的過程：

如上圖所示， Proxy 認證與普通的認證其實差別不大， Step1 ， 2 與基礎模式的 Step1,2 幾乎一樣，唯一不同的是， Proxy 模式用的是 PGT 而不是 TGC ，是 Proxy Ticket （ PT ）而不是 Service Ticket 。

3.2.3. 輔助說明
CAS 的 SSO 實現方式可簡化理解為： 1 個 Cookie 和 N 個 Session 。 CAS Server 創建 cookie ，在所有應用認證時使用，各應用通過創建各自的 Session 來標識用戶是否已登錄。
用戶在一個應用驗證通過後，以後用戶在同一瀏覽器里訪問此應用時，客戶端應用中的過濾器會在 session 里讀取到用戶信息，所以就不會去 CAS Server 認證。如果在此瀏覽器里訪問別的 web 應用時，客戶端應用中的過濾器在 session 里讀取不到用戶信息，就會去 CAS Server 的 login 介面認證，但這時 CAS Server 會讀取到瀏覽器傳來的 cookie （ TGC ），所以 CAS Server 不會要求用戶去登錄頁面登錄，只是會根據 service 參數生成一個 Ticket ，然後再和 web 應用做一個驗證 ticket 的交互而已。
3.3. 術語解釋
CAS 系統中設計了 5 中票據： TGC 、 ST 、 PGT 、 PGTIOU 、 PT 。
Ø Ticket-granting cookie(TGC) ：存放用戶身份認證憑證的 cookie ，在瀏覽器和 CAS Server 間通訊時使用，並且只能基於安全通道傳輸（ Https ），是 CAS Server 用來明確用戶身份的憑證；
Ø Service ticket(ST) ：服務票據，服務的惟一標識碼 , 由 CAS Server 發出（ Http 傳送），通過客戶端瀏覽器到達業務伺服器端；一個特定的服務只能有一個惟一的 ST ；
Ø Proxy-Granting ticket （ PGT ）：由 CAS Server 頒發給擁有 ST 憑證的服務， PGT 綁定一個用戶的特定服務，使其擁有向 CAS Server 申請，獲得 PT 的能力；
Ø Proxy-Granting Ticket I Owe You （ PGTIOU ） : 作用是將通過憑證校驗時的應答信息由 CAS Server 返回給 CAS Client ，同時，與該 PGTIOU 對應的 PGT 將通過回調鏈接傳給 Web 應用。 Web 應用負責維護 PGTIOU 與 PGT 之間映射關系的內容表；
Ø Proxy Ticket (PT) ：是應用程序代理用戶身份對目標程序進行訪問的憑證；

其它說明如下：
Ø Ticket Granting ticket(TGT) ：票據授權票據，由 KDC 的 AS 發放。即獲取這樣一張票據後，以後申請各種其他服務票據 (ST) 便不必再向 KDC 提交身份認證信息 (Credentials) ；
Ø Authentication service(AS) --------- 認證用服務，索取 Credentials ，發放 TGT ；
Ø Ticket-granting service (TGS) --------- 票據授權服務，索取 TGT ，發放 ST ；
Ø KDC( Key Distribution Center ) ---------- 密鑰發放中心；

4. CAS 安全性
CAS 的安全性僅僅依賴於 SSL 。使用的是 secure cookie 。
4.1. TGC/PGT 安全性
對於一個 CAS 用戶來說，最重要是要保護它的 TGC ，如果 TGC 不慎被 CAS Server 以外的實體獲得， Hacker 能夠找到該 TGC ，然後冒充 CAS 用戶訪問 所有 授權資源。 PGT 的角色跟 TGC 是一樣的。
從基礎模式可以看出， TGC 是 CAS Server 通過 SSL 方式發送給終端用戶，因此，要截取 TGC 難度非常大，從而確保 CAS 的安全性。
TGT 的存活周期默認為 120 分鍾。
4.2. ST/PT 安全性
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 認證，直接訪問 對應的 服務。

5. 參考資料
1、 https://wiki.jasig.org/display/CASUM/Introction
2、 http://www.jasig.org/cas/protocol/
3、 http://www.ibm.com/developerworks/cn/opensource/os-cn-cas/index.html
4、 http://www.blogjava.net/security/archive/2006/10/02/sso_in_action.html
5、 http://ke..com/view/190743.htm

㈦ 什麼是CAS

「CAS是電子錄取通知書，是擔保方簽發給未來學生的一個特別電子參考號碼。」

㈧ 不允許使用CAS來認證您訪問的目標應用。這是什麼原因呢難道是需要什麼證書嗎

這是因為CAS認證失敗，需要更新CAS認證。

從結構上看，CAS 包含兩個部分： CAS Server 和 CAS Client。CAS Server 需要獨立部署，主要負責對用戶的認證工作；

CAS Client 負責處理對客戶端受保護資源的訪問請求，需要登錄時，重定向到 CAS Server。圖 是 CAS 最基本的協議過程：

注意事項：

CAS中央認證服務，一種獨立開放指令協議。CAS在為 Web 應用系統提供一種可靠的單點登錄方法，CAS 在 2004 年 12 月正式成為 JA-SIG 的一個項目。

特點：

1、開源的企業級單點登錄解決方案。

2、CAS Server 為需要獨立部署的 Web 應用。

3、CAS Client 支持非常多的客戶端(這里指單點登錄系統中的各個 Web 應用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。

㈨ oppoR7S有miracas協議嗎

OPPO R7s支持該協議，Microcast是WiFi聯盟開發的一個實現同屏傳輸的技術（把手機上的畫面回推送到顯示器答端），是實現WLAN-Display功能的協議的名稱；某款手機是否支持該協議，只需確認這款機器是否支持WLAN Display功能，了解WLAN Display的使用方法即可。

㈩ 系統報錯，了解CAS的進來看看

你看看你包怎麼引的？不懂可以HI我，給分吧