Android 连接Cas服务器的实现单点登录（SSO）

如果我们的网站需要和另一个域名做统一认证，也就是在我们网站登录，但真正的功能却在另一个网站来提供。许多都以 passport 的方式。 整个认证可以分三步完成 第一步：本地验证

这个很简单，输入本地的用户名和密码，然后服务器认证通过，并返回正确的Cookie;

第二步：做远程认证，并返回远程连接

通过本地Cookie,确认用户合法性，然后服务器端调用远程的登录程序，返回一个远程认证号的URL,这个URL里面包含了一个唯一的认证码，使用Location的方式

第三步：远程登录

客户端使用前一步的URL,访问远程的服务器，服务器确认认证码的正确性，再返回正确的远程Cookie

至此，本地认证，通过一个URL,实现了远程认证。

一，业务分析

在分布式系统架构中，假设把上述的三个子系统部署在三个不同的服务器上。前提是用户登录之后才能访问这些子系统。那么使用传统方式，可能会存在这样的问题：

1当访问用户中心，需要用户登录帐号

2当访问购物车，还需要用户登录帐号

3当访问商品结算，又一次需要用户登录帐号

访问每一个子系统都需要用户登录帐号，这样的体验对于用户来说是极差。而使用单点登录就可以很好地解决上述的问题。

二，单点登录

单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO 的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

我们目前的系统存在诸多子系统，而这些子系统是分别部署在不同的服务器中，那么使用传统方式的 session 是无法解决的，我们需要使用相关的单点登录技术来解决。

第一步 ：用户访问应用系统1。过滤器判断用户是否登录，没有登录，则重定向（302）到认证系统去进行认证操作。

第二步 ：重定向到认证系统，显示登录界面，用户输入用户名密码。认证系统将用户登录的信息记录到服务器的session中。

第三步 ：认证系统给浏览器发送一个特殊的凭证ticket，浏览器将凭证交给应用系统1，应用系统1则拿着浏览器交给他的凭证ticket去认证系统验证凭证ticket是否有效。凭证ticket若是有效，将用户信息保存到应用系统1的session中一份，并告知应用系统1，用户通过认证。

第四步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第五步 ：当用户再次访问应用系统1，由于应用系统1的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问应用系统1了。

第六步 ：当用户再去访问其他应用系统时，浏览器会带着凭证ticket过去，其他应用系统到认证系统验证凭证，凭证ticket若是有效，将用户信息保存到其他应用系统的session中一份，并告知其他应用系统，用户通过认证。

第七步 ：用户通过认证，浏览器与网站之间进行正常的访问。

第八步 ：当用户再次访问其他应用系统，由于其他应用系统的session中有用户信息，所以就不用经过认证系统认证，就可以直接访问其他应用系统了。

三、Yelu大学研发的CAS(Central Authentication Server)

1什么是CAS？

CAS 是 Yale 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。CAS 具有以下特点：

1开源的企业级单点登录解决方案。

2CAS Server 为需要独立部署的 Web 应用。这个CAS框架已经提供

3CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括Java, Net, PHP, Perl, Apache, uPortal, Ruby 等。

从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。下图是 CAS 最基本的协议过程：

2CAS的详细登录流程

该图主要描述

1第一次访问http://shoppingxiaoguicom

2在登录状态下第二次访问http://shoppingxiaoguicom

3在登录状态下第一次访问http://payxiaoguicom

下面对图中序号代表的操作进行说明

当用户第一次访问http://shoppingxiaoguicom

序号1: 用户请求http://shoppingxiaoguicom，会经过AuthenticationFilter认证过滤器(在cas client 的webxml中配置)

主要作用：判断是否登录，如果没有登录则重定向到认证中心。

大概知道这个就行，CAS的具体实现会在以后的博客中写道

序号2:  AuthenticationFilter发现用户没有登录，则返回浏览器重定向地址。

重定向的地址就是认证服务器CAS Server的地址，后面的参数是我们请求的客户端地址，这个参数目的就是为了认证成功以后，根据这个参数的地址重定向回请求的客户端

序号3:  浏览器根据响应回来的重定向地址，向casxiaoguicom认证系统发出请求

序号4:  认证系统casxiaoguicom接收请求，响应登陆页面

序号5: ：用户登陆页面输入用户名密码，提交请求

序号6: ：CAS Server 认证服务器接收用户名和密码，就行验证，验证逻辑CAS Server 已经实现，并响应给浏览器信息

