I’m using privacyidea 3.6 with keycloak. I have keycloak configured to use triggerchallenge.
When a user with a TOTP token that has a PIN tries to authenticate through keycloak they have to provide only the OTP without the PIN for authentication to succeed.
Versatility: Adds additional capabilities to an already capable system. Security professionals can further tailor their authentication to the organizations wants/needs.
Meeting definition of MFA: MFA is defining as using two or more factors to authenticate a user. PI obviously meets that now. Adding the ability to also require the token’s assigned PIN furthers meeting the definition.
Additional hardening: Security professionals are sometimes paranoid folk. The potential exists that someone’s user store credentials and physical device are compromised. Adding the need to know the token’s assigned PIN can mitigate that possibility.
Still why? Being more versatile? How is this? Would like to know. Why is this use case? What is the use case requirement behind this technical requirement?
(For German speaking readers, please listen to https://login-success.podigee.io/9-features-oder-konzepte
Au contraire: Having a password, a PIN and an OTP value are still two factors. A password and a PIN are not two factors. These are only one factor - only longer.
Thank you.
However, you could still do this, if you would not trigger the challenge, which is by definition used to skip the PIN.
Thus you would need to disable the triggerchallenge setting in keycloak and have keycloak verify the LDAP password, and have privacyIDEA verify a PIN and the OTP/PUSH.
The use case would be a two step authentication utilizing more than a single instance of two factors.
1st Step: User initiates authentication using user store credentials
2nd Step: User is challenged to provide their PIN+OTP.
In the event that a user’s user store credentials and OTP device are compromised, requiring the PIN with OTP can possibly mitigate unauthorized access.
A password and a PIN are the same type of factor, ‘something you know’, but that doesn’t mean having one cancels the need/want for the other.
Yes, but then we don’t have the 2-step challenge that integrates the use of user store credentials in the first step.
We configure keycloak to use triggerchallenges so that we can use TOTP and webauthn tokens concurrently. The triggerchallenge is triggered by a dedicated account and not by sending the user credentials to privacyidea. Before all this, keycloak has verified the username/password of the user in some other way (LDAP bind, kerberos, …).
I don’t fully understand why there is a difference between validating a TOTP token in a single step vs 2-step.
Giving the user the option to add a small additional protection by configuring a PIN for his/her TOTP token sound like a good idea. It would be an additional barrier to overcome for an attacker.
I am really wondering, why any of you is using triggerchallenge in the first place, since you actually can do what you so desperately want - without using triggerchallenge.
How does authentication at keycloak work
Obviously authentication at keycloaks works like this:
The user is authenticated with username and ldap password in the first step by keycloaks own ldap component.
If the ldap password was correct, the privacyIDEA plugin is called. By default this plugin does nothing, simply waiting for a user input.
The user inputs his OTP-PIN (static).
The PIN is sent to privacyIDEA. A challenge is created and sent back to the keycloak privacyIDEA plugin.
The user answers the challenge - e.g. with his Webauthn token. If you configured TOTP into this policy the workflow for TOTP-Tokens is completely the same.
Er voila: A user authenticates with LDAP-Password, PIN and OTP-Value or WebAuthn.
Now, ordinary people do not like this. They do not want to use LDAP-Password and PIN. But there is this nasty step #3, which is necessary, since otherwise no webauthn challenge would be triggered. Since privacyIDEA can not know, that a user is about to log in. So what to do now?
Only use triggerchallenge if you know what you are doing
This is where triggerchallenge comes into play. It is only to avoid the step #3! This is the only original reason for triggerchallenge! Really. Honestly.
So the authentication at the keycloak will look like this:
The user is authenticated with username and ldap password in the first step by keycloaks own ldap component.
If the ldap password was correct, the privacyIDEA plugin is called.
Before asking the user for an input, the plugin sends a triggerchallenge request to privacyIDEA for the user, who is about to log in.
A challenge is created and sent back to the keycloak privacyIDEA plugin.
The user answers the challenge - e.g. with his Webauthn token. If you configured TOTP into this policy the workflow for TOTP-Tokens is completely the same.
So you see: No PIN! Because it was the intention to get rid of the PIN.
Consider these rule of thumb privacyidea is following
Try to keep all plugins easy - or should I say dumb. So if you come up with any kind of special use case, which you think is quite logical, but honestly is special, it will most probably be turned down, because maintaining a lot of plugins with all quirks and switches sucks.
All logics should be in the backend.
Enrolling tokens in a plugin is a bad idea.
Read the complete documentation and suggest very concrete improvements. Only telling the documentation is not precise enough, does not count. Which information would be missing at which point?
