On Sat, Aug 6, 2011 at 9:41 PM, William G. Thompson, Jr. <[email protected]>wrote:
> 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. > If that's your understanding (which "understanding" isn't really a use case), then how does the current implementation not satisfy that basic need? > > 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. > At what point does this become a higher level problem? If a service is DOS attacking the CAS server (even non-maliciously), then you should have some hardware or software load balancer detecting this. Also, if a client is misconfigured, what is the expectation that this isn't caught in testing? I could see a use case for more explicit messages about ticket expiration (i.e. Your SSO has expired. Please sign in again.) but not calling out throttling specifically as the only case. I don't see this as a more important use case (or one more likely to occur) than messaging the user that they previously had a session that has now expired (which we don't do). As for logging, you should have auditing turned on, and be creating alarms based off of those logs. > > Perhaps this is another reason to move the throttling concept out of > IsExpired(). > There is no throttling concept in the expiration of a ticket (nor is there a usage, time, etc. concept). The only concept is whether the ticket is expired or not, based on whatever definition you want to use (that fits within the constraint of the fact that if the expiration isn't permanent via the parameters you chose, then the expiration is potentially transient). Cheers, Scott > > 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 > > -- 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
