Identity Provider or IDP solution is critical for public clouds and large enterprise clouds, especially when the user base is extensive and requires governance. In OpenStack‑based infrastructures, the way how IAM solution is architected to meet both public‑cloud scalability and enterprise‑grade governance is a decisive factor for business success. This blog outlines key requirements for such identity solutions, then examines a widely referenced component — Keycloak — discussing its inherent strengths and limitations. It further explores different integration models for incorporating Keycloak into public and enterprise cloud identity frameworks, and concludes by comparing their trade‑offs to show how Uniview optimizes identity architecture for maximum efficiency and reliability.
Key design principles
A well‑designed cloud identity architecture must follow several key principles:
- Decoupling from core infrastructure — the identity layer should operate independently so that authentication remains usable for other services such as billing, object storage etc even when underlying hypervisor or controller partially or entirely is disrupted.
- Maintainability using organic, widely adopted technologies — avoiding disparate or exotic stacks that complicates ecosystem and increase operational overhead is the key to bring down total ownership cost.
- Support for SSO and enterprise IDP integration — while keeping system organic, it should well enable seamless federation with corporate identity systems.
- Social network integration — essential for public cloud user onboarding. By supporting login through major social networks, a cloud platform can dramatically accelerate user acquisition — social identity lowers barriers, reduces signup friction, and allows the user base to grow at an exponential pace due to its convenience
- Public user onboarding and governed self‑registration — allowing individuals to register themselves while still enforcing policy and compliance.
- Enterprise self‑service — enabling organizations to manage their own users, teams, and access lifecycles without operator intervention. Enterprise self‑service is especially critical. Large organizations users often access multiple projects, clusters, and roles. Users join and leave teams frequently, and the administrative overhead of managing these lifecycle events can be substantial. When the OpenStack infrastructure adminstrators and organization tenant administrator are not same person or team, cross‑boundary trust becomes a major architectural concern. A strong identity solution shall support delegated administration, automated lifecycle management, and clear separation of responsibilities to avoid operational bottlenecks.
Keystone has long been the cornerstone of identity in the OpenStack ecosystem, but it is designed for technolgoy and far from business ready. Public cloud environments introduce additional requirements: scalable user onboarding, policy‑driven self‑registration, and the ability to support both individual users and large enterprise tenants.
Today, commonly in openstack powered infrastructure, IAM solution tool kits involve a wide range of component combination, including:
- Vanilla Keystone
- Keystone‑over‑Keystone
- Keycloak + Keystone via OIDC
- In‑house IDP + Keystone
- Active Directory + Keystone
- LDAP + Keystone
- Commercical IDP+ Keystone
- Google/Entra Id + SSO Broker+Keystone
Examine Keycloak, the Pros and Cons
Keycloak has been a component introduced into OpenStack solution recently addressing some identity challenges. One top benefit of introducing Keycloak is its readiess on many business feature, so it can compose many cloud features in no time, and technical no cost when it's open source that everyone can install. Those strong features that meet various business needs:
But we should be always aware the cost and complexity, and significant drawback it introduces to business by itself. Keycloak can become a heavy, complex subsystem at scale, and its operational issues grow exponentially with user volume. And beyond Keycloak’s own limitations, many parts of its design are simply not optimal for OpenStack’s identity model — leading to awkward integrations, brittle federation flows, and additional operational overhead. More details are elaborated below:
Summary — Keycloak Drawbacks That Matter
| Category | Real Impact |
|---|---|
| Operational complexity | Hard to deploy, harder to maintain |
| Scaling challenges | Heavy resource usage, complex clustering |
| Upgrade fragility | Breaking changes, long upgrade cycles |
| LDAP fragility | Frequent source of outages |
| Customization risk | SPIs break across versions |
| High TCO | “Free” but expensive to operate |
| Security surface | Needs constant patching |
| Multi-tenancy limits | Not ideal for public cloud |
| Backup/DR complexity | Hard to do safely |
| HA complexity | Requires careful architecture |
Integration With Keycloak Centralized
Given these challenges, the key architectural question becomes how to position Keycloak within an OpenStack environment so that you benefit from what it does well while avoiding the operational and architectural debt it introduces
The first is the Keycloak‑Centralized approach, where Keycloak operates as a full IAM system: it manages onboarding, stores the primary identity database, handles MFA, and provides OIDC/SAML federation for Keystone. In this model, most user lifecycle operations depend on Keycloak itself, and when multiple Keystone clusters exist, Keycloak must integrate with each one individually.
An straightforward layout of adopting Keycloak Centralized is like below:
This model has benefits that Keycloak user registration, MFA etc can be used for upfront user management, and saved engineering time. Many public facing features by Keycloak can expedite the time to market. Basic functions work, for example, users sign in at keycloak, and then will be directed to keystone for token, then to horizon or vendor proprietary cloud portal to access service.
But as explained earlier this introduce extreme overhead and not reliable by the nature of Keycloak itself. Clouds of OpenStack are seemmingly more complicated than Keycloak was designed for. For example, when Keycloak is wired to multiple Keystone, multiple OpenStack, user has no way to switch in between. Each time a user has to sign out and sign back with different options to access a second keystone. User password resetting, cross openstack tokens can't never co-exist, so they are never like one cloud at all, other than a shared Keycloak. One major pull back is the way of integration relies on OIDC or SAML module, and as well sementic user mapping at the target the keystone that generic Keystone doesn't support. To have such integration, an overhaul of existing keystone is required which is a big instability.
Integration With Keycloak As Broker and Proxy
The second model is the Keycloak Broker approach, where Keycloak acts primarily as a protocol broker for OIDC and SAML, sitting between Uniview IDP and external identity providers such as Google or Entra ID.
With understanding the constraint and for the sake of sustaintability, this is also the Optimized Layout at Uniview. Uniview was initially focused first model, but ultimately moved to a different design of broker model, that preserves the useful parts of Keycloak while eliminating the maintenance burden and fragility.
The way of such solution using Keycloak from central piece to supporting and proxy, has all the benefits of Keycloak while avoided operations issues:
| Keycloak Centered | Uniview IDP | |
|---|---|---|
| Keycloak necessity | Core Components | Optional |
| Persistent Data at Keycloak | Yes and Essential | No persistent data |
| Keycloak Maintenance | Extreme overhead introduced | Zero or no |
| Disparate tech in stack | Ecosystem becomes very compicated with exotic and diparate tech | Openstack generic, such as mysql, mariadb only |
| Switch between sites/regions | No switch, user have signout then sign in with options | Seamless as one cloud |
| Billing system sustainability | Not sustainable | Very sustainable |
| Scalability | Not scalable, ideal for small user base only | Scalable to national large |
| User Management | Many frictions and no sense of native to OpenStack | Same API, same process, single tech stack |
| Enterprise Oriented | No, basically hard to handle group etc | Leveraging all enterprise design of OpenStack keystone |
| Decoupled from underlying OpenStack | No, significant rely on OIDC/SAML of keystone for integration | Zero requirement on openstack keystone to integration, no OIDC, no SAML |
| Cascading failure | High possibilities | Zero requirement on openstack keystone to integration, no OIDC, no SAML |
Conclusion
To conclude, Uniview Identity solution has been proven the ultimate optimizing in providing seamless user experience, stability, easy integration, long term low maintenance overhead, and very scalable solution, in contrast with KeyCloak Centralized solution.
Authored by Jack Dang · At Toronto Apr 2026