Oops, I meant:

Subject anotherSubject = Subject.Builder().buildSubject();

The Subject.Builder is covered here:

http://incubator.apache.org/shiro/subject.html

Cheers,

Les

On Tue, Jun 22, 2010 at 6:47 PM, Les Hazlewood <[email protected]>wrote:

> 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.
>>
>
>

Reply via email to