Shibboleth Developers

[Chad La Joie <>]

I personally don't think basing any policy like that on IP would be a good 
idea.

But regardless, if you're not implementing it in the authn service
then you might as well not implement it at all.  If I'm an attacker
I'm just going to beat on the service that lets me then use the
password on any service I want.

Now, you could claim that the IdP is, in fact, the authn service in
your organization and so is the appropriate place for you to implement
something like this.  But that is very rarely the way people actually
deploy the IdP (though a few people do).

On Tue, May 31, 2011 at 18:13, Peter Schober 
<>
 wrote:
> * Leif Johansson 
> <>
>  [2011-05-31 23:00]:
>> In their OIX application process [1], Google by way of Eric Sachs
>> argues for rate-limiting using CAPTCHAs as a way to reduce the
>> practicality of online password guessing attempts.
>
> Jfyi, on the SimpleSAMLphp list rate-limiting (and ultimately
> temporarily locking out of accounts or IP-addresses) was suggested by
> writing unsuccessful authentication attempts for a username to a
> memcache instance -- including the user agent's IP address (replacing
> memcache with JBoss Infinispan for the Shib IdP?).
> The IP address might be relevant, e.g. when n failed authentication
> attempts for the same username come from m different IP addresses in a
> rather short period, or when n failed authentication attempts for m
> different usernames come from the same IP address in some period, etc.
>
> Either way, it's not possible to implement such policies in the
> backend authentication system used by the IdP, as any such requests
> will come the IdP's IP address, losing relevant information for policy
> construction.
> That doesn't mean that such a thing needs to be part of the IdP core,
> I suppose.
> -peter
>



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered