You can easily solve this by implementing an expiration policy that checks how frequently the TGT is "used"
Also note that Denial of Service attempts affect all applications (you're really potentially DOSing the application also) and are often best handled at the network level (or at least not at an application specific level). Cheers, Scott On Tue, May 5, 2009 at 7:26 AM, Marvin Addison <[email protected]>wrote: > > STEP 2: > > User A: logins in and is redirected to > > CAS.http://example.service.com?ticket=newTicket1 > > CAS set cookie > > STEP 3: > > User A throws ticket away. and returns to service, automated! > > Just to clarify, you mean throws the service ticket away while > preserving the CASTGC cookie containing the TGT. (Discarding the TGT > would require reauthentication to obtain any new tickets, and > therefore not be automated.) > > You've outlined an interesting possibility for a denial of service > attack against CAS through resource consumption of service ticket > storage, but I believe such an attack could be largely mitigated by > both reducing the service ticket expiration period and configuring the > RegistryCleaner component to run more frequently to purge expired > tickets and reclaim storage space. I think if you could provide a > proof-of-concept for a denial of service condition, solutions > including one similar to what you proposed might be considered for > CAS4. > > 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-user > -- 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-user