这里的用户名，密码不需要关心，后续会讲到

图中1，2部分表示序号5 输入的用户名，密码，以及发出的请求。当认证服务器验证通过之后，根据请求参数service的值，进行重定向，其实就是回到了请求的客户端，同时会携带一个ticket令牌参数。同时会在Cookie中设置一个TGC，该cookie是网站认证系统casxiaoguicom的cookie，只有访问这个网站才会携带这个cookie过去。

注意：这个携带TGC的Cookie是实现CAS单点登录的关键所在！

Cookie中的TGC：向cookie中添加该值的目的是当下次访问casxiaoguicom认证系统时，浏览器将Cookie中的TGC携带到服务器，服务器根据这个TGC，查找与之对应的TGT。从而判断用户是否登录过了，是否需要展示登录页面。TGT与TGC的关系就像SESSION与Cookie中SESSIONID的关系。

TGT：Ticket Granted Ticket（俗称大令牌，或者说票根，他可以签发ST）

TGC：Ticket Granted Cookie（cookie中的value），存在Cookie中，根据他可以找到TGT。

ST：Service Ticket （小令牌），是TGT生成的，默认是用一次就生效了。也就是上面数字3处的ticket值。

序号7:  客户端拿到请求中的ticket信息，也就是图中1的位置

然后经过一个ticket过滤器Cas20ProxyReceivingTicketValidationFilter，去认证系统CAS Server判断ticket是否有效

这个过滤器的主要工作就是校验客户端传过来的ticket是否有效

CAS Client 客户端  shoppingxiaoguicom  中webxml的配置

序号8:  向CAS Server认证系统发出验证ticket的请求，也就是图中2的位置，然后执行ticket验证

序号9:  通过校验之后，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中，同时告知客户端ticket有效。当用户再次访问该客户端，就可以根据Cookie 中的SessionID找到客户端的Session，获取用户信息，就不用再次进行验证了。也就是图中响应给浏览器的部分。

序号10:  shoppingxiaoguicom客户端接收到cas-server的返回，知道了用户已经登录，ticket有效，告知浏览器可以进行访问。

至此，用户第一次访问流程结束。

当用户第二次访问http://shoppingxiaoguicom

序号11: 当用户第二次访问，仍然会经过AuthenticationFilter过滤器，但与第一次访问不同的是此时客户端session中已经存在用户的信息，浏览器中的Cookie会根据SessionID找到Session，获取用户信息，所以不需要进行验证，可以直接访问。

序号12:  客户端告知浏览器可以进行访问。

当用户第一次访问http://payxiaoguicom

序号13:   用户向payxiaoguicom  CAS Client客户端发出请求

序号14:  ：payxiaoguicom接收到请求，发现第一次访问，于是给他一个重定向的地址，让他去找认证中心登录。

序号15: 浏览器根据上面响应的地址，发起重定向，因为之前访问过一次了，因此这次会携带上次返回的Cookie：TGC到认证中心。

序号16:  认证中心收到请求，发现TGC对应了一个TGT，于是用TGT签发一个ticket，并且返回给浏览器，让他重定向到payxiaoguicomCAS Client客户端。

序号17: 根据上面响应回来的地址，进行重定向到payxiaoguicomCAS Client客户端

序号18:  payxiaoguicomCAS Client客户端带着ticket去认证中心验证是否有效。

序号19:  认证成功，把用户信息保存到客户端的session中，并把客户端的SessionID设置在Cookie中。当用户下次访问payxiaoguicomCAS Client客户端，直接登录，无需验证。

序号20:  告知浏览器可以进行访问

CAS单点登录的原理分析大致就是上述的这些，至于CAS单点登录的具体实现，将在下篇博客中写道。

CAS 原理和协议 从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。CAS Server 需要独立部署，主要负责对用户的认证工作；CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。图1 是 CAS 最基本的协

通过上述部署与配置，多个Web应用已经可以共用一个登录服务。但是，上述过程中作为CAS Client端的Web应用只取得了用户登录名称信息，而在实际应用中，Web应用往往需要获得登录用户更多的信息，例如会员等级、性别、住址等。要达到此目的，只需对Server端稍做修改即可实现。

1 服务端配置及修改

假定上述存储用户信息的数据表userinfo中还包含一个名为address的用于存储用户地址的字段，而Web应用程序希望能够从CAS Server处获得当前登录用户的地址信息，则Server端需要按以下内容修改deployerConfigContextxml。部分配置说明请参见注释。

