1:54 p.m.
@Thomas no one is going to read that - you wrote to much ;)
Summary:
Fetching a user from the admin endpoints doesn't include roles mappings.
Thomas wants it to and proposes to use "?include=roles", well actually I
proposed it, so it gets a +1 from me.
On 17 October 2016 at 20:35, Thomas Darimont <thomas.darimont(a)googlemail.com
wrote:
Hello group,
for KEYCLOAK-3410 "Ease creating user with initial roles via REST I" filed
the following
PR https://github.com/keycloak/keycloak/pull/3120 in which the need arose
to selectively include details within a Representation returned by a REST
resource.
In this concrete case I made it easier to create users with an initial set
of Realm-/ClientRoles
via the Keycloak admin client which I learned in some projects is a common
requirement.
Previously roles passed to the UserRepresentation were ignored when
creating a user via the Keycloak admin client and a user had to create the
roles in a second step after the creation of the user which required
multiple HTTP requests.
With the changes within the mentioned PR clients can create a user with a
set of predefined roles
with a single HTTP request like the following:
UserRepresentation user = new UserRepresentation();
user.setUsername("user1");
user.setRealmRoles(singletonList(REALM_ROLE_NAME));
user.setClientRoles(singletonMap(APP_CLIENT_ID,
singletonList(CLIENT_ROLE_NAME)));
Response response = keycloak.realm(realmName).users().create(user);
For symmetry reasons I also changed the
org.keycloak.services.resources.admin.UsersResource#getUser(String)
method to return the configured Realm/ClientRoles with just one HTTP
request.
See:
https://github.com/keycloak/keycloak/pull/3120/commits/
2afec29a2cf97a4aac97e169a564ab88bdce5d19
One downside of this is that this could potentially lead to unexpected
performance problems since a user could have many roles assigned, also
currently the admin console issues some UsersResource#getUser(String)
requests which would (currently) ignore the returned rows.
Stian and I had some discussions on how this could be solved - among the
discussed options were:
1) just return the Realm/ClientRoles and document the potential performance
impact
2) introduce some sort of ?include=[String ... categories] parameter in the
Keycloak client API
which would allow a client to control what would be returned in the
(User)Representation
3) Introduce a new dedicated endpoint UsersResource#getUserDetails(String
userId) to return the full UserRepresentation with the roles.
4) Use Media-Types like application/vnd.keycloak-user+json and
application/vnd.keycloak-user-details+json to control the data of the
returned representation.
Since all of those mentioned options come with some pros and cons we'd like
to reach out to you folks to help us to find the best solution possible.
Since this problem also arises for other representations like clients /
groups, realms etc.
it would be beneficial for the sake of a consistent API to find a general
solution how to proceed here.
Looking forward to your feedback.
Cheers,
Thomas
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev