Positioning of client mappers

[Captain-P-Goldfish]

Description

we just had some troubles finding the client mappers within the new keycloak admin console. We managed to find them but its not really obvious. May it be possible to place the mappers back in the outliner of the client next to the client scopes item?

Discussion

No response

Motivation

No response

Details

No response

[jbman]

It would be really good to have tab "Mappers" and there all mappers listed which are applied, including their source client scope where they are managed. This would give a nice overview of all the mappers which are applied for the client.

The tab would look like this, but as a client tab

The "...-dedicated" scope would also occur here under "Managed at client scope". Configured Mappers could not be added or removed here but viewed and maybe modified. To add a mapper the user would need to navigate to the client scope at the entry in the "managed at client scope" column.

[jonkoops]

@xianli123 could you take a look at this since this is a UXD issue?

[xianli123]

Thanks @jonkoops @jbman @Captain-P-Goldfish , I took a look at this issue. I remember this design is a compromise. In the future, the Scopes and Mappers may be removed from clients. We could involve @stianst to discuss it. What do you think? @stianst

[Captain-P-Goldfish]

what reason could there be to remove the scopes and mappers from the clients? This is actually a pretty powerful feature and removing it would be rather problematic for some of our usecases.

[xianli123]

Hi @Captain-P-Goldfish We plan to remove mappers and scope (inside client), and only allow assigning client scopes to a client. As for more details, I will convey your concerns to the developer team and get back to you as soon as possible.

[Captain-P-Goldfish]

thx. Would be great if the mappers would be kept. We are using them for two purposes:

1. to add hardcoded details into the access-token to clients that authenticate with client_credentials grant. These hardcoded details are necessary for some additional operations within the authenticating application.
2. To map additional audiences into the access-token

[jbman]

Hi @xianli123 and @Captain-P-Goldfish,

I think it would be ok to remove dedicated client mapper and role scope configuration, so that a mappers and roles scope are always configured as an entity which can be used at multiple clients.

However the view for one client should still support to check the complete configuration of a client by keeping the "Mapper" and "Scope" tabs at the client. The mapper tab should show an aggregated view of all mappers managed at client scope entities of the client. This is what I suggest in my comment above. This view allows an admin to check which data could end up in the tokens for this client. It also allows for navigating to the client scope to add or remove a mapper there.

btw.: I suggest to name the tab "Scope" either "Role Scope" or "Client Role Scope" to make it more distinguishable from the client scope entity.

[Captain-P-Goldfish]

I think it would be ok to remove dedicated client mapper and role scope configuration, so that a mappers and roles scope are always configured as an entity which can be used at multiple clients.

what about data that is not supposed to be added to multiple clients? Using client scopes is possible but it would harm the clarity of the configuration if different scopes are created for different clients. In my opinion it would be better to keep the possibility to add explicit meta-datasets into the access tokens of specific clients that are only meant for this client only.

And what about audience-mappers? What is gonna replace them?

[jbman]

That's true, a client scope could be named myClient-client-scope but it doesn't prevent that the scope is used by other clients. But isn't a naming convention enough to signalize that the scope isn't intended to be shared? Is anything special about the audience mapper?

I think it's good to have the client-scope configuration sharable by default, as you want to be able to hand out a second client which gets the same token claims as the first one (e.g. for secret rotation, or for testing a new client scope without modification of the existing client). But this isn't my main point. I'm also totally fine with keeping the dedicated client scope.

My main point is full visibility of all configured mappers for the admin. Admin shouldn't need to go to each client scope one-by-one to compose the list of mappers which produce token claims.

[xianli123]

@Captain-P-Goldfish @jbman Thanks for your ideas and suggestions. I have conveyed your comments to the developer. If you have any other comments, please feel free to leave them here.

[stianst]

@mposolda FIY

[stianst]

We are planning on deprecating/removing the ability to add mappers and scope directly to a client, and rather make it only possible to add these via a client scope. It just doesn't make much sense to have two separate implementations for adding mappers and scope to clients.

At the UI level how to represent it is a bit unclear. I could see that we could still want some form of a "dedicated" or single client client scope of sorts that stands out more than the rest. I can also see what @jbman is suggesting with an easy way to see the "effective" mappers and scope for a given client easier.