We got sidetracked with other projects, but we’ll start it before december, that’s for sure 
And yes, prepopulation is one of the main pain point
1 Like
Hi @pierreozoux, this indeed seems to be a recurring problem. My first thought as I was reading your proposal was: why not use a synchronization mechanism like ActivityPub or XMPP or RabbitMQ that you mentioned? Group changes sound like a perfect example for such announcements, and the publish-subscribe pattern goes a long way solving it efficiently. If your client only changes once per month, then it’s a single synchronization step, no need to run a crontab at all, it optimizes for actual usage.
That said I completely agree with the phases: one for full synchronization and the next one for granular (on-demand) synchronization.
I’m not sure about the energy efficiency of running Keycloak vs. LDAP, but in the case of preferring Keycloak, then could this be implemented with an event broker? There are some Keycloak extensions already supporting some listeners (MQTT, RabbitMQ, even one for pubsub on the Gaggle cloud that could serve as a starter).
1 Like
Using an event broker sounds good.
According to the RC comparison table EE-vs-CE keycloak would need to publish in addition for oAuth:
- Assign Rocket.Chat roles based on OAuth roles
- Join channels automatically based on OAuth roles
And we need to manage leaving users.
Mapping groups from keycloak to nextcloud is already working well with the SAML member attribute. But letting go users from groups they left in the IDP seems to be triggered only at their next login, so they’d still get notifications etc, which is not ideal.
Mapping groups to RocketChat requires a mapping table when doing it with SAML. Same here, users who leave are not eliminated in the respective RC groups.
I would suggest to map all groups in an IDP to a Team in RC (feature introduced in RC 3.13) and fill / delete the members with a cron job or event based. You still can hide those teams you do not need in the left panel.
This month was proposed to start working on the generic sync tool. Any date for a kick-off?
2 Likes
Yes, we have a ceph cluster dying and moving to a minio cluster, this was a bit unexpected
But yes, still planning to do it, maybe starting in december, but more probably beginning of Jan
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 
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 :
- 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.
- 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
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:
- 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”.