On 2010-11-16, at 6:24 PM, Scott Battaglia wrote: > The notion has always been that you can affect downstream but not upstream > (i.e. a TGT's expiration has an effect on PGTs, but not vice versa). > > There's a few reasons: > a. I think its what CAS2 did which is what we based everything off of (and > since Yale wrote the original spec and version ... :-)) > b. if you go upstream, i.e. a PGT affects a TGT, its also affecting other > PGTs (not sure if that's really a desired behavior)
I don't really buy this argument. It makes sense to me that if you use a PGT to produce a PT, you are (indirectly) using the TGT as well, and so the last-used-time for the TGT should be updated. This doesn't affect other PGTs except that the TGT won't expire on them, but that is what we are trying to stop from happening. If the other PGTs are not being used, they will expire on their own. If they are, then they, too, should be keeping the TGT alive. > c. A PGT is held on by another system (i.e. a portal). I can in theory > continue to use that PGT even after a human is no longer present. Only a TGT > can really determine if a human is present (i.e. interacting with the CAS > server itself). > > I however, can see your point. If you're spending all your time in the > portal, you, the user, are not interacting directly with the CAS Server and > thus could be subject to an artificial timeout. This is exactly our situation. Our "portal" in this case is Zimbra, and it is various zimlets that have PGTs. It is not uncommon for a user to log into Zimbra at the beginning of the day and not logout all day. If they don't visit another CAS application, the TGT will timeout and the zimlet will have a useless PGT. > I don't know what the correct way to handle this without increasing risk too > much. One answer would obviously be for PGTs to merely check if their parent > was manually expired vs. timed out (and then they only rely on *their* > timeout). This would also work as long as the TGT didn't disappear when it expired (my (imperfect) understanding is that to use the resulting PT you need the whole chain of TGTs intact to get user information). Not sure how this would affect the handling of the TGT in the cache. > Thoughts from anyone? > > > On Tue, Nov 16, 2010 at 5:36 PM, Ray Davison <[email protected]> wrote: > On 2010-11-08, at 2:47 PM, [email protected] wrote: > > > Ray, > > > > Apparently the original issue got lost. Can you open a jira issue for this? > > We're already looking at serialization issues in 3.5 but we should see > > which ones we can resolve in 3.4.4. > > > > The issue of proxy tgt/tgt timeout is unrelated to serialization issues. > > I'll comment on that later when I'm on a real keyboard. > > Scott, > > I would like to here your thoughts on the PGT/TGT timeout issue. > > > Cheers > > Scott > > > > Sent from my Verizon Wireless BlackBerry > > > > -----Original Message----- > > From: Ray Davison <[email protected]> > > Date: Mon, 08 Nov 2010 14:05:15 > > To: <[email protected]> > > Reply-To: [email protected] > > Subject: [cas-dev] ProxyGrantingTicket expiration policy/difficulties > > > > Back on March 20, 2010 and April 22, 2010, Mihir Patel pointed out a > > problem with ProxyGrantingTickets not being invalidated properly when the > > granting TGT was expired. He then showed a solution that modified the > > isExpired method in AbstractTicket. > > > > After many years of using CAS at Simon Fraser University, we finally had a > > project that will make heavy use of Proxy tickets, and almost immediately > > ran into similar, but more extensive, problems with PGTs. > > > > Part of the problem is similar to what Mihir found, but we ran into it from > > the other side. We had the PGT expiring even though the PGT and granting > > TGT were being kept alive. This problem was exactly the same as Mihir's, in > > that the serialization of the PGT in the Cache (MemCache in our case) broke > > the link with the granting TGT. > > > > We found another problem as well, and I am not sure if it was a design > > decision to have it work like it does, or an oversight. The problem is that > > if the PGT is being actively used, but the granting TGT is not then the TGT > > will eventually time out and render the PGT invalid. The application that > > has the PGT has no way of keeping the TGT alive. It seems to me that when a > > PGT is used to generate a PT, this should be registered as a use of the > > granting TGT as well. > > -- > Ray Davison > Senior Systems Consultant > Institutional, Collaborative, and Academic Technologies (ICAT) > University Computing Services > Simon Fraser University > 778-782-4448 > [email protected] > > > > > > -- > 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 > > > -- > 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 -- Ray Davison Senior Systems Consultant Institutional, Collaborative, and Academic Technologies (ICAT) University Computing Services Simon Fraser University 778-782-4448 [email protected] -- 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
