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:
- Who approved that role assignment?
- Was there proper four‑eyes control?
- Can we revoke access before it goes live?
- How do we protect around root access?
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:
- “draft / pending / approved” states for user, role, realm and client changes
- a quorum‑based approval engine (default 70 % of current realm‑admins)
- simple admin UI + REST endpoints for reviewing and approving changes
- zero impact on existing realms when the feature flag is off
Please see Proposed Epic here
Walkthrough / demo
Why consider upstreaming?
- Security: removes “god‑mode” risk from a single admin.
- Compliance: requirements like: “internal controls” (SOX), “oversight” (PCI DSS), “access control provisioning processes” (ISO 27001), “policies for access authorization” (HIPAA), and “separation of duties” (NIST SP 800-53).
- Developer experience: teams keep using the same Keycloak APIs instead of juggling a second product.
- Incremental rollout: enable per realm, test in non‑prod first, then expand.
High level for discussion
| Theme | Quick summary (why it matters) |
|---|---|
| Admin UX | Minimal UI to view drafts, grant / deny, and see an audit trail. Fancy dashboards can wait. |
| Quorum tuning | 70 % feels sensible for a PoC, but should it be configurable per realm? |
| Operator hooks | The Keycloak Operator could simply set --features=iga, so clusters opt‑in explicitly. |
| Community fit | Does an optional “IGA profile” belong in upstream, or should it remain a maintained fork/extension? |
What this is not (yet)
- Full segregation‑of‑duties policy modelling
- SCIM / HR feed provisioning
- Ticket‑system integrations
- Fancy reporting dashboards
Those could evolve later if there’s appetite.
Next steps
- Feedback welcome! Does this resonate? Concerns around scope, security, performance?
- Here’s the draft Epic posted in Issues for consideration
Looking forward to your thoughts and the maintainers’ guidance on whether this belongs upstream or stays a fork.
Thanks!
Mike & Tide.org team