Keycloak provider realm missing in token request

mat1010 · September 17, 2022, 9:10am

We are having issue using PI with multiple realms through Keycloak.

Right now the authentication only works with users in the default realm. We did configure the Keycloak provider to send the corresponding realm for the tenant. The realm is properly being sent on the triggerchallenge request, but when sending the token request it seems that no realm at all is sent and therefore the default realm of PI is being used

Triggerchallenge request

[2022-09-17 10:39:38,619][32823][140254540224256][DEBUG][privacyidea.api.lib.utils:253] Update params in request POST https://mfa.example.org/auth with values.
[2022-09-17 10:39:38,634][32823][140254540224256][DEBUG][privacyidea.api.before_after:100] End handling of request '/auth?'
[2022-09-17 10:39:38,640][32823][140254380001024][DEBUG][privacyidea.api.before_after:85] Begin handling of request '/validate/triggerchallenge?'
[2022-09-17 10:39:38,641][32823][140254380001024][DEBUG][privacyidea.api.lib.utils:253] Update params in request POST https://mfa.example.org/validate/triggerchallenge with values.
[2022-09-17 10:39:38,641][32823][140254380001024][DEBUG][privacyidea.lib.user:186] Entering get_user_from_param with arguments ({'user': 'foo', 'realm': 'bar'},) and keywords {}

Token request:

[2022-09-17 10:39:39,482][32823][140254540224256][DEBUG][privacyidea.api.before_after:100] End handling of request '/auth?'
[2022-09-17 10:39:39,486][32823][140254380001024][DEBUG][privacyidea.api.before_after:85] Begin handling of request '/token/?user=foo'
[2022-09-17 10:39:39,487][32823][140254380001024][DEBUG][privacyidea.api.lib.utils:253] Update params in request GET https://mfa.example.org/token/ with values.
[2022-09-17 10:39:39,487][32823][140254380001024][DEBUG][privacyidea.lib.user:186] Entering get_user_from_param with arguments ({'user': 'foo'},) and keywords {}
[2022-09-17 10:39:39,488][32823][140254380001024][DEBUG][privacyidea.lib.user:186] Entering split_user with arguments ('foo',) and keywords {}
[2022-09-17 10:39:39,488][32823][140254380001024][DEBUG][privacyidea.lib.config:186] Entering get_from_config with arguments ('splitAtSign',) and keywords {'return_bool': True}
[2022-09-17 10:39:39,488][32823][140254380001024][DEBUG][privacyidea.lib.config:327] Cloning request-local config from shared config object
[2022-09-17 10:39:39,490][32823][140254380001024][DEBUG][privacyidea.lib.config:198] Exiting get_from_config with result True
[2022-09-17 10:39:39,490][32823][140254380001024][DEBUG][privacyidea.lib.user:198] Exiting split_user with result ('foo', '')
[2022-09-17 10:39:39,491][32823][140254380001024][DEBUG][privacyidea.lib.realm:186] Entering get_default_realm with arguments () and keywords {}
[2022-09-17 10:39:39,491][32823][140254380001024][DEBUG][privacyidea.lib.realm:198] Exiting get_default_realm with result defrealm
[2022-09-17 10:39:39,491][32823][140254380001024][DEBUG][privacyidea.lib.user:186] Entering __init__ with arguments (User(login='', realm='', resolver=''),) and keywords {'login': 'foo', 'realm': 'defrealm', 'resolver': None}

Is there anything we have to do on PI side to correctly match the users?

UPDATE: When manually assigning / generating a token, the authentication works. So it looks like there’s an issue with creating the token for a user on 1st login.

cornelinux · September 17, 2022, 6:33pm

Creating tokens within keycloak is the most dumbest idea ever. Honestly.

This is an external PR which to my knowledge was simply merged.

If this f***ing feature does not work for you, you need to issue another pull request.

I am highly annoyed by this idiot idea to enroll tokens within the the client applications like keycloak.
Why it sucks?
I does not provide a decent security and control.
Everone under the sun thinks it should work in a different way. Yes. It is a totally idiot idea and this is why everyone feels a bit irritated and has different expection.

As for me, I personally wouldnever ever added such a functionality.

cornelinux · September 17, 2022, 6:49pm

@mat1010 I am sorry for the harsh words.
But this is a never ending story. There are endless good reasons to not enroll tokens within the client (in this case keycloak).

