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
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 ?
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 :
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 :
(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
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:
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.