基本概念
单点登录SSO ，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS(Centeral Authentication Service) 中央认证服务。
(CAS Central Authentication Service)是一款不错的针对Web应用的单点登录框架
单点登录SSO ，是目前比较流行的企业业务整合的解决方案之一。
SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
CAS(Centeral Authentication Service) 中央认证服务。
(CAS Central Authentication Service)是一款不错的针对Web应用的单点登录框架
基本术语
TGT(Ticket Granging Ticket)
TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。
TGT封装了Cookie值以及此Cookie值对应的用户信息。
用户在CAS认证成功之后，CAS生成cookie(叫TGC),写入浏览器，同时生成一个TGT对象放入自己的缓存，TGT对象的ID就是cookie的值。
当HTTP再次请求到来时，如果传来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT，如果有的话则说明用户之前登录过，如果没有，则需要用户重新登录。
TGC(Ticket Granting cookie)
存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https)是CasServer用来明确用户身份的凭证。
ST(Service ticket)
服务票据，服务的唯一标识码，有CASServer发出(Http传送）,用户访问Service时，service发现用户没有st，则要求用户去CAS获取ST。
用户向CAS发出获取ST的请求，CAS发现用户有TGT，则签发一个ST，返回给用户，用户拿着ST去访问service,service拿ST去CAS验证，验证通过后，允许用户访问资源。
服务票据，服务的唯一标识码，有CASServer发出(Http传送）,用户访问Service时，service发现用户没有st，则要求用户去CAS获取ST。
用户向CAS发出获取ST的请求，CAS发现用户有TGT，则签发一个ST，返回给用户，用户拿着ST去访问service,service拿ST去CAS验证，验证通过后，允许用户访问资源。
TGT(Ticket Granging Ticket)
TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。
用户在CAS认证成功之后，CAS生成cookie(叫TGC),写入浏览器，同时生成一个TGT对象放入自己的缓存，TGT对象的ID就是cookie的值。
当HTTP再次请求到来时，如果传来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT，如果有的话则说明用户之前登录过，如果没有，则需要用户重新登录。
TGC(Ticket Granting cookie)
存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https)是CasServer用来明确用户身份的凭证。
结构上看CAS包含两部分
CAS Server
CASServer 负责完成对用户的认证工作，需要独立部署，CASServer会处理用户名/密码等凭证(Credentials)
CAS Client
负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到CAS Server进行认证。
原则上，客户端应用不再接受任何的用户名密码等 Credentials）
CASClient 与受保护的客户端应用部署在一起，以Filter方式保护的资源。CAS最基本的协议过程
CAS Client 与受保护的客户端应用部署在一起，以Filter方式保护Web应用受保护资源，过滤从客户端过来的每一个Web请求。
1）(step1) web浏览器访问CAS Client，无session并且无票据ST，定向到CASServer（step 2），又因为浏览器中并没有cookie，故服务器端拿不到TGC，因此需要重新登录。
2）(step3) 是用户认证过程，如果用户提供了正确的CASServer会处理用户名、密码等凭证（Credentials），认证成功后，CAS生成cookie(叫TGC)，写入浏览器，同时生成一个TGT对象，再根据TGT发放票据ST，并且重定向用户到CAS Client(附带刚才产生的Service Ticket),Service Ticket是不可伪造的（strp4）
3) (step5) 拿着ST 去CAS Service验证一下，验证成功后返回用户信息(step6)
ps: 收到ST后，为什么还要验证过呢？
因为CAS知道这个用户已经登陆过，但是对于这个项目来说，我并不知道这个用户已经登陆过了，故需要验证
4）当用户访问另一个应用的服务再次被重定向到CAS Service的时候，CAS Server会主动获取这个TGC cookie 然后做下面的事情
- 如果User持有TGC且其还没有失效，那么久走基础协议图的Step4,达到了SSO的效果
- 如果TGC失效了，那么用户还是要重新认证（走基础协议图的step3）
CAS请求认证时序图
CAS服务器端登录时处理
第一步：cas往浏览器增加cookie（TGC）
CAS 向浏览器送回一个所谓的内存cookie，这种cookie并不真的保存在内存中，而只是浏览器一关闭，cookie就自动过期。这个cookie称为"ticket-grantingcookie"，用来表明用户已经成功的登录过。
这个cookie是一个加密的cookie，其中保存了用户登录的信息。用户以后其他应用客户端登录。
第二步：cas同时创建了一个ticket（ST）重定向到原来的cas客户端
认证成功后，CAS服务器创建一个很长的，随机生成的字符串，称谓"Ticket"。随后，CAS将这个ticket和成功登录的用户，以及服务联系在一起。这个ticket是一次性使用的一种凭证，它只对登录成功的用户机器服务使用一次。使用过以后立即失效。
CAS客户端应用A的处理
第一步：收到ticket后，向cas提交验证ticket
第二步：ticket验证后创建session
以后登录此应用时，没有ticket，但IE能提供session，从session中取得CASReceipt,并验证如果有效说明已经在此应用认证过，允许访问此应用。
到此为止，CAS会记录用户已在应用A登录。
用户登录到应用B是如果处理
用户进入应用B时，首先仍然会重定向到CAS服务器。不过此时CAS服务器不再要求用户输入用户名和密码，而是首先自动寻找Cookie,根据Cookie中保存的信息，进行登录。然后,CAS同样给出新的ticket重定向应用B给cas验证（流程同应用A的验证方式）如果验证成功则应用B创建session记录CASReceipt信息到session中，以后凭此session登录应用B。
原理： 1一个cookie+N个session
CAS创建cookie在所有应用中登录时cas使用，各应用通过在IE创建各自的session来标识应用是否已经登录。
cookie，在cas为各应用登录时使用，实现了只须一次录入用户密码
session：各个应用会创建自己的session标识是否登录
具体描述一下客户端消息流程
1 第一次访问http://localhost:8080/a
client:没有票据且session中没有消息所以跳转到CAS
cas:拿不到tgc故要求用户登录
2 认证成功后回调
cas：通过TGT生成ST发给客户端，客户端保存TGC，并重定向到http://localhost:8080/a
client: 带有票据(ST),所以不跳转只是后台发给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验证票据，允许用户访问。
