shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: Making the ModularRealmAuthenticator not check all realms for FirstSuccessfulStrategy
Date Fri, 09 Mar 2012 21:21:23 GMT
Adding the new method for 1.3 is difficult:  while not backwards
compatible, it is certainly better than changing the behavior of an
existing API.  But if we want to guarantee APR versioning guidelines -
which reinforces perceived stability (highly desirable for a security
API/framework) - it should probably go into 2.x only.

If we are to guarantee backwards compatibility, a new strategy should
be implemented that throws an Exception from the afterAttempt method.
That exception is inspected (e.g. ShortCircuitIterationException) to
trigger whether or not to continue to further realms.

Yes, this is hacky, yes, it's not ideal, but it does guarantee
backwards compatibility while still retaining existing functionality.

Because I favor stability in a security framework, my preference is to
do the hacky exception approach and then clean this up permanently in
2.x.  But I could be in the minority here.

What are peoples' thoughts on this?


On Fri, Mar 9, 2012 at 9:56 AM, Brian Demers <> wrote:
> The ModularRealmAuthenticator always loops through all the configure
> realms.  This can get expense if you have multiple external realms
> configured (JDBC, LDAP, etc), and you are using
> the FirstSuccessfulStrategy.  In this case where you had both a JDBC and
> LDAP realm configured you would want to drop out of the loop if the Subject
> was authenticated in the JDBC realm.  This way you do not need to eat the
> cost of the LDAP query (which the results would be ignored anyway)
> To solve this I added a new method to the AuthenticationStrategy Interface,
> this makes the change simple, but would break backwards compatibility with
> any custom AuthenticationStrategy NOT extending from
> AbstractAuthenticationStrategy.
> I cannot think of any (non hackie way) alternative to this for 1.3.  Anyone
> have any thoughts?  Or any thoughts on including this in 1.3?

View raw message