search

TNG / keycloak-mock

A Java library to test REST endpoints secured by Keycloak via OpenID connect.
Apache License 2.0
122 stars 27 forks source link

Added possibility to map the preferred_username property to additional claims #139

Closed singer-d closed 1 year ago

singer-d commented 1 year ago

Those can be configured via ServerConfig, or cli option for the standalone application, respectively.

hankem commented 1 year ago

Context: We use the keycloak_openid_user_property_protocol_mapper to map built in properties defined on the Keycloak user interface to a claim in a token. This PR supports mapping the preferred_username.

ostrya commented 1 year ago

Let my try to understand your purpose with this: You want to run the standalone version of the mock, and you need the generated tokens to contain one or more claims whose names you want to freely configure and whose value should be the username of the user as entered in the login screen. Is that it?

If so, I feel this is one special case of a more generic need to configure the generated claims when using the login screen. Also, I think it introduces some inconsistency to the programmatic use case (i.e. why am I able to remap the preferred username, but not the name, email or subject?).

I believe it would be cleaner to extend the login screen. Either with just a free text field where a JSON with additional claims can be added or with some more fancy UI (e.g. with input fields for all "standard" claims and/or some kind of auto-completion editor). What do you think?

singer-d commented 1 year ago

Yes, that is exactly, what we want. The idea was to leave the gui as simple as it is and work with the information from the two fields that are already there. Since there only user and roles are provided in my opinion it makes sense, to only provide this mapping for the user since this is the only input we have.

hankem commented 1 year ago

this is one special case of a more generic need to configure the generated claims when using the login screen.

Agreed! I just realized that (for another project) we'd need the email claim in the tokens from the standalone keycloak-mock.

ostrya commented 1 year ago

Agreed! I just realized that (for another project) we'd need the email claim in the tokens from the standalone keycloak-mock.

Hm, that sounds like #121 .

ostrya commented 1 year ago

As discussed offline, it should be easy to use standard claims in your use case. Therefore I will close this pull request as I would like to avoid the extra complexity it would add to the library.