However, it does not seem to be present when I use the microsoft IDP. It works as expected when the IDP is another KeyCloak instance. The FEDERATED_ACCESS_TOKEN is present though, and contains the expected token.
My question is therefore: Am I making incorrect assumptions as to when the ID token should be present, or am I missing something in the setup, or have I found a bug? I have ensured that the scopes I ask with include openid. I also manually ensured that obtaining tokens from Entra ID gives both an access token and an ID token with the expected content.
Maybe you would ask why I need it - fair question. We’re in the sad situation that the user roles has to come from the federated IDP. Therefore I will need a way to take the roles claim (in the case of Entra ID) and map it to KeyCloak roles. I cannot find a mapper which can do this, thus the custom SPI implementation where I need to access the claims from the ID token. If anyone has a great idea to avoid a custom SPI, I would love to hear it.
Can also mention that my custom SPI class is implemented as below
It’s all there, I’m mapping something (here, the claim groups to a KC role.
There’s also the “Advancec Claim to Role” mapper, with some more mapping options.
Why these built-in mappers don’t work for you?
The roles claim contain an array like “[Developer, Tester]”. Thus, I cannot just use the claim to role mapper. Also, that mapper only exists for OIDC IDP’s (same for the advanced one). The microsoft IDP do not have these. Would I need to convert my IDP to a generic OIDC one instead?
I think that the advanced mapper would do the trick, but I would have to do one per role.
I foresee another problem in the future though, where I need to interpret the “groups” claim and massage this into a claim which can be used for ABAC purposes. Maybe if I use OIDC instead, the ID token will appear again actually. I will try this and get back with the result.
The Microsoft Social Provider should IMHO not be used to connect an enterprise EntraID to Keycloak, only for public MS accounts, as social provider.
If you want to connect to an enterprise EntraID, it’s best to use the generic OIDC provider, where you have more flexibility and options. This way, you can also use the available mappers. The “Claim to role” and also the advance mappers support to use a value from an array. My example above is exactly this. In the token, there’s an array of UUIDs, and if one value is equal to the configured one, it maps the user to the selected role.
