Shibboleth Developers

[Chad La Joie <>]

I guess another thing that I'll say is that one of the main goals in
v3 is to allow much greater flexibility in what can be injected "in
the flow" when processing a message.  So, while I'm personally
skeptical of either the effectiveness of some authentication "extras"
or their placement within the IdP itself, it should be much much
easier for people to create extensions, and compose them, then it is
in v2.

And like the ongoing discussion of the attribute consent UI, if people
can demonstrate the usefulness of some extension it's not overly hard
to convince me to add it to core (as long as the code is
maintainable).

On Tue, May 31, 2011 at 18:21, Chad La Joie 
<>
 wrote:
> 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
>



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