My understanding is that the intent was to protect CAS server resources by forcing the user to the login screen, thus avoiding the case were the misconfigured client continuously requests new STs.
I think we could improve the the "detect and protect" behavior of TGT throttling by letting the user know that the service they tried to access is in fact misconfigured and that is why SSO failed rather then just letting CAS send them to the login screen. A note in the cas.log probably makes sense to. Perhaps this is another reason to move the throttling concept out of IsExpired(). Bill >On Sat, Aug 6, 2011 at 4:04 PM, Scott Battaglia <[email protected]> >wrote: > What is the use case for throttling the TGT? > A client configured confusingly that redirects back to the CAS server > requesting a new ticket? A robotic attack? > In either scenario I don't see that it matters whether the ticket is removed > or not. > > On Fri, Aug 5, 2011 at 8:05 AM, William G. Thompson, Jr. <[email protected]> > wrote: >> >> Folks, >> >> A first pass at TicketGrantingTicketExpirationPolicy and >> TicketGrantingTicketExpirationPolicyTests is up on >> https://issues.jasig.org/browse/CAS-1003 >> >> The policy implements the sliding and hard timeout as well as the >> throttling (cool down). >> >> However, I think there may be a problem with using isExpired for the >> throttling feature in a high load environment. If the RegistryCleaner >> happens to calls isExpired within the cool down period won't that >> purge an otherwise valid ticket? >> >> A cleaner way to implement throttling might be for the CASImpl to >> check the time between last use. >> >> Thoughts? >> >> Bill >> >> >> >> On Thu, Aug 4, 2011 at 11:04 AM, William G. Thompson, Jr. >> <[email protected]> wrote: >> > OK. I'm going pursue this today. Should I do that on: >> > >> > * >> > https://source.jasig.org/cas3/branches/cas-3_4_x_maintenance/cas-server-3.4.2 >> > (this is where the HEAD of 3.4.x current is, correct?) >> > * branch from there? >> > * something else? >> > >> > Bill >> > >> > >> > On Thu, Aug 4, 2011 at 10:50 AM, William G. Thompson, Jr. >> > <[email protected]> wrote: >> >> On Thu, Aug 4, 2011 at 9:59 AM, Marvin Addison >> >> <[email protected]> wrote: >> >>>> I therefore strongly feel the default TGT expiration policy should >> >>>> include a >> >>>> hard timeout. CAS adopters should have to customize if they want to >> >>>> opt >> >>>> out of a hard timeout >> >>> >> >>> +1 >> >>> >> >>>> It could just be TicketExpirationPolicyImpl, with properties for >> >>>> * number of allowed uses (-1 means infinite) >> >>>> * sliding window time length >> >>>> * fixed window time length >> >>>> * frequency of use throttle time length >> >>> >> >>> With reasonable defaults and the ability to make any of the time spans >> >>> infinite with a -1 value, I'd be fully behind your proposal to make >> >>> this the default policy for TGTs. I could go either way on the >> >>> recommendation to replace existing policies with this one. They're >> >>> already developed and tested -- why get rid of them? >> >> >> >> If they are superseded by the approach, deprecating/removing them >> >> overtime reduces the code/docs maintenance burden and reduces >> >> configuration complexity. >> >> >> >> >> >>> >> >>> On the matter of naming, there's simply no use case for throttling >> >>> with ST expiration policy since the number of uses should be small >> >>> enough to prevent abuse. Keeping TGT in the name is one way to >> >>> indicate this, but I do like the idea of improving the brevity of our >> >>> component names. >> >>> >> >>> --1 for the use of Impl in any component names. Don't even touch that >> >>> -- it merits it own thread on a slow day. >> >>> >> >>> M >> >>> >> >>> -- >> >>> 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
