Hi Rama,
There is no need for separate SecurityManager instances - there should
only be a single SecurityManager per application.
Here's how I would solve this problem with Shiro's current code base:
1. Create your own AuthenticationToken implementation that can retain
the type of authentication that will occur. For example, you could
create the following:
public TargetedAuthenticationToken extends UsernamePasswordToken {
...
private String target = 'foo'; //
getTarget/setTarget, etc.
...
}
When authenticating a Subject, instances of this class will be created
and submitted to the subject.login method.
2. In your Realm implementations, override the supports method to
inspect the submitted token and return true iff the Realm supports
authentication for that particular target, e.g.:
public FooRealm extends AuthorizingRealm {
...
@Override
public boolean supports(AuthenticationToken token) {
if (token instanceof TargetedAuthenticationToken) {
return
((TargetedAuthenticationToken)token).getTarget().equals("foo");
}
return false;
}
}
Same thing for your BarRealm that checks the target to equal "bar".
This ensures that the SecurityManager's Authenticator will only call
on the Realm(s) that 'support' the submitted token.
3. Create an AuthenticatingFilter [1] subclass that knows how to
construct different AuthenticationToken instances based on
configuration. FormAuthenticationFilter and
BasicHttpAuthenticationFilter are example subclasses that already
exist. You could subclass one of those depending on how you perform
authentication.
In your AuthenticatingFilter subclass, override one of the createToken
methods suitable for your needs. That implementation, based on the
filter's configuration, would construct an AuthenticationToken that
encapsulates information useful to determine which Realm should
perform authentication. For example:
@Override
public AuthenticationToken createToken(....) {
TargetedAuthenticationToken token = new
TargetedAuthenticationToken(username, password);
token.setTarget(this.getTarget()); //'this.getTarget()' returns
the 'target' attribute configured in shiro.ini (see below)
return token;
}
You can configure the target in the filter subclass in shiro.ini. For example:
[main]
fooAuthc = com.mycompany.shiro.filter.authc.MyAuthenticatingFilterSubclass
fooAuthc.target = foo
fooAuthc.loginUrl = /foo/login
barAuthc = com.mycompany.shiro.filter.authc.MyAuthenticatingFilterSubclass
barAuthc.target = bar
barAuthc.loginUrl = /bar/login
[urls]
/foo/** = fooAuthc
/bar/** = barAuthc
[1]
http://shiro.apache.org/static/current/apidocs/org/apache/shiro/web/filter/authc/AuthenticatingFilter.html
HTH!
Les Hazlewood
CTO, Stormpath | http://www.stormpath.com | 888.391.5282
twitter: @lhazlewood | http://twitter.com/lhazlewood
blog: http://leshazlewood.com
stormpath blog: http://www.stormpath.com/blog/
On Sat, Apr 7, 2012 at 12:09 AM, rama.casturi <[email protected]> wrote:
> I am trying to find a best practice solution for my situation. I have two
> different sets of urls in my webapp that need to be secured/authenticated
> against two different sets of user bases.
>
> For example, the /foo/* urls are to be accessible only to a certain set of
> users based on username/pwd tokens. And another set /bar/* urls are to be
> accessible only to a set of users (stored in a different database table from
> the first set) via a auth token mechanism (which they can obtain by
> accessing /bar/login and supplying a username/pwd).
>
> I want to understand how to structure the shiro filter(s) in my web.xml and
> the corresponding shiro filter bean definition in my applicationContext.xml.
> Should I be using two different shiro filters (one for each url pattern),
> mapping to two different bean in the context file, where each bean has its
> own security manager that is configured with its own realm (each realm
> responsible for authenticating against the corresponding user base table).
>
> I understand it is a long winded question, but I did search through quite a
> few pages on the forum, but did not see anyone asking a similar question. I
> would appreciate some help/guidance on the best practice.
>
> Thanks
> Rama
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/Multiple-security-managers-and-realms-to-handle-authentication-for-different-sets-of-urls-tp7445068p7445068.html
> Sent from the Shiro User mailing list archive at Nabble.com.
