So a quick search of the mailing lists, Google, and issues.jasig.org shows that there has been no further discussion on this issue. I've opened https://issues.jasig.org/browse/CAS-1349 for this. Please let me know if it's a duplicate, or if there is anything I got wrong, in style or substance.
There's some interest in my organization in fixing this in the medium-to-long term, so I may start looking into it in my copious spare time. Thanks, Rich On Wed, Apr 18, 2012 at 8:03 PM, Dennis Roberts < [email protected]> wrote: > Hi Rhett, > > Sorry I didn't get back to you sooner; I got busy with other things at > work. I think you're right; I hadn't considered serialization-based ticket > registries. > > Thanks for your reply. > > Dennis > > On Mar 26, 2012, at 8:14 PM, Rhett Sutphin wrote: > > > Hi Dennis, > > > > Background: I have implemented a set of extensions for CAS 3.4 which > extend the life of all ancestor PGTs and TGTs when a PT is requested. I > promised to open source it a while ago, but I haven't gotten around to > disentangling it from the overlay for my group's CAS implementation. > > > > On Mar 26, 2012, at 6:06 PM, Dennis Roberts wrote: > > > >> > >> On Mar 22, 2012, at 6:22 AM, Marvin S. Addison wrote: > >> > >>> I'm in favor of adding support for this feature out of the box where > it's disabled by default, but can be enabled simply via configuration. I > haven't done the code review to determine effort required, but I recall > from previous discussion that it's non-trivial. Anyone want to confirm > that? > >> > >> I have only passing familiarity with the code, so I'm probably missing > something here. It seemed like it would be possible to do this by creating > a new interface (say, TicketGrantingTicketUpdatePolicy), which would have a > single method that returns a list of tickets whose last accessed timestamp > should be updated. The default implementation of this interface would a > list containing only the ticket granting ticket that is actually granting > the new service ticket. The alternate implementation could return a list > containing the current ticket granting ticket and all of its ancestors. > Then instead of just calling updateState() for itself, > TicketGrantingTicketImpl can call updateState() for every element in the > list returned by the TicketGrantingTicketUpdatePolicy implementation. > >> > >> Implementations of the TicketGrantingTicketUpdatePolicy interface could > be injected into CentralAuthenticationServiceImpl, which could then pass > the TicketGrantingTicketUpdatePolicy to > TicketGrantingTicket.grantServiceTicket so that the ticket granting ticket > doesn't have to keep track of the update policy. > >> > >> Does this sound reasonable or is there something that I'm missing? > > > > A couple of comments: > > > > 1) I'm not sure, but I don't think this proposed implementation will > work with serialization-based ticket registries. IIRC, they store each > ticket and its relationships as an isolated serialized blob. E.g., say you > have PGT-Y issued from TGT-X. You retrieve PGT-Y and update its parent. > Then you retrieve TGT-X directly. The directly-retrieved TGT-X will not > reflect the changes made to the parent of PGT-Y, even though they are both > logically TGT-X. > > > > 2) My implementation had a slightly broader goal from yours, but it > ended up needing a fairly invasive implementation. Let me describe the goal > and the implementation so you can decide if it really is more complex than > what you're trying to achieve. > > > > I wanted to have a single session expiration time for a user's session > across all applications authenticated by CAS. This could be a session > comprised of interactions with one application, or traveling between two > applications, or using one application that makes proxy calls to another > service. In all cases, I wanted to have a session lasting 30 minutes, > extended for each interaction with any application or service, expiring on > all applications and services simultaneously. Your portal case is a subset > of these requirements. > > > > In order to meet these requirements, I needed for tickets to not only be > aware of their ancestors, but also to be aware of their children. This > required extensive changes, including new ticket & registry interfaces, a > new registry implementation, a new expiration policy, and even changes to > CentralAuthenticationService itself. > > > > Rhett > > > >> > >> Thanks, > >> Dennis > >> > >> > >> -- > >> You are currently subscribed to [email protected] as: > [email protected] > >> To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > > -- > > You are currently subscribed to [email protected] as: > [email protected] > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- *Richard J. Renomeron*, Project Lead *TCG* Yes, it *can* be done! Tel: (202) 742-8460 | Fax: (202) 986-5532 Google Talk: [email protected] | AIM: rrenomeronTCG OpenPGP Key ID 8CD7CFEB | www.tcg.com -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
