IdP custom handling for throttling misbehaving looping SPs

[Russell Beall]

On Aug 9, 2011, at 11:15 AM, Cantor, Scott E. wrote:

> On 8/9/11 2:05 PM, "Russell Beall" <beall at usc.edu> wrote:
> 
>> Has anyone implemented any custom code which can detect and throttle, or
>> error out, occurrences of an SP which is misconfigured and starts looping?
> 
> Legacy requests are usually shortcircuited by replay detection (now
> anyway, not prior to 2.3). Not sure there's any way to do that for SAML 2
> without explicitly adding features.

Actually, it is two legacy SPs which are the primary culprits.  I haven't seen these be shortcircuited.  The replay detection doesn't catch it because it appears to be a new request each time.

> If it's happening at all, the web site is misconfigured, so making sure
> the resulting message actually blames them is helpful.

Yes, it is definitely misconfiguration that causes this, and I would like to have the error page indicate the site responsible so the user can complain appropriately.

> The old IdP would block this using a cookie technique that would
> generalize to SAML 2, so could be added as a feature, or probably
> implemented within custom login handler code, but it does use up a lot of
> cookie space.

This would be nice.

Is there a record of logins in the sessionStore object which might have a history of logins processed, with timestamps?  It might be simple enough to check the history, perhaps simply with a bit of JSP code, and if there have been so many for a given entityID and principal within the last so many minutes, I could toss up an error page (no cookie processing needed for this...).

Russ.