Repository navigation
Keycloak setup for ID Austria (with transient sub) #51873
|
(I asked this on the forum before seeing the wind down notice, hope you don't mind I copy and paste it here too) Hello, I have not yet figured out from the docs and various bits of information online if Keycloak will work out of the box with ID Austria as an external IdP. I have seen some discussions with people writing their own plugins for it but not sure if any of this has been integrated into Keycloak or if features have been added that would solve the problem so maybe some of you can help me. I am very new to Keycloak and have only been playing with it in a local docker container and do not yet have an ID Austria setup to really test with and I am just trying to figure out if it can do what we need. The main point that seems to be causing issue is the fact that ID Austria uses a transient sub claim in their id token which changes with every login. The static id used to identify the user is the “bPK” located at “urn:pvpgvat:oidc.bpk” in the id token. I have seen that you can configure mappers to map different claims to solve this but I still have not seen any definitive proof that this will solve the problem. Here there is mention of using the Attribute Mapper but also no proof that it worked (the opposite actually): sd-f/keycloak-custom-attribute-idp-linking#3 and also more talk around writing custom plugins for it: So that is the first point to clear up. The second is the fact that there is no user info endpoint in ID Austria. I found that when configuring an IdP you can check the “Disable user info” option which looks to me to disable the use of the user info endpoint, I am guessing in favor of just using the token (from the info hover): “Disable usage of User Info service to obtain additional user information? Default is to use this OIDC service.” I think the rest of the configuration is simple and clear but if I can’t solve the above then I guess it is not an out of the box solution. Thanks for any help! |
Replies: 1 comment 4 replies
|
Hi @ThriceGood, Assuming, ID Austria is a more or less regular OIDC IdP... (I don't know ID Austria details) I've not tested it, but with a transient For the |
|
Thanks for your reply. The bPK is located in an attribute named: The default template for this mapper is: Its not clear to me how to define the template here and I am not sure what ALIAS and CLAIM are supposed to be. I am taking it that "username" is what Keycloak uses as the lookup for existing users and is usually the "sub". Therefore remapping username to be filled by bPK will tell Keycloak to use the bPK instead of sub. Am I correct? Also, here is what my attribute importer looks like, could you imagine this working for the same functionality?: |
To get the bPK as the userId (will yield as If your attribute
|
|
Sorry I forgot to link to info regarding ID Austria. It is definitely OIDC despite the naming: https://www.id-austria.gv.at/de/developer/anbinden/anbindung-mit-openid-connect My Username Template Importer will look like: According to the info text I can extract the particular claim from the id/access token with the syntax I defined:
I am hoping I can test this, and hoping it works 🙂 |
|
@dasniko FYI, it worked using the mapper as described. The user is recognized as existing in the system and they are seamlessly logged in with no further prompts. Thanks for your help! |
To get the bPK as the userId (will yield as
subin the KC issued tokens), you must use theUsername Template Importer, not a regularAttribute Importer. The mapper might look like this:(I haven't tested this specific usecase, just deriving from other cases)
If your attribute
urn:pvpgvat:oidc.bpkalso has a friendly name, e.g.bPK, the template also could beATTRIBUTE.bPKFrom the helptext of the template field: