The notion of used is dependent on the ticket type itself. You use a TGT every time you grant a service ticket. You use an ST every time you check its validity (even if validity is as simple as comparing two strings).
In your example, you defined a policy that says if you use the TGT, and two seconds has not passed before someone checks its validity, then its expired. Throttling expiration policies are not really the best test of this since their expired/unexpired is often transient. -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Mon, Apr 22, 2013 at 1:28 PM, Misagh Moayyed <[email protected]> wrote: > OK, but even in that context I am not sure what to make of the current > behavior. Does it make sense to imply that if a TGT grants an ST, that ST > is “used” once? Or if the ST is just being checked for a service match, > does it make sense to call it used? I am not sure that it does. **** > > ** ** > > Shouldn’t we decide on an actual and clear definition of what used in the > ticketing context is? I tend to align that more with validation calls and > how then it might be relevant to the expiration policy, (which is what the > current behavior seems to slightly imply), but perhaps, there can be a more > accurate description? If the ticket state is managed by something else, and > the ticket itself has no way of knowing what that something is or how it’s > going to use the ticket, it seems confusing to me let the ticket itself be > responsible for figuring out whether or not it’s “used”. Makes sense? **** > > ** ** > > To put that in better context, it’s not clear why the below test would > fail:**** > > https://gist.github.com/mmoayyed/5436911 **** > > ** ** > > ** ** > > *From:* Scott Battaglia > [mailto:[email protected]<[email protected]>] > > *Sent:* Sunday, April 21, 2013 2:33 AM > > *To:* [email protected] > *Subject:* RE: [cas-dev] Question on AbstractTicket.updateState()**** > > ** ** > > Successful or failed validation is irrelevant to state update. State is > updated when a ticket is used. A ticket itself determines when it is used. > **** > > On Apr 20, 2013 11:52 AM, "Misagh Moayyed" <[email protected]> wrote:*** > * > > Well, I think we can reasonably come up with the proper API to not break > encapsulation as much and yet actually be able to update the ticket state > after a validation event. Initially, I just wanted to confirm that the > behavior currently as far as ticket state goes does seem to want to make a > number of unwarranted assumptions that ultimately affects the expiration > policy negatively. If this analysis seems correct, we can start > brainstorming about how to better approach this. **** > > **** > > Part of the issue is that tickets currently have no way of determining a > validation event and a successful one for that matter. All that logic > happens outside and carried on by CASImpl and others. So it seems like we > either have to expose the right hooks into the ticket api or somehow send > the signal over that the ticket is actually successfully validated and its > count and status can be incremented, etc. I am considering a number of > options, but do certainly appreciate suggestions and feedback. Another > possible approach might be to delegate the ticket statement management to a > different component and not have the ticket itself remain responsible for > it?**** > > **** > > *From:* Scott Battaglia [mailto:[email protected]] > *Sent:* Friday, April 19, 2013 12:52 PM > *To:* [email protected] > *Subject:* RE: [cas-dev] Question on AbstractTicket.updateState()**** > > **** > > Only tickets can update their state. Nothing else.**** > > On Apr 19, 2013 3:49 PM, "Misagh Moayyed" <[email protected]> wrote:**** > > No, because that validation does happen down the line. If the call to > updateStatus() was done outside of isValidFor() somewhere in CASImpl when > all checks pass that would have been clearer. ST.isValidFor() could return > false if the match fails and yet the state is updated which subsequently > could cause the exp policy to kick in and consider the ticket expired. *** > * > > **** > > For STs, I think the status update should happen inside CASImpl. For TGTs, > possibly when the SSO session is established? Makes sense? **** > > **** > > *From:* Scott Battaglia [mailto:[email protected]] > *Sent:* Friday, April 19, 2013 12:14 PM > *To:* [email protected] > *Subject:* Re: [cas-dev] Question on AbstractTicket.updateState()**** > > **** > > The state is updated when its validated. Isn't that your #2?**** > > > **** > > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia**** > > **** > > On Fri, Apr 19, 2013 at 3:09 PM, Misagh Moayyed <[email protected]> > wrote:**** > > Team, > Looking at CAS ticket API and trying to better review the ticket > expiration policy, I stumbled upon the updateState() [1] method call that > I am not sure I am understanding correctly. > > This method is called in two areas: > > 1. When TGT grants an ST > http://bit.ly/ZEfGFB > > 2. When ST attempts to ensure a match between the service and the incoming > service to validate > http://bit.ly/13wXXYB > > updateState() does the following: > > 1. Records the previous last used time > 2. Records the last used time > 3. Updates the ticket usage count > > My question is: shouldn't the ticket state be updated when the ticket is > validated? Such that the expiration policy would then be able to determine > that the ticket is "actually" used once based on its update count? > > Misagh > > [1] http://bit.ly/11sfyu1 > > -- > 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**** > > -- > 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**** > > -- > 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**** > > -- > 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
