If this discussion belongs in the Jira issue instead of the mailing list, please let me know and I'll move it there.
I spent a little bit of time trying out the potential solution that's under discussion, and I ran into a issue when trying to update the parent ticket state(s) -- namely, that the method for updating the state is in TicketState rather than TicketGrantingTicket. The easy way out is, of course, make the UpdatePolicy deal in a list of TicketGrantingTicketImpl rather than TicketGrantingTicket, but I suspect that would not pass muster on a pull request, as I assume Ticket and TicketState are different interfaces for a reason. Is a refactoring of these two interfaces in order? There's also the issue with serialized ticket registries, although I have no idea how I'd approach that (and I'd love to hear ideas that I could explore). Thanks, Rich On Wed, Sep 11, 2013 at 10:36 AM, William G. Thompson, Jr. <[email protected] > wrote: > This issues has been known for some time, but we haven't had a > deployer need for a fix until now. Let's target a fix for 3.5.3 and > 4.0. > > Best, > Bill > > > On Thu, Sep 5, 2013 at 2:50 PM, Rich Renomeron - TCG > <[email protected]> wrote: > > So a quick search of the mailing lists, Google, and issues.jasig.orgshows > > 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 > > -- > 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-dev
