Repository navigation
Replies: 6 comments 5 replies
|
Hi @ondamike, Your demo is very sleek and I can certainly see this belonging as part of Keycloak directly rather than an extension. It is a fairly big topic though, so we would need to carefully define an MVP and make sure the implementation is flexible enough to support customization as well as be possible to extend without too much effort. I haven't dug into your codebase or looked in detail what capabilities you have already implemented, but would love to discuss this future, especially if you have capacity and interest in contributing to Keycloak. Happy to arrange a call at some point to discuss future if you are interested? Some quick thoughts that came up to me when viewing your demo:
|
|
Thanks @stianst. Great feedback! We'd love to contribute to Keycloak. I'll ping you offline to arrange a call. |
|
@vmuzikar @pedroigor please take a look at this and join the discussion; @vmuzikar if you can also dig up your old prototype around this topic that would be great |
|
One additional thought is that we may want to be careful as terming this IGA (lightweight or not) due to this really only being a small subset of capabilities provided by an IGA solution. We may want to name the feature something like approvals perhaps, rather than the much broader term IGA. |
|
Makes sense! Happy to workshop that. |
|
Related issue #41993. This adds another interesting angle, maybe you want to just be notified rather than review updates. |
|
I think it's a great point. Perhaps the entire system should be configured to support "notify" and "approve" mode. Later, we could implement flexible policies what gets approved automatically (and will end up with a notification) and what needs Keycloak Admin explicit action. |
|
Hi @ondamike. IGA is a key area within IAM, and something Keycloak is lacking in order to define/enforce policies on resources and streamline their operations. What you are doing is great, and the capabilities you are proposing provide a very nice baseline to cover some of the IGA key aspects, such as access request and provisioning, and separation of duties. Please, count me in for further discussions/meetings on the matter. IGA is an area that we are starting to explore, and I'm really glad that others are interested in collaborating on how we can improve the project capabilities in terms of governance and administration. As you know, today we have a set of capabilities that are somewhat related to key aspects of IGA. To name a few:
However, even though these provide some building blocks for IGA, we don't have an upper layer from where we can set policies to govern security assets, to enforce such policies, as well as to streamline and automate operational tasks. In addition to that, we also have ongoing initiatives like the Resource Lifecycle Management [1] [2] feature that seeks to address some key aspects around IGA, mainly around identity/resource lifecycle management. This feature should help a lot with what @slaskawi linked here #41993. Another key feature that we have planned is to finally support SCIM, which should help to enable more integrations and mainly help with identity lifecycle management. From an administrator PoV, I imagine in Keycloak a specific section in the Admin UI an specific that maps to "Governance and Administration". In this section, I can also imagine some key capabilities available such as the one you are proposing and those I have mentioned. I'm preparing a document to help us drive discussions around IGA and how any existing and new capabilities play out in this arena. Once I've something more concrete, I would like to share it with you (probably in a call) to see how we can work together on this. I think the idea is to convert it to a set of GH issues in the future and resume the original epic [3] you have started with a more concrete plan. |
|
@ondamike I was looking at the implementation. I was wondering if, instead of wrappers and custom user/group/role providers, the mechanism could be based on replaying representations? In essence, that is basically what the Admin API does when managing resources (mainly JSON payloads), where the rep is parsed to a model and changes are persisted. By leveraging the same logic in endpoints, we could perhaps replay the representations/payloads sent via Admin API? Also, do the approvals follow an order and respect the order in which their corresponding approval request was created? I'm wondering how to deal with conflict resolution when two requests might overlap with each other. Not sure that would work though for mime types other than JSON, mainly when processing files. |
|
Hi @stianst @pedroigor, Coming back to this one with a concrete use case, I think it is the second use case of the approvals design note: https://github.com/keycloak/keycloak-community/blob/main/design/approvals-system.md#use-case-2 In my company, we run B2B customer portals on Keycloak with Organizations. Someone from a customer company signs up and before they get access two things must happen: check that the person is eligible against company data that lives outside Keycloak, and get an approver's agreement on the customer side or ours (or both). Today this can be approximated: a Workflow on user-created with disable-user, or a custom required action, and an external service that re-enables the account. What is missing is the semantics: a pending state distinct from a disabled account, an approve/reject call that records who decided and why and an event for each request and decision, since workflow execution history is not persisted. Every team ends up rebuilding those three pieces. What I have in mind is a narrow first step where Keycloak owns the mechanism and the decision stays outside:
Who is eligible and who approves stays in the external service which is the "delegated to an external entity" option of the design note. I read the earlier attempts: the 2021 prototype closed "for now" in favor of #8536, and this thread. The design note generalizes to approving any configuration change, and the prototype's own scope was already limited to user creation and self-registration. What I have in mind is smaller on the Keycloak side still: no interception of changes, only a pending state and an event. Back in 2021 @velias noted that registration is probably the easy part ("only some flag in DB that user is under approval (so can't login yet)"), so it looks like a reasonable first milestone, leaving approval of changes to existing users and roles for later. A few questions before going further:
If it fits, I'd be interested in contributing to it. |
|
@ondamike I should have asked you first: is the Tide fork still meant to go upstream? What I described is a small subset of it, and the decision sits outside Keycloak rather than in an admin quorum. If your work could cover it, I'd rather align with it than start a parallel track. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
(and thanks @mabartos for your input!)
With many of us leaning on Keycloak as the central point for Identity & Access Management, we still end up plugging in a separate IGA tool - or hacking our own - whenever an auditor/security teams asks:
To see how far we could get without leaving the Keycloak ecosystem, we played with this proof‑of‑concept fork https://github.com/tide-foundation/keycloak-IGA with surprising success!
It demonstrates that with minor changes, we can add:
Please see Proposed Epic here
Walkthrough / demo
Why consider upstreaming?
High level for discussion
--features=iga, so clusters opt‑in explicitly.What this is not (yet)
Those could evolve later if there's appetite.
Next steps
Looking forward to your thoughts and the maintainers' guidance on whether this belongs upstream or stays a fork.
Thanks!
Mike & Tide.org team
All reactions