On Sun, Aug 7, 2011 at 10:43 AM, Scott Battaglia <[email protected]> wrote: > 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?
The implementation in ThrottledUseAndTimeoutExpirationPolicy does seem to meet the basic need. If isExpired is called by CASImpl during the cool down period, the user will then be bounced to the login screen, although with no indication as to why the SSO session expired, thus cutting off a potentially infinite loop of ST requests. There does seem to be a risk in the current implementation in conjunction with the DefaultRegistryCleaner. If the RegistryCleaner happens to call isExpired during the cool down period it will delete the ticket even though there's no indication that the CAS server is suffering from a misconfigured or rogue client. Is it is worth trying to preserve the Throttle concept in a way that doesn't suffer from this issue? I don't know. I'd like to implement a TicketGrantTicketingPolicy that doesn't run afoul of the RegistryCleaner. > >> >> 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 we should just drop the Thottling behavior from TicketGrantingTicketPolicy and more this concern outside of the CAS server altogether? >> >> 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). I meant more specifically, as in the ThrottledUseAndTimeoutExpirationPolicy use of IsExpired to indicate to the CASImpl that the ticket is being throttled. Best, Bill > 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 -- 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