<!--将原有attributeRepository配置注释 -->

<!--

<beanid="attributeRepository"

class="orgjasigservicespersondirsupportStubPersonAttributeDao">

<propertyname="backingMap">

<map>

<entrykey="uid" value="uid" />

<entrykey="eduPersonAffiliation" value="eduPersonAffiliation"/>

<entrykey="groupMembership" value="groupMembership" />

</map>

</property>

</bean>

-->

<!--新增attributeRepository配置(开始) -->

<bean class="orgjasigservicespersondirsupportjdbcSingleRowJdbcPersonAttributeDao"id="attributeRepository">

<!-- 指定使用的数据源，此处dataSource是已配置好的数据源 -->

<constructor-arg index="0"ref="dataSource"/>

<!-- 从数据库中查询信息的SQL语句，通常只需要修改表名即可 -->

<constructor-arg index="1" value="select fromuserinfo where {0}"/>

<propertyname="queryAttributeMapping">

<map>

<!-- 上述查询的参数，将userName替换为表中表示用户名的字段名称 -->

<entrykey="username" value="userName"/>

</map>

</property>

<propertyname="resultAttributeMapping">

<map>

<!-- 需要返回给Web应用的其它信息，多个信息时可继续增加entry节点-->

<!--key值为数据表中的字段名称，value值为Client端取值时的名称标识-->

<entry key="address" value="address"/>

</map>

</property>

</bean>

<!--新增attributeRepository配置(结束) -->

<bean

id="serviceRegistryDao"

class="orgjasigcasservicesInMemoryServiceRegistryDaoImpl">

<propertyname="registeredServices">

<list>

<beanclass="orgjasigcasservicesRegexRegisteredService">

<propertyname="id" value="0" />

<propertyname="name" value="HTTP and IMAP" />

<propertyname="description" value="Allows HTTP(S) and IMAP(S)protocols" />

<propertyname="serviceId" value="^(https|imaps)://" />

<propertyname="evaluationOrder" value="10000001" />

<!--增加此项配置 -->

<property name="ignoreAttributes" value="true"/>

</bean>

… …

</list>

</property>

</bean>

CASServer要将额外的信息传递至Client端，还需要修改完成信息组装的文件WEB-INF/view/jsp/protocol/20/casServiceValidationSuccessjsp。casServiceValidationSuccessjsp负责组装包含用户信息的XML，因此修改部分是将需要传递的额外信息加入到它最终生成的XML文件之中。具体修改如下：

<cas:serviceResponsexmlns:cas='http://wwwyaleedu/tp/cas'>

<cas:authenticationSuccess> <cas:user>${fn:escapeXml(assertionchainedAuthentications[fn:length(assertionchainedAuthentications)-1]principalid)}</cas:user>

<!-- 新增额外信息(开始) -->

<c:iftest="${fn:length(assertionchainedAuthentications[fn:length(assertionchainedAuthentications)-1]principalattributes)> 0}">

<cas:attributes>

<c:forEachvar="attr"items="${assertionchainedAuthentications[fn:length(assertionchainedAuthentications)-1]principalattributes}">

<!--注意此行的正确写法，网上资料基本都是错误的--> <cas:${fn:escapeXml(attrkey)}>${fn:escapeXml(attrvalue)}</cas:${fn:escapeXml(attrkey)}>

</c:forEach>

</cas:attributes>

</c:if>

<!-- 新增额外信息(结束) -->

<c:if test="${not emptypgtIou}">

<cas:proxyGrantingTicket>${pgtIou}</cas:proxyGrantingTicket>

</c:if>

<c:if test="${fn:length(assertionchainedAuthentications)> 1}">

<cas:proxies>

<c:forEachvar="proxy" items="${assertionchainedAuthentications}"varStatus="loopStatus" begin="0"end="${fn:length(assertionchainedAuthentications)-2}"step="1">

<cas:proxy>${fn:escapeXml(proxyprincipalid)}</cas:proxy>

</c:forEach>

</cas:proxies>

</c:if>

</cas:authenticationSuccess>

</cas:serviceResponse>

2 Java Client端取得更多用户信息

Java Client端不需要做任何修改就可以继续正常使用CAS服务，如果需要取得用户更多信息，可以通过AttributePrincipal对象取得Attribute列表(一个Map对象)后进行查询。

修改前述Java Client的示例代码，在最后追加取得address信息的代码，重启服务并重新访问页面，可以看到页面上显示了当前用户的address信息。

