[SSO - Keycloak] sync users and groups membership in the app

Yes, we have a ceph cluster dying and moving to a minio cluster, this was a bit unexpected :slight_smile:

But yes, still planning to do it, maybe starting in december, but more probably beginning of Jan :slight_smile:

Should we plan a kick-off? How’s about 19 or 20 Jan 22 afternoon?

It’s nice to see people interested ! I’ll be working on this during the next couple of months.
We just discovered the SCIM standards (http://www.simplecloud.info/) and we plan to build upon it.
A kick-of is a great idea? 20 Jan is good for us. 14h30 CET on https://meet.liiib.re/scim ?

1 Like

Thursday 14h30 is good for fairkom folks.

There is already a nice SCIM plugin for keycloak https://github.com/Captain-P-Goldfish/scim-for-keycloak

So we need to test it and focus on the clients.

Nice !
And this one https://github.com/suvera/keycloak-scim2-storage :wink:
We’ll need app adapters which are both SCIM Service Provider (for push strategy) and SCIM Client (for pull/initial reconciliation).

We tried suvera/keycloak-scim2-storage. It only does user creation, and It’s based on a dumb loop. So we don’t think we should use this one.
As mentioned in this issue Keycloak doesn’t have internal middleware APIs to reject response in case of SCIM error.
For now, we see only 2 options for KC Client :

  1. Dev a KC proxy, wich would allow us to achieve strong consistency and realtime propagation, but is more tricky to dev because it could lead to bad beaviors or create an attack surface.
  2. Dev a KC extension or a sidecar program wich would loop or react on KC events, it would need a way of storing (posgres, k8s cm) metatadata (events start date for next loop). It’s less senstive but in case of error we just have to have a good logging system because nothing is actionable.

We lean toward option 2 : a Golang program that stores metadata in k8s config map or in a S3 bucket. If your Java dev wants to, he can build the same logic as a KC extension and maybe extend KC DB.
What do you think ?

Keycloak is moving from WildFly to Quarkus - the extensions probably won’t work anymore. We rather should aim at a sidecar maybe using REST. See their roadmap Keycloak - Search

Let’s discuss this at our next meeting on Friday Feb 4 2022 14:30 CET on https://meet.liiib.re/scim

Pad: Libre SCIM - v1.0 - HedgeDoc

Next status meeting Friday Feb 11 2022 14:30 CET on https://meet.liiib.re/scim

Here is the Keycloak Client POC I made : git.
I first build it in Kotlin to experiment with the language, and it was working. Then I tried to make it work with Keycloax.X (Quarkus), and I fiddled a lot with the dependencies which didn’t work (something with the rest client not being provided by the runtime). And I finally moved it to Java because Kotlin support in VSCodium isn’t great.
Anyway, there is now an error with JPA that I don’t quite understand. If someone has a little time to help me fix this and clean up the pom.xml, It would be much appriciated.

We got a nice demo from @hrenard to create and delete users in rocketchat with an SCIM provider in keycloak.

Next status meeting Fr 25 Feb 2022 11am on https://meet.liiib.re/scim

We added some rough issues in git to represent the work to be done. Feel free to create an account, comment or take on some of them.

Hey @rasos, I would like your opinion on a problem. I’m working on KC group to RC team support and there are some inconsistencies.
RC doesn’t allow the use of admin username so the default KC realm admin is excluded from SCIM logic. RC needs a user with the admin role, and he will probably be the same one who gives his RC API token to the SCIM app.
The same user will also be the owner of all teams created via SCIM. But KC doesn’t know who he is. And RC needs to keep him in the member list when adding or removing other users.
Here are the options I thought of, ordered by simplicity :

  • KC stays ignorant and the RC SCIM app adds the admin in the member list. (Best for the 1st implementation)
  • We add a role or an attribute on KC users which needs to auto join all groups and stays in it.
  • Upon group creation, a group admin user is created and join/stays in the group.

(Join and stays might be complicated)
Do you have specific requirements ?

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:

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.