TGT Expiration Policy question

30 views
Skip to first unread message

Daniel Ellentuck

unread,
Apr 3, 2020, 3:56:21 PM4/3/20
to CAS Users
I'd like to add a MaximumNumberOfUses condition to org.apereo.cas.ticket.support.TicketGrantingTicketExpirationPolicy, which establishes a sliding expiration window for the TGT.  I don't see anything that does exactly that. Did I miss something?  (I'm currently using 5.3.x, but this seems consistent across all modern versions.) If not, I can submit a PR.

Thanks,

   Dan

Dan Ellentuck
Columbia University I.T.

Ray Bon

unread,
Apr 3, 2020, 4:25:26 PM4/3/20
to cas-...@apereo.org
Dan,

The sliding window for TGT is affected by proxy ticket requests.
Even if you do not have a proxied service, this could still limit the number of applications a user logs in to.

Are you trying to limit the number of times the TGT can be used or limit the number of times one particular application can renew its session before requiring a password prompt?

If the latter, perhaps adding the counter to the cas client and then have the login request send the 'renew' parameter, which will force login. Or, adding it to the service definition.
Both of these options would require many code changes.

Ray
-- 
Ray Bon
Programmer Analyst
Development Services, University Systems

I respectfully acknowledge that my place of work is located within the ancestral, traditional and unceded territory of the Songhees, Esquimalt and WSÁNEĆ Nations.

Daniel Ellentuck

unread,
Apr 3, 2020, 5:05:15 PM4/3/20
to CAS Users
Hi Ray, et. al.,

Thanks. I think it's a simpler use case than what you describe. TGTs can be expired based on a variety of ticket state conditions like a sliding window or a simple expiration time (or in theory, any other contextual information.) These expiration rules are expressed in the TGT's expiration policy. CAS comes with a number of these policies out of the box. See, e.g., org.apereo.cas.ticket.support.TicketGrantingTicketExpirationPolicy, which uses a sliding window. I want a TGT expiration policy that ORs a sliding window with a maximum number of tickets to address a condition that can arise from application or browser error and that causes a lot of service tickets to be generated from a single TGT.  It's not a case of throttling, since it's not so much the frequency as the total number of service tickets that's the issue. It doesn't look like there is an expiration policy that does exactly that.

Thanks,
   Dan


--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/8e1f54fed3a33973654cde120d84cd88b7515716.camel%40uvic.ca.

Ray Bon

unread,
Apr 3, 2020, 5:26:01 PM4/3/20
to cas-...@apereo.org
Dan,

Have you experienced a rogue application that did this?

Sometimes one of our applications gets its session mixed up and repeatedly tries to log in but the browser traps that with a 'too many redirects'.

As an example of high ticket use; we have a web based email client that uses cas proxy tickets to contact the imap server. every action that the user does, plus the background check for new mail, requires a new proxy ticket.

If you could limit the check to ST creation rather than ticket creation in general ...

You might have to include the IP address. But that might affect roaming connections.

Ray

Daniel Ellentuck

unread,
Apr 3, 2020, 6:15:49 PM4/3/20
to CAS Users
Hi Ray,

I've encountered a few cases of application error, which I doubt were malicious. I've also seen what may be browser error (or browser difference) where the browser does not short circuit the request with Too Many Redirects. In both those cases, I just want to add a sanity check to the TGT to prevent it from issuing a large number of tickets. I went and implemented my own ticket expiration policy, which was straightforward, but I want to check if I'm not missing some combination of currently available ticket expiration policy and CAS properties that would make this happen: sliding window OR max number of tickets.  

Thanks,
Dan

Reply all
Reply to author
Forward
0 new messages