CAS 单点登录学习

CAS实现SSO单点登录原理

安全性：

用户只须在cas录入用户名和密码，之后通过ticket绑定用户，在cas客户端与cas校验是通过ticket，并不会在网上传输密码，所以可以保证安全性，密码不被窃取

原理：

１个cookie+Ｎ个session
ＣＡＳ创建cookie在所有应用中登录时cas使用,各应用通过在ＩＥ创建各自的session来标识应用是否已经登录。
Cookie:在cas为各应用登录时使用，实现了只须一次录入用户密码
Session:各应用会创建自己的session表示是否登录

用户A，应用X，应用Y，认证中心Z。
A首次访问X时，没T没session，X告诉A去重定向找Z，A在Z登录成功，Z给A写了X的T和Z的cookie，Z告诉A可以重定向访问X了。
A带着T到了X，有T没session，X悄悄拿着T去Z检查，Z告诉X这个T登录成功的，并且Z把这个T销毁，X会为A创建session，并允许访问。
A首次访问Y时，没T没session，Y告诉A去重定向找Z，Z发现这个cookie有效，Z给A写了Y的T，告诉A可以重定向访问Y了。
A带着T到了Y，有T没session，Y和X一样。
A再访问X或Y，没T有对应的session，就允许访问了。
这里主要有两方面，一个是重定向解决跨域问题，一个是单cookie对于多个session。

CAS 登录时处理：

第一步：cas往浏览器增加cookie（ＴＧＣ）
CAS向浏览器送回一个所谓的“内存cookie”。这种cookie并不是真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为“ticket-granting cookie”，用来表明用户已经成功地登录。这个Cookie是一个加密的Cookie，其中保存了用户登录的信息。用于以后其它应用客户端登录。

第二步：cas同时创建一个ticket重定向到原来的cas客户端
认证成功后，CAS服务器创建一个很长的、随机生成的字符串，称为“Ticket”。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户及其服务使用一次。使用过以后立刻失效。

cas客户端应用Ａ的处理

第一步：收到ticket后，向cas提交验证ticket
Cas客户端收到ticket之后，应用程序需要验证ticket。这是通过将ticket 传递给一个校验URL来实现的。校验URL也是CAS服务器提供的。CAS通过校验路径获得了ticket之后，通过内部的数据库对其进行判断。如果判断是有效性，则返回一个NetID给应用程序。随后CAS将ticket作废，并且在客户端留下一个cookie。（谁来创建cookie？），

第二步：ticket验证后创建session
以后登录此应用时，没有ticket，但ＩＥ能提供session,从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用，
到此为止，ＣＡＳ会记录用户已在应用Ａ已经登录

用户登录到应用Ｂ是如何处理

用户进入应用Ｂ时，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输 入用户名和密码，而是首先自动寻找Cookie，根据Cookie中保存的信息，进行登录。然后，CAS同样给出新的ticket重定向应用Ｂ给cas验证（流程同应用Ａ验证方式），如果验证成功则应用Ｂ创建session记录CASReceipt信息到session中，以后凭此session登录应用Ｂ。
到此为止，ＣＡＳ会记录用户已在应用A和应用B进行登录，但是当用户在应用B退出cas登录时，要通知应用Ａ进行退出，如何通知应用Ａ呢？

名词解释

CAS的核心就是其Ticket，及其在Ticket之上的一系列处理操作。CAS的主要票据有TGT、ST、PGT、PGTIOU、PT，其中TGT、ST是CAS1.0协议中就有的票据，PGT、PGTIOU、PT是CAS2.0协议中有的票据。

TGT（Ticket Grangting Ticket）

TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie，写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT ，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。

ST（Service Ticket）

ST是CAS为用户签发的访问某一service的票据。用户访问service时，service发现用户没有ST，则要求用户去CAS获取ST。用户向CAS发出获取ST的请求，如果用户的请求中包含cookie，则CAS会以此cookie值为key查询缓存中有无TGT，如果存在TGT，则用此TGT签发一个ST，返回给用户。用户凭借ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源。

PGT（Proxy Granting Ticket）

Proxy Service的代理凭据。用户通过CAS成功登录某一Proxy Service后，CAS生成一个PGT对象，缓存在CAS本地，同时将PGT的值（一个UUID字符串）回传给Proxy Service，并保存在Proxy Service里。Proxy Service拿到PGT后，就可以为Target Service（back-end service）做代理，为其申请PT。

PGTIOU（Proxy Granting Ticket IOU）

