Spring Security与CAS结合使用的意义
web应用中一个登陆过程,其实就是完成认证与授权。
所谓认证,就是当用户试图进入系统,而系统发现用户没有登陆,就调转到登陆页面。
所谓授权,指用户认证通过之后对该用户赋权限,即该用户能够访问这个系统的哪些功能(即该用户能够访问这个系统的哪些url地址及按钮)
Cas它的功能就是进行用户名密码认证。如果spring security与cas集成,就相当于spring security自身的登录认证功能转移到cas框架上,然后spring security进行认证之后的授权。
CAS原理和协议
基础模式
基础模式SSO访问流程主要有以下步骤:
1. 访问服务:SSO客户端发送请求访问应用系统提供的服务资源。
2. 定向认证:SSO客户端会重定向用户请求到SSO服务器。
3. 用户认证:用户身份认证。
4. 发放票据:SSO服务器会产生一个随机的Service Ticket。
5. 验证票据:SSO服务器验证票据Service Ticket的合法性,验证通过后,允许客户端访问服务。
6. 传输用户信息:SSO服务器验证票据通过后,传输用户认证结果信息给客户端。
如上图: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的安全性。协议工作过程中会有两次重定向的过程。但是 CAS Client与CAS Server之间进行Ticket验证的过程对于用户是透明的(使用HttpsURLConnection)。
各服务首次访问:若用户没有登录过执行以下图全部流程。若以在其他服务中登录则执行到下图第二步
同服务第二次访问(因为之前已创建session,所以不会再去cas server)
CAS 如何实现 SSO
当用户访问另一个应用的服务再次被重定向到CAS Server的时候,CAS Server会主动获到这个TGC cookie,然后做下面的事情:
1) 如果User持有TGC且其还没失效,那么就走基础协议图的Step4,达到了 SSO 的效果;
2) 如果TGC失效,那么用户还是要重新认证 (走基础协议图的Step3)。
辅助说明
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的交互而已。
Session共享
可以通过Nginx+SpringSession实现Session共享,这样既可以同步Session信息,又能使其他应用不用再做首次认证
Cas登录过期时间
1、修改Cas Server的CASTGC过期时间
修改Cas Server下cas/WEB-INF/spring-configuration/ticketExpirationPolicies.xml(CASTGC的过期时间,单位为秒)
<bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.TicketGrantingTicketExpirationPolicy"
p:maxTimeToLiveInSeconds="28800"
p:timeToKillInSeconds="1800"/>
2、修改Cas Client的Session过期时间
向Cas Client下WEB-INF/web.xml添加以下代码(Session过期时间,单位为分钟):
<session-config>
<session-timeout>30</session-timeout>
</session-config>
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应用可以代理用户去实现后端的认证,而无需前端用户的参与。