I’m definitely no OIDC/Oauth2 expert, but have you considered logging people out when their groups have changed? If I understand your post correctly, that should trigger a group & attributes sync once the user tries to use the app again, and needs to log in.
I believe oauth2 supports a /logout endpoint, but we have not used it yet. I also believe not every application implements it. And then of course you still haven’t solved the garbage collection problem.
And do you think the problem might be easier/less work to solve if you only support OIDC, or wouldn’t it matter? We’re using the sociallogin plugin for Nextcloud, which works fine for us so far.
Logging out is still not perfect. As you said, we still have GC issue. Plus, actually user creation. As long as the user didn’t log in the tool, the user is not created, hence not visible. Say you want to share a file with this newly created user, it doesn’t work.
Same goes for groups creation/deletion.
OIDC like SAML are “frontend” login solution, Nextcloud doesn’t discuss directly with Keycloak, they do discuss though the user being redirected between webpages.
Basically, we need a backend solution to sync users and groups. Historically, this has been done with ldap, but it is not perfect, and I don’t understand it So we are better off developing a new one
(Half joking here, I still think we have better arguments than NIH classic one )
Great approach to plan developing a service that is syncing users and group memberships from keycloak to its clients. Pre-population of users currently works with nextcloud being connected in addition to an LDAP user store. Pre-population is something administrators (especially if they are used to Microsoft tools) expect: you should be able to share a folder or a chat group to a user, even if s/he has not yet signed up with the specific service.
Please share any repo or where we can help to specify details.
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).
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?
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 ?
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
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.
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.
So we are better off developing a new one 