OpenId and SAML Client's attributes

[slavko-vega]

Supported are attributes for OpenId and SAML clients

[mrparkers]

I guess I'm not completely understanding the problem we're trying to solve here. I understand that your goal is to add user-defined attributes to API calls for resources such as openid and saml clients, but is there any reason that we need to use reflection or define reserved keys?

My thinking is that we could just allow users to use this attributes map to define any properties they want on the model that is sent to the Keycloak API, and it's up to them to make sure that they aren't overwriting other attributes or sending attributes that the Keycloak API will reject. As long as we know what field we're trying to add, we know what field to look for in the response we get back so the state can be updated accordingly.

This appears to be what we're doing with the IdentityProviderMapperConfig, right? Can we take the same approach for openid and saml clients as well?

[slavko-vega]

Hey @mrparkers , you're totally right. I wasn't aware of that implementation in IdentityProviderMapperConfig. I'll use the same approach for OpenId/SAML client.

[slavko-vega]

Hi @mrparkers, client (OpenId and SAML) attributes are implemented as extra_config.

[civ0]

Hi all, are there any updates on this PR?

Setting custom attributes on clients would be very useful for me. Please let me know, if there is something I can do to help progressing this PR.

[Tokynet]

BUMP @slavko-vega and @mrparkers

[mrparkers]

Hi everyone, I think the functionality that's been introduced within this PR has already been implemented via several other PRs:

• extra config for openid clients: add extra_config for openid clients to handle custom attributes (#387) #579
• extra config for saml clients: feat: add extra_config and new required attributes for keycloak_saml_client resource #589
• extra config for identity provider mappers: chore: misc improvements for extra_config attribute #584

Let me know if you think that anything else is missing, but I think for now we can close this PR.