Hey @hrenard, I would suggest in a first step that we require to add and use one separate KC user teamadmin or TeamAdminBot with admin role in RC. If that user shows up and stays in each team, it should be fairly self-explaining.
FYI, Authentik SSO just released SCIM support
1 Like
What is the best place to manage group memberships?
Keycloaks resource sharing seems not intuitive for end users Authorization Services Guide
Better usability would give one of the clients users already know and use:
- RocketChat teams
- Matrix groups
- nextcloud circles - very easy and intuitive to use - API can list the circles I am a member of circles/Circles.php at master · nextcloud/circles · GitHub
However, that way the SCIM clients also need to become SCIM service providers.
Or should we have an extra group management service which is just talking to keycloak?
This is a complex topic, and I have intuition that an extra group management service is necessary.
I think this is outside my expertise, but I can try something…
The main tools we use are Matrix, Discourse and Nextcloud.
In Matrix, you have spaces, rooms, and roles.
In Discourse, you have groups, and admin, moderator and trust level.
In Nextcloud, you have groups.
Maybe the first question is who is “managing” groups?
Is it an end user? Is it the admin of the instance? Is it a “group manager”? Is it the manager of the “group”?
Then, maybe the second question is what is the intent of this persona? Is it to create a Project, is it to create a working group, is a project different than a working group? Is it something else?
In this group management service, do I just manage groups, or also resources?
Something we have in mind and could be nice, is to have some kind of “project template”.
A project template could have the following resources:
- a matrix space
- a matrix room in this space
- a Nextcloud user with the name of the group
- this Nc user would own and create:
- a deck and share it with the group
- a cal and share it with the group
- a folder and share it with the group
As an admin, you could create a “project” or “Working Group”, edit this template to fit your needs.
Then you could put people in this group and also make them “group admin”.
And from the tools, if you want to manipulate these resources, you’d brought back to this tool.
I’m no UX expert, and I think it is first a UX problem rather than a technical problem. I think there is a bit of work to be done before starting to code this “group management service”.
Our scenario is that end users should be able to create their teams and self manage memberships. Our nextcloud users really love Circles to define and manage their teams in a DIY manner. Until NC 22 Circles was an extra app, now it is integrated in the contacts menu and most NC apps now understand to share resources with circles.
Would NC Circles be good enough as a UI for a SCIM provider? Circles have the roles owner, moderator and member, which could be mapped e.g. to matrix.
NC Circles can not define resources outside sharing of nextcloud files or a calendar. However, resources are not so relevant when it comes to the number of chat groups. nextcloud resources (storage) is assigned to a user (ideally an extra team-owner user).
Sure, an extra group management service would allow more options, e.g. which service is included or a gateway to billing. Mapping a team to nextcloud with an extra NC user would require to provide that extra user, which adds some complexity compared to circles. An extra group management service would require nextcloud users to go there and we would need to recommend them not to use circles (I think they can’t be turned off anymore, since it was integrated in NC22 core).
It’s not just about Circle being a SCIM service provider thought.
The complexity quickly arise when thinking the topology : centralized or meshed, which relation between applications: push (sync) or pull (async unless scim native), and both way or not.
I think meshing is too complex and dangerous. We could theoretically have each application be a SCIM service provider, and a client and a centralized “hub”, but it multiplies the complexity, so the dev we’ll be harder to scale.
From a UX standpoint, I’m not sure that a one-to-one relation between resources of different applications will fit “naturally” and be easy to understand. I believe that a meta concept like a workspace or a project with composable resources of different applications is easier to understand. But a specialized UI would be required and for a polish result we’ll also need some way to identify and navigate back and forth (or even traverse) the links between app resources and this meta concept.
If we build a centrals group management dashboard with a top down ruling strategy, then we should warn a user, when s:he tries to create a matrix space inside matrix or a circle inside nextcloud, to better go to that central service and do it there. This would likely mean patching matrix clients or nextcloud core, which we likely do not want to do.
Agree that complexity rises when having more than one SCIM service provider. If we would let the workspace creation just be done by ONE already existing service (and let Keycloak just be a SCIM service provider for user accounts), then I would opt for matrix, as any local or federated user could be added. For nextcloud, there is a pending MR to allow adding federated users to circles. However, federated users would not be known to the local Keycloak.
It looks like we would need a brain-storming session to discuss the pros and cons of each approach.
Yes, a brainstorming session is good idea. And maybe, before jumping into solution engineering, we’ll refine the user stories which might require additional feedback from our users.