I created two Realms and added them to the realms property of Default Web
security manager
<bean id="securityManager"
class="org.apache.shiro.web.mgt.DefaultWebSecurityManager">
<!-- Single realm app. If you have multiple realms, use the 'realms'
property instead. -->
<!--<property name="realm" ref="hdPokerRealm"/>-->
<property name="realms">
<list>
<ref bean="hdRealm"/>
<ref bean="hdFingerprintRealm"/>
</list>
</property>
<!--<property name="cacheManager" ref="cacheManager"/>-->
<property name="sessionManager" ref="sessionManager"/>
</bean>
In hdRealm we have
@Override
public boolean supports(AuthenticationToken authenticationToken) {
return (authenticationToken instanceof UsernamePasswordToken)
}
In hdFingerPrintrealm we have
@Override
public boolean supports(AuthenticationToken authenticationToken) {
return (authenticationToken instanceof FingerPrintAuthenticationToken)
}
In which FingerPrintAuthenticationToken is a custom token we created
But we get the following error.
2014-02-15 21:32:39,704 ERROR c.h.a.controller.LoginController - Error testing
credentials
org.apache.shiro.authc.AuthenticationException: Authentication token of type
[class org.apache.shiro.authc.UsernamePasswordToken] could not be authenticated
by any configured realms. Please ensure that at least one realm can
authenticate these tokens.
at
org.apache.shiro.authc.pam.AtLeastOneSuccessfulStrategy.afterAllAttempts(AtLeastOneSuccessfulStrategy.java:54)
~[shiro-core-1.2.1.jar:1.2.1]
at
org.apache.shiro.authc.pam.ModularRealmAuthenticator.doMultiRealmAuthentication(ModularRealmAuthenticator.java:235)
~[shiro-core-1.2.1.jar:1.2.1]
at
org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:269)
~[shiro-core-1.2.1.jar:1.2.1]
at
org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)
~[shiro-core-1.2.1.jar:1.2.1]
What could we be missing?
Thanks
Mark Spritzler
On Feb 14, 2014, at 1:40 AM, Dominic Farr <[email protected]> wrote:
> This line.
> ... generate a password for them, which we never send to them.
>
> This is the start of your design problem.
>
> You generate a password which the user never knows.
>
> When the user returns your system expects the user to know the unknown
> password.
>
> No amount of software will solve this problem.
>
> What is the password protecting? If the DeviceID is globally unique perhaps
> you don't need a password, the Device itself can act as a password.
>
>
> On 14 February 2014 02:12, [email protected] <[email protected]> wrote:
> So in our application (REST) we have the standard users with logging in via
> username/password. However, we also have a login as guest. However, guest
> users are still full users in our system. When a user signs in as guest for
> the first time a request is sent with just a FingerPrint, this is a HASH sent
> from the client to the REST api. To determine that this is the first time
> this fingerprint/deviceID has been sent I do a db lookup WHERE db.fingerPrint
> = loginRequest.fingerPrint.
>
> If it doesn’t return a record then that means it is a new guest and we create
> a User instance and store it in the db. We generate a username GuestNNN and
> generate a password for them, which we never send to them. If it does return,
> then we take the userName from the db and the passed in signature and create
> a SignatureAuthenticationToken, which just extends
> UsernamePasswordAuthenticationToken and the constructor we pass in username
> and fingerprint String. This works when we encrypt the fingerPrint with
> PasswordService and store it encrypted.
>
> However, this does not work then on subsequent logins by that guest, because
> in order to get the userName I have to query the db using the same WHERE
> clause
> WHERE db.fingerPrint = loginRequest.fingerPrint
>
> It fails because the incoming login request has the fingerPrint unencrypted
> and the where clause will never match what is in the db, because the db has
> it stored encrypted.
>
> If I try to just store the fingerprint in the db unencrypted, then the login
> will fail because we are using PasswordMatcher with DefaultHashService which
> will always take the fingerprint and encrypt it and compare it to what is in
> the db, which is now unencrypted. So I am sort of damned if I do, damned if I
> don’t.
>
> The login as guest request will always just have the fingerPrint, the client
> will never know or send us the userName because it doesn’t know it.
>
> We can’t use rememberMe as unauthenticated user as guest because we need to
> make them an actual user with data stored in the database that on subsequent
> logins keeps their information etc.
>
> Any ideas?
>
> Thanks
>
> Mark
>
>
