Mailing-List: contact dev-help@shiro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@shiro.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: les.hazlewood@anjinllc.com
In-Reply-To: 
 <CAH9eYVq3qNA+ONjy=ZdwiRONttMKyFDhMjHsCeKvOZQi=bNEVg@mail.gmail.com>
References: 
 <CAH9eYVq3qNA+ONjy=ZdwiRONttMKyFDhMjHsCeKvOZQi=bNEVg@mail.gmail.com>
Date: Fri, 9 Mar 2012 13:21:23 -0800
Message-ID: 
 <CAETPiXby5jX3vH8YOUUtofq+74spkyOCfY-4KR5SEN9jsRjOOw@mail.gmail.com>
Subject: Re: Making the ModularRealmAuthenticator not check all realms for
 FirstSuccessfulStrategy
From: Les Hazlewood <lhazlewood@apache.org>
To: dev@shiro.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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?

Les

On Fri, Mar 9, 2012 at 9:56 AM, Brian Demers <brian.demers@gmail.com> wrote=
:
> The ModularRealmAuthenticator always loops through all the configure
> realms. =C2=A0This can get expense if you have multiple external realms
> configured (JDBC, LDAP, etc), and you are using
> the FirstSuccessfulStrategy. =C2=A0In this case where you had both a JDBC=
 and
> LDAP realm configured you would want to drop out of the loop if the Subje=
ct
> was authenticated in the JDBC realm. =C2=A0This way you do not need to ea=
t the
> cost of the LDAP query (which the results would be ignored anyway)
>
> To solve this I added a new method to the AuthenticationStrategy Interfac=
e,
> this makes the change simple, but would break backwards compatibility wit=
h
> any custom AuthenticationStrategy NOT extending from
> AbstractAuthenticationStrategy.
> https://github.com/apache/shiro/compare/trunk...first-successful-authc-st=
rategy#L1R99
>
> I cannot think of any (non hackie way) alternative to this for 1.3. =C2=
=A0Anyone
> have any thoughts? =C2=A0Or any thoughts on including this in 1.3?