groups on users and members on groups doesn't appear to be exposed via the 2 endpoints. about scim-for-keycloak HOT 9 CLOSED

Do you have a user federation configured with LDAP or Kerberos?
In that case you need to configure it. By default the members are extracted from the keycloak database. Doing this is much more performant. But if you are using ldap you need to set it explicitly. This case is documented here: https://scim-for-keycloak.de/faq

from scim-for-keycloak.

I do have a user federation configured with LDAP. Setting the flag "Is User Federation active" totally solved the problem. It does have a terrible impact on the performance when getting all the groups our users. we will have to see in our use cases if that's an issue but as it stands I'm using the endpoints to implement my own SCIM client until we can see if yours is an option.

from scim-for-keycloak.

As indicated that property is not workable on large numbers of users. What instead I want is to not have the group brought back on user unless I ask for it specifically.

Reading https://bookstack.soffid.com/books/scim/page/scim-operations#bkmrk-read it says that you can do attributes={attributes} to get specific attributes of the resource. If I ask for group for user or member for group then if you then did what you do now for the "Is User Federation active" that would work as well..

In addition I guess it wouldn't be bad if you returned the federated info only if you asked for a specific resource i.e /Users/someuserId. Could you also make that an option?

In keycloak java rest api no groups come back on the user if you ask for a list of users.
If you want to get user groups you do this:

UserResource userResource = realmResource.users().get(userId);
List roleMappingResource = userResource.groups();

Which I assume just gets the users groups via the federation. I guess I need something like that from the SCIM.

from scim-for-keycloak.

this is actually not a problem.
I actually haven't implemented it yet. But SCIM defines the returnedattribute. If set to REQUEST the value will only be returned if explicitly requested. I actually just forgot to to add this feature but it is not much work and can be added without problems.
I will keep this ticket open until I have added the handling of the returned-attribute in the plugin. The SCIM SDK though is already handling it by excluding these attributes even if they are added into the response. So at the moment it would help to not return the groups but they would still be parsed from the remove provider.

from scim-for-keycloak.

I'm not sure if I understand what you said here. I figure my steps to get good performance are as follows:

1. if "Is User Federation active" is on then currently groups are returned on users and members are returned on groups. This is not ideal for performance reasons. Hence I assume I have to turn that off. right?
2. So after turning it off groups won't be returned on users and members wont be returned on groups right?
3. Then you're going to implement something that wasn't implemented to allow me so specify attributes=groups or members?
4. this way you'll know to go after user federated entries?

I'm not sure what you mean by "SCIM defines the returned attribute" OR "If set to REQUEST". Can you point me to SCIM documentation talking about this if I'm missing something? Thx

from scim-for-keycloak.

I have actually made a little mistake in my implementation here that is easy to fix though:

1. groups are always added to the user-resource no matter what we are configuring: This is a mistake: The groups shall be returned only if one of the following conditions is met:
   • the returned value of the groups attribute is always
   • the returned value of the groups attribute is default and the attributes/excludedAttributes parameters are empty or the attributes-parameter contains the groups-attribute explicitly
   • the groups-attribute is even configured. It is possible to remove it and thus the groups should not be read at all. Instead they are read, added to the resource and then excluded again. This is of course a performance horror.

Fixing this issue is not much work and luckily also not very complicated.

2. I meant this
   

unfortunately there is no optimal way to get the groups of a federated resource because retrieving the groups depends on the underyling implementation within keycloak. Therefore the best way is to synchronize users, groups (maybe also roles) to the keycloak-database. This will prevent the additional calls for all the users to the external system and thus enhance performance.

from scim-for-keycloak.

I'm pretty sure that fixing this will address my performance issue.

In last paragraph, are you proposing to circumvent the calls to external system by creating your own table structure in keycloak database to hold them?

from scim-for-keycloak.

fixed and available in the next release

from scim-for-keycloak.

It all worked perfectly. The liquibase issues I worked around that might be a security issue are now the only remaining issues.

from scim-for-keycloak.