PGTIOU是CAS协议中定义的一种附加票据，它增强了传输、获取PGT的安全性。
PGT的传输与获取的过程：Proxy Service调用CAS的serviceValidate接口验证ST成功后，CAS首先会访问pgtUrl指向的https url，将生成的 PGT及PGTIOU传输给proxy service，proxy service会以PGTIOU为key，PGT为value，将其存储在Map中；然后CAS会生成验证ST成功的xml消息，返回给Proxy Service，xml消息中含有PGTIOU，proxy service收到Xml消息后，会从中解析出PGTIOU的值，然后以其为key，在map中找出PGT的值，赋值给代表用户信息的Assertion对象的pgtId，同时在map中将其删除。

PT（Proxy Ticket）

PT是用户访问Target Service（back-end service）的票据。如果用户访问的是一个Web应用，则Web应用会要求浏览器提供ST，浏览器就会用cookie去CAS获取一个ST，然后就可以访问这个Web应用了。如果用户访问的不是一个Web应用，而是一个C/S结构的应用，因为C/S结构的应用得不到cookie，所以用户不能自己去CAS获取ST，而是通过访问proxy service的接口，凭借proxy service的PGT去获取一个PT，然后才能访问到此应用。

TGT、ST、PGT、PT之间关系

1：ST是TGT签发的。用户在CAS上认证成功后，CAS生成TGT，用TGT签发一个ST，ST的ticketGrantingTicket属性值是TGT对象，然后把ST的值redirect到客户应用。

2：PGT是ST签发的。用户凭借ST去访问Proxy service，Proxy service去CAS验证ST（同时传递PgtUrl参数给CAS），如果ST验证成功，则CAS用ST签发一个PGT，PGT对象里的ticketGrantingTicket是签发ST的TGT对象。

3：PT是PGT签发的。Proxy service代理back-end service去CAS获取PT的时候，CAS根据传来的pgt参数，获取到PGT对象，然后调用其grantServiceTicket方法，生成一个PT对象。

抛弃Https让Cas以Http协议提供单点登录服务

warnCookieGenerator.xml 设置

将 p:cookieSecure 值设置为 “false”

    <bean id="warnCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"          p:cookieHttpOnly="true"          p:cookieSecure="false"          p:cookieMaxAge="-1"          p:cookieName="CASPRIVACY"          p:cookiePath=""/>

deployerConfigContext.xml 设置

将 p:requireSecure 值设置为 “false”

<!-- Required for proxy ticket mechanism. --><bean id="proxyAuthenticationHandler" class="org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler" p:httpClient-ref="supportsTrustStoreSslSocketFactoryHttpClient" p:requireSecure="false"/>

客户端消息流程

1. 第一次访问http://localhost:8080/a,

   CLIENT：没票据且SESSION中没有消息所以跳转至CAS
   CAS：拿不到TGC故要求用户登录

2. 认证成功后回跳

   CAS：通过TGT生成ST发给客户端，客户端保存TGC，并重定向到http://localhost:8080/a
   CLIENT：带有票据所以不跳转只是后台发给CAS验证票据（浏览器中无法看到这一过程）

3. 第一次访问http://localhost:8080/b
   CLIENT：没票据且SESSION中没有消息所以跳转至CAS
   CAS：从客户端取出TGC，如果TGC有效则给用户ST并后台验证ST，从而SSO。
   【如果失效重登录或注销时，怎么通知其它系统更新SESSION信息呢？？
   TicketGrantingTicketImpl类grantServiceTicket方法里this.services.put(id,service);可见CAS端已经记录了当前登录的子系统】

4. 再次访问http://localhost:8080/a

   CLIENT：没票据但是SESSION中有消息故不跳转也不用发CAS验证票据，允许用户访问

cas-server 服务器端

注销后重定向到页面

cas-servlet.xml
将 p:followServiceRedirects 设置为 true

  <bean id="logoutAction" class="org.jasig.cas.web.flow.LogoutAction"        p:servicesManager-ref="servicesManager"        p:followServiceRedirects="${cas.logout.followServiceRedirects:true}"/>

java-cas-client 客户端

参见参考资料

参考资料

• CAS github

• CAS实现SSO单点登录原理

• 单点登录cas学习心得

• CAS总结之Ticket篇

• CAS SSO研究一：抛弃Https让Cas以Http协议提供单点登录服务
  

• cas-server-webapp

• java-shiro-cas-client-demo

• sso-shiro-cas