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
<richard.renome...@tcg.com> wrote:
> 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
> <den...@iplantcollaborative.org> 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 cas-user@lists.jasig.org as:
>> >> rh...@detailedbalance.net
>> >> To unsubscribe, change settings or access archives, see
>> >> http://www.ja-sig.org/wiki/display/JSG/cas-user
>> >
>> >
>> > --
>> > You are currently subscribed to cas-user@lists.jasig.org as:
>> > den...@iplantcollaborative.org
>> > To unsubscribe, change settings or access archives, see
>> > http://www.ja-sig.org/wiki/display/JSG/cas-user
>> >
>>
>>
>> --
>> You are currently subscribed to cas-user@lists.jasig.org as:
>> richard.renome...@tcg.com
>>
>> 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: richard.renome...@tcg.com | AIM: rrenomeronTCG
> OpenPGP Key ID 8CD7CFEB | www.tcg.com
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> wgt...@gmail.com
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to