<%@pageimport="orgjasigcasclientauthenticationAttributePrincipal" %>

<%@pageimport="orgjasigcasclientvalidationAssertion" %>

<%@page import="javautil" %>

<%

String loginName1 = requestgetRemoteUser();

%>

requestgetRemoteUser(): <%=loginName1%><br/>

<%

AttributePrincipal principal = (AttributePrincipal)requestgetUserPrincipal();

String loginName2 = principalgetName();

%>

requestgetUserPrincipal()getName():<%=loginName2%><br/>

<%

Object object =requestgetSession()getAttribute("_const_cas_assertion_");

Assertion assertion =(Assertion)object;

String loginName3 =assertiongetPrincipal()getName();

%>

requestgetSession()getAttribute("_const_cas_assertion_")getPrincipal()getName():<%=loginName3%><br/>

首先回答你第一个问题，安全证书是tomcat或者apache用于开启ssl安全的socket链接使用的，也就是支持https协议的。一般我们都用tomcat作为应用服务器，这样就需要tomcat首先支持https协议，开启https很简单，找一下官方的文档资料，我在这里简单说一下，首先在部署tomcat的机器上为jdk（确切的说是jre，不过通常我们都在tomcat的服务器上安装jdk而不是jre）生成证书，使用jre自带的keytool工具来生成即可，生成证书的过程中注意一点，就是CN项，也就是第一个字段，是服务器的域名，比如本机测试的话可以用localhost。使用以下语句

1 keytool -keystore keystore -alias acegisecurity -genkey -keyalg RSA -validity 9999 -storepass password -keypass password

What is your first and last name（这个就是CN项）回答localhost即可

其他随便填写即可。

2 keytool -export -v -rfc -alias acegisecurity -file acegisecuritytxt -keystore keystore -storepass password

这一步是导出key。

3 复制 acegisecuritytxt 到 %JAVA_HOME%\jre\lib\security  

4 复制 keystore 到 %CATALINA_HOME %

5 控制台窗口（如果是Windows系统就是dos窗口）下进入 %JAVA_HOME%\jre\lib\security

6 keytool -import -v -file acegisecuritytxt -keypass password - keystore cacerts -storepass changeit -alias acegisecurity

向虚拟机中导入证书

接下来，用编辑器打开%CATALINA_HOME%/conf/serverxml，找到<Connector port="8443" maxHttpHeaderSize="8192"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true"

acceptCount="100" scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS" />

这一行默认是被注释掉的，取消注释，并加入keystoreFile="keystore" keystorePass="password"这两个属性，注意keystoreFile属性可以使用keystore文件的绝对路径，也可使用基于%CATALINA_HOME%环境变量的相对路径，keystorePass是访问keystore的密码，应和上面制作证书时设定的密码保持一致。

访问https://localhost:8443，应弹出一个对话框，告知用户正要访问的站点的证书不安全，是否接受，确认接受，应可看到那只熟悉可爱的小猫。

通过以上步骤就为tomcat配置了ssl。

配置了ssl，然后就是把cas server的war部署到这个tomcat下就可以了，到此，你的cas服务器就算部署成功了，但是，cas server那个war默认是使用userproperties中的那么几个用户做认证，要实现不同类型的认证方式还需要自己开发，这里不具体讲了，可以参考官方文档，也可以问我。呵呵：）

部署了cas服务，接下来就是接入client application了。

接入application有三种方式，一种是使用acegisecurity，很好用，但是很复杂；一种是使用cas提供的cas client，简单快捷，适应各种恶劣环境，哈哈；最后一种是lam的一个开源项目，没试过，不敢说怎么样。前两种不明白可以找官方文档，也尅问我，哈哈。

就第一个问题说的较详细，实在打字太多，有点累了。后面的有点粗糙，不过对于有心的人我相信还是很受用的。总结了很久的东西，希望对你有帮助。

　　尊敬的用户，您好！很高兴为您答疑。

　　您在利用cas开发单点登录系统时，不应该使用跨域的跳转，如果因为服务器部署架构的问题，不得不跨域也该考虑利用接口进行数据传递。而您贴出来的实例bean亦或滤镜等代码，并不会对于您浏览器的跳转产生实质的影响。您的主要问题是在地址重定向上出现了逻辑上的死循环。

　　希望我的回答对您有所帮助，如有疑问，欢迎继续咨询我们。