Enrolling tokens is a sensitive process. And you need a controlled environment.
If you want to do 2FA at keycloak this is the best proof, that this is not a controlled environment.

You have no additional control during the enrollment process.
Over and over people/users come around and think they want to do it this way. Since Google does it this way — they provide a service for end users and leave all the control an responsibility to the end user. You do not want to do this in enterprise environements.
…since nextcloud does it this way — and they have aboslutely no knowledge and experience in 2FA.

Do not enroll the 2nd factor at the same place, where you actually want to use the 2nd factor!

This feature is in the current release since a colleague out of the goodness of his heart merged a not well engineered community PR in the master branch.

You want to put a bit more thinking into your enrollment process - trust me.
And you might consider waiting for this feature:

github.com/privacyidea/privacyidea

Multi-Challenge: Allow token enrollment during /validate/check

opened 10:47AM - 04 Feb 22 UTC

cornelinux

Type: Feature request Type: Main feature Topic: Enrollment Topic: multichallenge

We have the possibility to add mechanism in a multi-challenge response communica…tion during `/validate/check`. Currently we do this for [changing pins](https://github.com/privacyidea/privacyidea/blob/28f138522618915950769a0fe196720f3b417393/privacyidea/lib/challengeresponsedecorators.py#L76) and for [resyncing tokens](https://github.com/privacyidea/privacyidea/blob/28f138522618915950769a0fe196720f3b417393/privacyidea/lib/challengeresponsedecorators.py#L169). The goal is, to also allow enrollment of tokens during /validate/check. To do so, we need to be able to provide an image in the challenge. This image would be the QR code to enroll e.g. an HOTP or TOTP token. We could also enroll a token by asking the user for an email-address or phone number (SMS token). A possible workflow would then be: 1. User authenticates with an enrollment specific token like a `registration` token. 2. Challenge Response kicks in and displays the QR code to the user. 3. The user scans the QR code and responds with the OTP value. # Challenge Layout The challenge can consist of: * serial: "PISM12345678", * transaction_id: "12345678901234567890", * message: "Please enter otp from your SMS", * client_mode: [interactive, poll, u2f, webauthn] * image: (as already prepared in [TiQR ](https://github.com/privacyidea/privacyidea/blob/9501114c95277cc174809dc8180aa5128ec81165/privacyidea/lib/tokens/tiqrtoken.py#L443) This would be a base64 encoded data img url. ## Polling TODO: Do we need information, where to poll? ## Cryptographic Challenges TODO: Where would the cryptographic challenges be sent? Can this be generic or would it always be token type specific? ## Client mode The client modes are described here https://privacyidea.readthedocs.io/en/latest/tokens/authentication_modes.html and currently: interactive, u2f, webauth, poll. Client modes are defined here: https://github.com/privacyidea/privacyidea/blob/db71956c5670a587690923d53fc059934b25c04b/privacyidea/lib/tokenclass.py#L137 # Conditions and Scenarios What would be the conditions *when* this new token would actually be enrolled? This somehow also links very closely to #2956. * A user might have no token at all (authenticating via passthru) and is supposed to enroll his first token * A user has a registrationcode and will enroll his first token * The token of the user expires and the user is supposed to enroll a new token. * The user only has a "weak" token of a certain kind and is supposed to enroll a "stronger" token. smartphone app -> certificate (#1511) * The user has an HOTP token with weak data and is supposed to upgrade to a stronger one (sha1 -> sha256) # Alternatives We could also enroll a token with a pre-event handler - we can already do this with SMS or Email tokens. In case of HOTP or TOTP the QR code would need to be displayed. However, we would still end up in a challenge response, so this approach seems more sensible. # Todos * [ ] implement policy * [ ] implement decorator * [ ] tests * [ ] docs **Additional Notes** This can be related to #1511

mat1010 · September 17, 2022, 8:23pm

Thank you for the explanation. It just felt convenient to have Keycloak do the enrollment since the user would not have to be aware of another service to initially enroll the token beforehand. But I get your point. Since we will have to tell them anyway where and how they can manage their 2nd factor, this is not that much of a benefit.

In the meantime, while checking alternate ways regarding the enrollment, I added the policies that allow a user to initially enroll a token in self service and force them to do further logins on PI with their token. This also helped me to gain a deeper understanding how the policies in PI work