Ah, ok - the way I would do this is to create a new Subject temporarily for
the 2nd login using the Subject.Builder:
Subject currentSubject = SecurityUtils.getSubject();
Subject anotherSubject = new Subject.Builder();
anotherSubject.login(new UsernamePasswordToken(adminUsername,
adminPassword));
PrincipalCollection adminPrincipals = anotherSubject.getPrincipals();
PrincipalCollection currentPrincipals = currentSubject.getPrincipals();
((MutablePrincipalCollection)currentPrincipals).addAll(adminPrincipals);
Also you will probably want 2 Realm instances - one for each database. A
normal authentication attempt will try to call both Realms, and use the data
only from the Realm(s) that succeeds. This is perfectly fine for most
apps.
However, if you want to restrict which realm will process each type of
authentication attempt, you will need to have a custom AuthenticationToken
subclass with a flag that the Realm can inspect. Then the 'supports'
implementation on your Realm can return true or false if it wants to process
the token or not. For example:
e.g. MyRealm#supports(AuthenticationToken token) {
return token instanceof MyAuthenticationToken &&
((MyAuthenticationToken)token).getDatasourceName().equals(getDatasourceName())
}
If you don't want to do this, or if you want even more control over exactly
how the authentication attempt takes place, you can implement your own
AuthenticationStrategy and plug that in to the security manager
configuration (e.g. via INI):
securityManager.authenticator.authenticationStrategy =
com.whatever.MyAuthenticationStrategy
The default strategy is the AtLeastOneSuccessfulStrategy.
Best,
Les
On Tue, Jun 22, 2010 at 5:34 PM, nmetzger <[email protected]> wrote:
>
> Hi Les,
>
> Thanks for replying so quickly.
>
> In my application a user with admin permissions logs into the system that
> is connected to database number 1. If the same user needs to access the
> admin functionality, he needs to log into database number 2 to do admin
> tasks.
> I guess I'm just looking for the most elegant solution, trying not to
> reinvent the wheel.
>
> Natalie
>
>
> --
> View this message in context:
> http://shiro-user.582556.n2.nabble.com/authentication-as-user-and-admin-tp5208454p5211341.html
> Sent from the Shiro User mailing list archive at Nabble.com.
>
