Keycloak provider realm missing in token request

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 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 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 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.

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.

@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:

1 Like

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 :+1:

1 Like