关于Apereo CAS中的几种timeout定义

1. session timeout: 

顾名思义，就是session超时时间(CAS中默认配置是5分钟)，在CAS中使用了spring workflow来做登录和登出的流程，这些流程中的数据都是存在当前session中的，大家应该看到登录页面表单元素中有lt/execution，这些是在打开登录页面时由login workflow生成，当你提交表单时会与session中的lt/execution进行校验，所以，当你打开登录界面，在超过session timeout时间后再提交表单，当前登录将是无效的，直接表现就是再次会到登录界面，所以这个还是有点坑的，看起来不是特别合理。另外，值得一提的是当你在登录流程中加入验证码功能时，尤其需要注意的是生成验证码的controller不能是 /captcha 这种请求路径，它会导致登录页面在产生验证码时再次生成新的 lt/execution，经常会让第一次登录无效，因为 lt/execution 不能通过校验，最好写成  /captcha.jpg 什么的，因为login workflow会认为这是静态资源而不刷新  lt/execution，从而保证  lt/execution 在整个session有效期内都是有效的。

具体配置点：

web.xml

<session-config>

  <!-- Default to 5minute session timeouts -->

  <session-timeout>5</session-timeout>

</session-config>

 

另外，在CAS登录成功后，基于对内存利用的考虑，session会在2秒内失效，尽管session timeout的时间还未到。所以，这里也有一个坑，当你登录成功后快速退出，然后回到登录界面，这时有可能登录页面还是使用的之前的session，因为2秒还没有到， lt/execution 还是放在之前的session中，但是当你提单表单时，session已经失效， lt/execution 也就无效了，同样会导致此次登录无效，依然会回到登录界面，当然，解决办法可以是调整登录成功后session超时时间的大小，但是我不认为这是一个好的解决方案，最好根据业务场景来考虑。

具体配置点：

cas-servlet.xml

<beanid="terminateWebSessionListener"class="org.jasig.cas.web.flow.TerminateWebSessionListener"/>

类：TerminateWebSessionListener 有以下注释，请参考

Listener to expireweb session as soon as the webflow is ended. The goal is to decrease memoryconsumption by deleting as soon as possible the web sessions created mainly forlogin process.

 

2.TGT timeout(TicketGrantingTicket)

当登录成功后，CAS会为次此登录成功授权生成一个TGT，后面所有的是否登录的判断都是基于TGT，如果子系统访问CAS server会首先判断当前cookie是否存在TGT，且是否有效，TGT默认超时时间是7200s，也就是2(timeToKillInSeconds)个小时，也就是说子系统之间跳转在2个小时之内不会要求再次登录，TGT的时间会在每一个子系统访问CAS server时重新计时，每增加一个子系统访问，就会有一个新的2个小时。另外，需要注意的是，此TGT最大超时时间为8(maxTimeToLiveInSeconds)小时，如果TGT存活时间超过8个小时，不管子系统有没有访问CAS server都会要求重新登录，那怕你前一个子系统是在前一分种访问，另外的子系统在2个小时之内访问也会要求重新登录，因为TGT总的存活时间已经超过8个小时。

具体配置点：

ticketExpirationPolicies.xml

<!-- TicketGrantingTicketExpirationPolicy: Default as of 3.5 -->

<!-- Provides both idle and hard timeouts, for instance 2 hour sliding window with an 8 hour max lifetime -->

<bean id="grantingTicketExpirationPolicy" class="org.jasig.cas.ticket.support.MyTicketGrantingTicketExpirationPolicy"      p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}" 

      p:maxTimeToLiveInSeconds="${tgt.maxTimeToLiveInSeconds:28800}" <!-- TGT最大存活时间，默认8小时 -->      

      p:timeToKillInSeconds="${tgt.timeToKillInSeconds:7200}"/> <!-- 登录成功后，业务系统在2个小时内请求TGT得有效 -->

 

3.ST timeout(Service Ticket)

ST就是为每一个子系统生成的Ticket，当访问CAS server时我们的请求地址一般是:https://xxx.xxx.xxx.xxx/cas/login?service=https://xxx.xxx.xxx.xxx/a，每一个子系统我们可以理解为是一个Service，当访问CAS server时CAS首先判断是否登录，如果登录cookie中就会有上面提到的TGT，如果TGT有效，那么表示已经登录，并且会为https://xxx.xxx.xxx.xxx/a生成一个Ticket，这个就是ST，CAS会把这个ST返回给https://xxx.xxx.xxx.xxx/a，a系统拿到ST后会再次请求CAS server，并传入这个ST到CAS server，CAS server会验证ST的合法性，如果这个a系统传入的ST就是CAS server返回给a系统的ST，那么认为是有效的，这时才会将username或者其他登录信息返回给a系统，至此登录验证流程结束。那么，ST是有存活时间的，系统要求是拿到ST后默认10s(timeToKill)内完成ST的验证，并且只能验证一次(numberOfUses)，如果超过10s，那么ST将无效，CAS server 会生成一个新的ST，并且重复此验证流程。

具体配置点：

ticketExpirationPolicies.xml

<!-- Expiration policies -->

<util:constantid="SECONDS"static-field="java.util.concurrent.TimeUnit.SECONDS"/>

<beanid="serviceTicketExpirationPolicy"class="org.jasig.cas.ticket.support.MyMultiTimeUseOrTimeoutExpirationPolicy"
      c:numberOfUses="1"c:timeToKill="${st.timeToKillInSeconds:10}"c:timeUnit-ref="SECONDS"

      c:numberOfUses="1"c:timeToKill="${st.timeToKillInSeconds:10}"c:timeUnit-ref="SECONDS"/>