[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    Tynamo Tapestry-Security  - Multiple Realms - How to Change Authentication Strategy
From:       Charles Karow <charles () karow ! com>
Date:       2014-12-21 16:55:39
Message-ID: 5496FB8B.9090503 () karow ! com
[Download RAW message or body]


I'm using Tynamo Tapestry-Security 0.6.0 with Tapestry 5.4, and finding 
it a very useful tool!!

I am implementing two realms for two different classes of users that are 
stored in different tables in the database; both will use 
username/password authentication, and thus the same authentication token 
type. They are mutually exclusive - any given user will be found in one 
realm and not found in the other, so I will always have one realm that 
fails to authenticate.

I see that in Tynamo the default authentication strategy has been 
replaced with a custom FirstExceptionStrategy, which improves the 
exception handling, but will only work if there is only one Realm per 
Token type. (See http://jira.codehaus.org/browse/TYNAMO-154) While I 
appreciate and value the ability to get the original exceptions, right 
now it seems more important to me to be able to have the two realms.

So it seems to me that I should change the authentication strategy to 
one of Shiro's (e.g. "First Successful" or "At Least One Successful"), 
or eventually create my own custom strategy that would give me the best 
of both worlds, by passing on the correct exceptions, while allowing 
multiple realms using the same token type.

I have tried to change the authentication strategy in my AppModule with 
the following code in addRealms():

         SecurityManager sm = SecurityUtils.getSecurityManager();
         DefaultWebSecurityManager wsm = (DefaultWebSecurityManager)sm;  
// <<---- Class cast fails
         ModularRealmAuthenticator mra = (ModularRealmAuthenticator) 
wsm.getAuthenticator();
         mra.setAuthenticationStrategy(new FirstSuccessfulStrategy());

It fails because the returned SecurityManager is actually the IOC 
ServiceProxy and not the SecurityManager object. I tried similar code in 
the Realm's constructor, with a similar failure.

So what would be the best approach?

Is there a way to get the actual service implementation from the service 
proxy?

Is there a better way to configure the authentication strategy?

Thanks in advance for your help!!!
Charles




[prev in list] [next in list] [prev in thread] [next in thread]