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我，给分吧