SSO-CAS单点登录

基本概念

单点登录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 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 然后做下面的事情

1. 如果User持有TGC且其还没有失效，那么久走基础协议图的Step4,达到了SSO的效果
2. 如果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验证票据，允许用户访问。