Keycloak or WSO2 Identity Server: when each one fits
Keycloak fits teams that want an Apache-2.0 identity server with community releases and their own operating model, while WSO2 Identity Server fits teams that want B2B CIAM features out of the box and are prepared to buy a subscription for support. Both are Apache-2.0 Java servers, so the license type alone does not separate them. The decision turns on four questions: whether a paid support contract is a requirement, whether organization hierarchies and per-customer login options are needed on day one, which user stores and protocols are mandatory, and who will run the platform day to day.
Start with support. WSO2 offers an unsupported open source distribution on GitHub for do-it-yourself builds, while commercial deployments get updates, expert support and vulnerability monitoring through a subscription. Keycloak has no equivalent paid tier from the upstream project, so a team that needs a contract typically buys one from a third party such as Red Hat build of Keycloak. Confirm with each vendor what the subscription covers, who is paid for it, and whether it recurs annually, because these terms drive total cost more than the software does.
Then check the requirements list against the product. WS-Federation is supported by WSO2 Identity Server, and SAML, OpenID Connect, SCIM and FAPI are listed among its features; Keycloak covers OpenID Connect, OAuth 2.0 and SAML 2.0 but its supported list does not include WS-Federation, so confirm that gap with your relying parties before committing. For user stores, both can federate LDAP or Active Directory, but WSO2 also names custom user store implementations. Finally, if your team is small, weigh whether it can operate a Java identity platform with a supported production database, clustering and upgrades, or whether a subscription changes that workload.
Which platform fits which scenario
This table maps common scenarios to the platform that usually fits better, with the condition that makes the choice hold. Read each row against your own identity sources, customer model and support requirements, since both platforms can be configured for several rows with additional work. The main takeaway is that Keycloak is the more common default for OIDC and SAML single sign-on, while WSO2 Identity Server is worth a closer look when a subscription, WS-Federation or a Java-based WSO2 estate is already part of the plan.
| Scenario | Better fit | Why and where the other could also work |
|---|---|---|
| Internal workforce SSO for SaaS apps | Keycloak | Holds when the apps speak OIDC or SAML and staff sit in Active Directory or LDAP, which Keycloak federates. WSO2 can cover the same protocols, so choose it if the team already runs WSO2 or wants a commercial subscription. |
| B2B SaaS where customers manage their own users and login options | Depends on the tenancy model | WSO2 lists per-customer login options, delegated administration and organization hierarchies, which fit this case. Keycloak can model it with realms or its Organizations feature. Confirm which B2B features your target release supports before deciding. |
| WS-Federation or legacy Microsoft-style estate | WSO2 Identity Server | WSO2 lists WS-Federation among its supported protocols, and Keycloak's documented protocols are OpenID Connect, OAuth 2.0 and SAML 2.0. Confirm the exact relying-party requirements in a proof of concept, because WS-Federation support may be a deciding factor. |
| Team with no paid support budget | Keycloak | Keycloak is Apache-2.0 with community releases and no paid edition is required to run it. WSO2's open source distribution is unsupported for do-it-yourself builds, so support must come from your own team or a retained partner. |
| Team that wants a subscription with expert support and vulnerability monitoring | WSO2 Identity Server | WSO2's on-prem subscription includes expert support, continuous product updates and vulnerability monitoring. Keycloak has a supported distribution from Red Hat, which is a different vendor and product, so compare its terms directly before choosing. |
| Kubernetes-first platform teams | Keycloak | The Keycloak Operator is installed through Operator Lifecycle Manager or kubectl and manages Keycloak and client custom resources. WSO2 can also run on Kubernetes, so the decision depends on how much Operator-based lifecycle tooling your team wants to adopt. |
| Teams that need a Java server with a commercial lifecycle path | WSO2 Identity Server | WSO2 is Apache-2.0 at source level, so a commercial build and an open source build share the same core. Ask WSO2 which features sit only in the licensed distribution and how upgrades between 7.x releases are handled. |
How each server is built and deployed, and what that means for operations
Both servers are Java identity platforms that run in your own infrastructure, but they make different assumptions about databases, clustering and packaging. The cards below set out those assumptions so you can estimate the operating work each one creates before you choose.
Keycloak's database requirement
Keycloak needs a relational database in production. The supported options include PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL. The default dev-file database is for development only. Confirm that your DBA team already runs one of these engines with backup and restore procedures you can rely on, because the database becomes the system of record for realms, users and sessions.
Keycloak high availability designs
Keycloak documents three high availability architectures: one cluster optionally spread across availability zones, multi-cluster deployments (v2) without an external Infinispan cluster, and the deprecated multi-cluster v1 that used a separate Infinispan cluster per site. Both supported designs depend on a synchronously replicated database, so replication latency between sites becomes an architectural constraint. Confirm the replication behavior, failover time and sizing with tests in your own environment before you commit to a design.
Keycloak Operator and Helm options
The Keycloak Operator for Kubernetes and OpenShift is installed through the Operator Lifecycle Manager, which is the recommended method, or with kubectl. An experimental Helm chart is also available. The Operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources, but it does not provision your database for you. Keycloak's documentation strongly recommends manual approval mode for operator updates, so plan a review step for every upgrade.
WSO2 deployment targets and JDK
WSO2 Identity Server can be self-hosted on Kubernetes, Docker, virtual machines or bare metal, and WSO2 also offers Asgardeo as a SaaS option built on the same core. It requires a JDK compliant with Java 21 or Java 25. Check that your platform team supports one of these runtimes and that your container images, patch cycle and JVM tooling match it. Confirm which deployment pattern WSO2 supports for your clustering needs, since its documentation sets the boundaries for those choices.
WSO2 embedded H2 limits
WSO2 Identity Server ships with an embedded H2 database, which is for development and testing only. Production needs an external database such as Oracle, PostgreSQL, MySQL or Microsoft SQL Server. A team that evaluates the product on the default setup and then moves to production must plan a database migration, a configuration change and a retest of user stores and identity data. Ask WSO2 or your implementation partner to document that migration path before you build on the evaluation environment.
Operating effort for each platform
Keycloak's operating work centers on the database, cluster topology and the Operator upgrade cycle, and its schema migrates at startup by default, with a manual option for large deployments. WSO2 adds a JDK and a supported deployment target choice to the list, and its commercial subscription covers updates and expert support. Ask each vendor for a written upgrade procedure, a list of supported runtimes and the staffing your team needs to run both platforms over a year. Quotes should reflect the scope you agree in writing with your implementer.
Protocols, user stores and B2B features side by side
This table compares protocol support, user store options, B2B features and production database rules for Keycloak and WSO2 Identity Server. Where a supplied fact is missing, the cell tells you what to confirm in the current documentation, so check those rows against your own requirements before you shortlist either product.
| Capability | Keycloak | WSO2 Identity Server |
|---|---|---|
| License | Apache-2.0 | Source code under Apache-2.0; unsupported distribution on GitHub, paid subscription builds for commercial use |
| SAML | SAML 2.0 supported | SAML supported |
| OpenID Connect and OAuth 2.0 | OpenID Connect and OAuth 2.0 supported | OpenID Connect supported; confirm OAuth 2.0 grant coverage in the current documentation |
| SCIM | Confirm SCIM support in the current Keycloak documentation | SCIM supported |
| WS-Federation | Confirm WS-Federation support in the current Keycloak documentation | WS-Federation supported |
| LDAP or Active Directory user stores | Federates users from LDAP or Active Directory | LDAP directories such as OpenLDAP and Active Directory supported as user stores |
| Custom user stores | Confirm custom user storage options in the current Keycloak documentation | Custom user store implementations supported |
| Identity brokering to external providers | Brokers logins to external OpenID Connect or SAML providers | Confirm brokering options in the current WSO2 documentation |
| Organization hierarchies and delegated administration | Confirm organization and delegated administration features in the current Keycloak documentation | README lists delegated administration and organization hierarchies |
| Per-customer login options and FAPI support | Confirm per-customer login and FAPI support in the current Keycloak documentation | README lists per-customer login options and FAPI support for API security |
| Production databases | PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and others listed in the database guide | Works with Oracle, PostgreSQL, MySQL and Microsoft SQL Server |
| Embedded database rule | Default dev-file database is for development only, not production | Embedded H2 database is for development and testing only |
What each licence and edition gives you
Keycloak is licensed under Apache-2.0 and is maintained by the Keycloak project, a Cloud Native Computing Foundation incubating project. The project publishes the source, the server distribution and the Operator, and there is no paid edition of the upstream code. Since Keycloak 26.0, the project plans four minor releases a year and a major release every two to three years, and says breaking changes in a minor release will be opt-in. The current release is 26.8.1, published October 13, 2026.
- Licence: Apache-2.0, with no commercial licence tier for the server itself.
- Support: Community support through the project's public channels, with no contractual response commitments.
- Updates: New minor releases on the published cadence, with fixes delivered in the project's own release stream.
- Vulnerability handling: Security fixes ship through upstream releases, so your team must track them and apply them.
- When paid support matters: When your team cannot absorb upgrade testing, incident response and patch work without an external contract.
Confirm the upgrade window your team can meet against the release cadence before you commit to this route.
The Red Hat build of Keycloak is Red Hat's supported distribution based on the open source Keycloak project, and it replaces Red Hat Single Sign-On. Red Hat maintains the build, packages it for its own platform and sells the subscription that covers it. Red Hat's product page showed version 26.6 as its latest at the time of research, so confirm the current version on the product page before you plan around it.
- Licence: Keycloak remains open source, while the packaged build is delivered under Red Hat's subscription terms.
- Support: Vendor support from Red Hat under the subscription, which your procurement team should confirm for scope and response levels.
- Updates: Supported builds that Red Hat tests and ships on its own schedule, which may trail upstream releases.
- Vulnerability handling: Red Hat issues advisories for its build, so confirm how fast those advisories reach your team.
- When paid support matters: When your organization runs Red Hat platforms already and needs a vendor to own the support case.
Ask Red Hat which version lines and support windows apply to your subscription before you choose this path.
The WSO2 Identity Server source code is licensed under Apache-2.0, and the project publishes releases on GitHub. WSO2 describes the GitHub distribution as unsupported and intended for do-it-yourself builds. The current release is v7.3.0, published May 13, 2026, and the WSO2 documentation covers that version. Building and running this distribution is the responsibility of your team.
- Licence: Apache-2.0 for the source code, which permits your own builds and modifications under its terms.
- Support: None from WSO2 for the open source distribution, according to WSO2's product page.
- Updates: Releases appear on the GitHub releases page, and your team decides when to adopt them.
- Vulnerability monitoring: WSO2's paid subscription includes vulnerability monitoring, so this route leaves that work with your team.
- Commercial use: The product page does not offer the licensed distribution for commercial use on this route, so confirm that point with WSO2 before production use.
Check the current licence terms in the repository and with WSO2 before you deploy this build in a regulated environment.
The WSO2 on-prem product subscription is the paid route for running WSO2 Identity Server in your own infrastructure. It provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. WSO2 also documents commercial deployments as receiving updates for enhancements, fixes and performance, alongside expert support. WSO2 offers self-hosting on Kubernetes, Docker, virtual machines or bare metal, plus SaaS options such as Asgardeo.
- Licence: Commercial licence for the licensed distribution, with the Apache-2.0 source available separately.
- Support: Expert support from WSO2 under the subscription, with scope and tiers to confirm in the contract.
- Updates: Continuous product updates delivered through the subscription, including enhancements, fixes and performance changes.
- Vulnerability monitoring: Included in the subscription, so WSO2 tracks issues for the licensed build.
- When the subscription matters: When production use, audit evidence of vendor patching or a vendor escalation path is required.
Request the subscription terms in writing and confirm which tier covers your deployment model before you budget for it.
Which protocols and user stores decide the fit
The protocol list rarely decides this comparison. What decides it is where each platform expects a user record to live and whether a customer's directory is read, brokered or replaced. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, federates users from LDAP or Active Directory, and brokers logins to external OIDC or SAML identity providers. A realm can therefore keep local accounts, read an existing directory, or send authentication to an upstream provider. WSO2 Identity Server supports SAML, OpenID Connect, SCIM and WS-Federation, and its user stores can be a relational database, an LDAP directory such as OpenLDAP or Active Directory, or a custom user store implementation. In both designs, the password stays with the system that holds the account. Decide early which system is the source of truth for each user population.
B2B onboarding is where the two designs diverge in practice. WSO2 documents delegated administration, per-customer login options and organization hierarchies in its README, so the question for your team is how those settings map to a customer whose employees sit in their own Active Directory. For Keycloak, confirm in the Keycloak server administration guide how per-customer identity providers, user federation and administrative delegation are scoped. Each customer onboarding path needs a network route to the directory or a metadata exchange with the customer's identity provider, plus a service account with read rights. Write those steps down per customer type before you compare licensing or support terms.
Before you commit, confirm two items against current documentation: whether your applications need WS-Federation (WSO2 lists it, and you should verify Keycloak's position for your protocol list) and the SCIM provisioning details for Keycloak, including which resources and operations you need. Then test your own directory schema in a non-production environment. Check attribute names, multi-valued group membership, nested groups, account disabled flags and any custom attributes used to map a user to a tenant. Schema mismatches are cheap to find in a test realm or user store and expensive to unwind after customers have logged in.
What drives the running cost of each platform
Running either platform costs more than the software license, and the license is often the smallest line. The cards below separate one-time build work from recurring spend on infrastructure, people, support, upgrades and testing, so the quote you request can be compared line by line.
Database and production infrastructure
Both platforms need a production relational database rather than an embedded one. Keycloak supports PostgreSQL 14 to 18, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL, and its high availability designs require a synchronously replicated database. WSO2 Identity Server works with Oracle, PostgreSQL, MySQL and Microsoft SQL Server, while its embedded H2 database is for development only. Ask who provisions, licenses and backs up the database and whether that cost sits in your existing estate or the quote.
High availability nodes and capacity
Keycloak documents three high availability architectures, from one cluster spread across availability zones to multi-cluster designs, so node count and placement depend on the one you choose. WSO2 Identity Server runs on Kubernetes, Docker, virtual machines or bare metal, so the compute footprint depends on your standard. Recurring cost comes from the nodes, load balancers, monitoring and the failover tests you run each year. Ask for a sizing assumption in writing and the environments it covers, such as staging and disaster recovery.
Skilled staff across the stack
Running either server needs people who understand Java runtime tuning, the chosen database, identity protocols and, if you deploy on Kubernetes, cluster operations. WSO2 adds a JDK requirement, and the current listing names Java 21 or Java 25, so your Java team must own patching of the runtime. This is recurring payroll or contractor time, and it does not appear in a license line. Ask the implementation partner which of these skills it supplies during the build and which it expects your team to hold after handover.
Vendor support and subscriptions
WSO2 commercial deployments run on an on-prem product subscription that provides expert support, continuous product updates and vulnerability monitoring, and the unsupported open source distribution leaves those with your team. Keycloak is free to run, but if you want vendor-backed support you may buy it separately, for example from Red Hat's build of Keycloak. This is a recurring fee. Confirm the subscription term, the support hours and what is excluded before comparing it with an internal support rota.
Upgrade effort and release cadence
Keycloak plans four minor releases a year and a major release every two to three years, with breaking changes in minor releases made opt-in. The Operator documentation strongly recommends manual approval for operator updates, which means someone must schedule and test each upgrade. WSO2 product updates arrive through the subscription, and you still need a test cycle before applying them. Upgrades recur, so budget the testing window, not only the migration. Ask each vendor for its supported upgrade paths and the release notes you must review.
Customization and testing
Custom user stores, login themes, B2B delegated administration and per-customer login options all need code or configuration that you must test after every release. WSO2 supports custom user store implementations, so custom connectors carry their own maintenance. This is mostly one-time build work with recurring regression testing attached. Ask the implementation partner for a fixed-scope list of customizations, the acceptance tests for each and who owns them after handover. DeployOpen does not publish prices, and a quote follows the written scope.
Moving from one platform to the other
The sequence moves identity traffic, users and client configuration from one server to the other without a single unplanned login outage. The result is a documented cutover with a retired source server and an inventory that both teams can audit.
Inventory clients, protocols and dependencies
The platform owner and each application team list every relying party, the protocol it uses (OpenID Connect, OAuth 2.0, SAML 2.0, SCIM or WS-Federation), its redirect URIs, signing certificates, token lifetimes and any service accounts. Include scripts, CI jobs and API consumers that obtain tokens, because they often break first. The step is done when every client has an owner, a protocol and a test case, and the list has been reviewed by the security team. Confirm which protocols each server supports in your exact version before you assume a one-to-one match.
Map realms, tenants and organizations
Translate the existing tenancy model into the target. In Keycloak this usually means deciding how realms, groups and the Organizations feature map to the WSO2 organization hierarchy, or the reverse. Record which administrators manage which tenant, which per-customer login options exist, and which identity providers are brokered. The output is a mapping document that a reviewer can check line by line. Do not assume that organization or delegation concepts carry over unchanged, and confirm each mapping in a non-production environment first.
Export or re-create users and credentials
Decide whether user records move or stay in place. If both servers read the same LDAP or Active Directory store, user federation links can often be re-pointed without moving accounts, so passwords and directory attributes stay where they already live. If accounts sit in an internal database, export them under a documented procedure and check that password hashes can be imported in the target format. Where hashes cannot move, plan forced resets or a staged re-enrollment of MFA. The step is done when a sample of migrated users can authenticate in staging and their group memberships match the source.
Reconfigure SAML and OIDC clients
Recreate each client on the target server using the inventory from the first step. Protocol endpoints and metadata formats are standard in principle, but the entity IDs, claim mappings, audience values, signing keys and logout URLs must be set again and tested. For each application, run a login, token refresh and logout test against staging and record the result. The step is done when every client passes its test case and the application owners have signed off in writing.
Rebuild login flows, branding and extensions
Admin configuration, authentication flows, custom user store or event listener code, themes, email templates and any WSO2-specific features do not move automatically. Rebuild them on the target platform and document each one against its original. Custom extensions often need rewriting in the target's extension model, so schedule a code review with the developers who wrote them. The step is done when every login screen, branded page and MFA path has a matching configuration and a reviewer has compared the two side by side.
Run both servers in parallel
Keep the source server live while the target serves a pilot group or non-critical applications. Monitor sign-in success rates, token errors, directory sync jobs and audit logs on both sides, and keep a rollback path that reverts DNS, load balancer or application settings to the source. Confirm that the database, backup and monitoring setup on the target meets the same standard as the original. The step is done when pilot logins are stable across the agreed test period and the rollback has been rehearsed.
Cut over applications in controlled waves
Move the remaining applications in groups, starting with those with the lowest blast radius. For each wave, switch the client configuration or issuer URL, confirm sign-in and API token flows, and announce a freeze window to the affected teams. Keep the source read-only for changes so that no account updates are lost. The step is done when all clients point to the target, a post-cutover checklist has been signed off, and no traffic reaches the old issuer endpoint.
Retire the source and keep the evidence
After the agreed observation period, disable the old server, archive its configuration, database and audit logs according to your retention policy, and revoke its service credentials and certificates. Keep the mapping documents, test results and sign-offs with the change record so auditors and future operators can trace each decision. The step is done when the source is decommissioned, its data is archived or deleted under the approved retention rules, and the change record is closed.
Where implementation projects usually run long
Implementation effort for Keycloak and WSO2 Identity Server clusters around the same few decisions. On the Keycloak side, the first is the database: Keycloak needs a relational database in production, and its high availability designs depend on a synchronously replicated database, so the chosen engine (for example PostgreSQL 14 to 18 or Microsoft SQL Server) and its replication setup must be settled before any realm is built. On the WSO2 side, the equivalent decisions are the JDK (Java 21 or Java 25), the external database and whether users live in a relational store, an LDAP directory or a custom user store. Whichever route is chosen, the choice of Kubernetes with the Keycloak Operator or virtual machines with the server distribution changes who maintains the automation, and that choice should be written into the statement of work with the named owner of each layer.
Projects overrun most often in four places. The first is an unclear B2B tenancy model: Keycloak realms, its Organizations feature, WSO2 organization hierarchies and per-customer login options imply different delegation and branding boundaries, and redesigning them after client onboarding has started is expensive. The second is late directory schema discovery, where attribute mappings, group nesting and LDAP or Active Directory naming only surface during testing. The third is upgrade planning: Keycloak plans four minor releases a year and makes breaking changes opt-in, while WSO2 release cadence and patch windows depend on the subscription, so the upgrade path and rollback test belong in scope from the start. The fourth is custom user store work, which is open-ended unless its interface, data volume and test cases are fixed in writing.
The client must supply an application inventory listing each relying party, its protocol, its login flows and its owner, plus read access to the directory and a test account for each user type. Each project also needs a named owner with authority to approve realm or tenant design, and a written decision on support: whether the team will run the platform alone, buy a Red Hat or WSO2 subscription, or combine internal staff with a retainer. Those decisions shape the fixed scope agreed before work starts. Ask for the scope, deliverables and test plan in writing, including login flow tests and upgrade rehearsal, and confirm with each vendor which support tier covers the components you run.
Questions buyers ask before choosing Keycloak or WSO2
How much does it cost to run Keycloak or WSO2 Identity Server?
Neither project charges a license fee for its open source code, since Keycloak and the WSO2 Identity Server source are both Apache-2.0. Your running cost comes from four places: the infrastructure for a clustered deployment, a production database that your engine license terms may price separately, staff time for operations and upgrades, and any vendor subscription. WSO2 sells on-prem subscriptions, and Red Hat sells a supported Keycloak build, but neither price is in the facts available to this page, so ask both vendors for a written quote. Ask each quote to state what it includes, the support tier, the number of environments, and whether upgrades are covered.
Do you need a paid WSO2 subscription for production?
WSO2 publishes an unsupported open source distribution on GitHub for do-it-yourself builds, and that route is not a commercial production support arrangement. Commercial deployments receive product updates for enhancements, fixes and performance, plus expert support from WSO2. The on-prem subscription also adds vulnerability monitoring and access to the licensed distribution for commercial use. Whether your production use needs that licensed distribution depends on WSO2's terms, so confirm the terms in writing before you build on the unsupported route. Your own security team will also need a named owner for patching if you stay unsupported.
Can you run Keycloak without a Red Hat subscription?
Yes. Upstream Keycloak is Apache-2.0 open source, published at keycloak.org and on GitHub, and it does not require a Red Hat subscription to run. The Red Hat build of Keycloak is a supported distribution based on the same project, and it replaces Red Hat Single Sign-On. You pay for it when you need Red Hat's support, certified packaging or its lifecycle terms. Check the release line each option ships, because Red Hat's product page showed version 26.6 as its latest, while upstream Keycloak 26.8.1 is the current release. Without a vendor subscription, your support comes from your own team, the community, or a retainer with an implementation partner.
How long does a migration from WSO2 to Keycloak take?
No migration duration is supplied for this move, so take a timeline only from a written scope. The main drivers are the number of applications, the protocol flows each one uses (SAML, OpenID Connect, SCIM or WS-Federation), and whether custom login flows or user store code must be rebuilt. Your user data matters too: Keycloak can federate users from LDAP or Active Directory, so an existing directory may stay in place. Also count the B2B tenant model, the data cutover plan and the test effort per application. Keycloak runs its database schema migration automatically at startup by default, but large deployments often apply that SQL manually, which adds planning work.
Can our team run either platform without outside help?
A capable team can run either platform alone, but the prerequisites are real and should be checked before you commit. Keycloak needs a relational database in production, and its high availability designs need a synchronously replicated database. WSO2 needs a JDK compliant with Java 21 or Java 25, and its embedded H2 database is for development and testing only. Most teams still buy outside help for the initial architecture, hardening, backup and restore testing, and each upgrade. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under fixed-scope engagements agreed in writing, with retainers for ongoing support.
What does the identity work need from our own staff?
Plan for named roles rather than a single administrator. An identity architect owns the protocol and tenant design, a database administrator owns the production database and its replication, and a platform engineer owns the Kubernetes or virtual machine layer. Each application needs an owner who can supply redirect URIs, claims and test accounts. Your security or compliance lead needs to review configuration and collect evidence, and your service desk needs a process for user lifecycle tasks. The time each role commits depends on the number of applications and the migration path, so confirm those hours inside the written scope before work begins.
Does Keycloak support the B2B features WSO2 lists?
Keycloak covers part of this list directly, including brokering logins to external OpenID Connect or SAML providers, user federation from LDAP or Active Directory, realms, and fine-grained authorization services. The WSO2 README lists delegated administration, per-customer login options, organization hierarchies and FAPI support for API security. The facts available to this page do not confirm that Keycloak matches each of those four items, so verify them yourself. Test delegated administration, per-customer identity provider configuration, organization hierarchies and the FAPI profile your APIs need against your own requirements in a non-production environment before you choose.
How often do upgrades arrive, and who applies them?
Keycloak has planned four minor releases a year since version 26.0, with a major release every two to three years, and it says breaking changes in a minor release will be opt-in. The Keycloak Operator documentation recommends manual approval mode so that updates do not happen unintentionally. WSO2's commercial subscription includes continuous product updates, while the unsupported distribution carries no update commitment from WSO2. Either way, your team or an implementation partner must test each upgrade, apply it and roll it back if needed. Ask both vendors which release lines they will patch and for how long before you commit to a version.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including Keycloak and WSO2 Identity Server deployments. We start by confirming which protocols, user stores and B2B features your applications actually need, then write the scope before any work begins.
How we scope
- Inventory the applications, protocols (SAML, OIDC, SCIM, WS-Federation) and user stores each identity server must serve.
- Confirm whether the target is the community Keycloak release, the WSO2 unsupported distribution or a WSO2 paid subscription build.
- Agree the scope, deliverables and timelines in writing before work starts. Most engagements are fixed-scope.
How we build
- Deploy on your Kubernetes, virtual machine or bare metal footprint, with the production database chosen from the vendor's supported list.
- Connect LDAP or Active Directory user stores, external identity providers and B2B organization or delegated administration as scoped.
- Test login flows, token behavior, failover and upgrade paths in a non-production environment before cutover.
How we hand over
- Document the architecture, configuration, database and high availability design, and the operating runbooks for your team.
- Record how licensing, support entitlements and version upgrades apply to the edition you chose, so decisions stay traceable.
- Walk your administrators through backups, upgrades and the evidence needed for compliance assessments, which DeployOpen prepares but independent auditors issue.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainers can cover version upgrades, patch review and operational monitoring against the scope agreed in writing.
- Ask for a written quote that lists the scope, deliverables and support terms so you can compare it with any vendor subscription.
