We’re doing a smooth enrollment, so users can login to privacyidea to register tokens theirselves. I want users, that already have a token registered, to do mfa login. Users without a registered token can login via password.
I had some problems configuring that behaviour, so I wanted to share how I accomplished it.
We are using LDAP resolvers. We allow users to register two token types: TOTP and webauthn
So according to the documentation, basically you have to configure two settings via policy:
login_mode: privacyIDEA (webui policy)
passthru: userstore (authentication policy)
After I set these, login with a test account failed. The test account had a TOTP token registered.
The behaviour is connected to the token type. With the configurations above, the default behaviour of privacyidea (3.8.1) for TOTP is this:
Instead of LDAP Password, the user has to enter OTP PIN and OTP Value. Example: My OTP PIN is 1234 and my TOTP Value from Authenticator App is 123456. I can login with “password” 1234123456
(as described here: 7.3. Authentication policies — privacyIDEA 3.8.1 documentation)
Not quite intuitive for users. But we can change that behaviour.
So in my case for TOTP I wanted this behaviour:
User enters LDAP password, if that is correct, present a new page where user is asked to enter TOTP value from Authenticator App.
That is achieved with these two settings:
otppin: userstore (authentication policy)
challenge_response: totp (authentication policy)
otppin: userstore tells privacyidea to ask for password from userstore (in my case LDAP password) instead of OTP PIN. So now we can login with LDAP password + OTP Value. Example: My LDAP password is pa$$w0rd and my OTP Value is 123456. I can login with pa$$w0rd123456.
challenge_response: totp tells privacyidea to trigger a separate challenge for TOTP Value. So now I can login by first entering my LDAP password and then answering the challenge created after my LDAP password was verified.
Background: Why does TOTP behave like that in privacyidea? From a technical standpoint, TOTP is not a Challenge-Response Token. Basically the user has the correct OTP value at every time. The user just has to take a look into the authenticator app to see the current valid OTP value. There is no need for the server to trigger a challenge first, because the user already has the information needed.
Now think of SMS token type. First, the server needs to trigger a SMS, that is sent to the user. Otherwise the user cannot know the current valid SMS code. So with SMS you do not need to set challenge_response: sms because token type SMS is a Challenge-Response token by design.
Same goes for WebAuthN, where the server must trigger a challenge first, which the user can then validate or not.