PingFederate vs Keycloak: when each one fits
A renewal, a support window or a licensing change is usually what forces the federation decision, and the first question is which protocols your relying parties actually use. PingFederate is the stronger fit when a meaningful share of your estate depends on WS-Federation and WS-Trust relying parties, when you have already invested in custom PingFederate adapters and integration kits, or when your organization needs a commercial support contract with Ping and has standardized on that support model. Keycloak fits well when your estate is built mainly on SAML 2.0 and OpenID Connect, when you want Apache 2.0 licensing with no per-connection commercial agreement, and when your own platform or operations team is prepared to run the server. Keycloak is licensed under the Apache License 2.0 and supports OpenID Connect, OAuth 2.0 and SAML 2.0, but it does not cover WS-Federation, so that gap must be closed on paper before any commitment.
The decision turns on three things. The first is a protocol inventory of every connection, listing the protocol, binding, signing and encryption settings, and any WS-Trust token issuance, because a single WS-Federation dependency can change the whole plan. The second is the scale of connections, meaning how many service providers, OAuth clients and identity sources you run, how often they change, and whether they are owned by a central team or by business units that create their own. The third is who will operate the platform. Keycloak's operational work includes database selection and high availability design, upgrade planning, backup, and monitoring, and the Keycloak Operator's documentation strongly recommends manual approval mode for operator updates. Ask Ping for the scope of its support terms and ask yourself whether your team can own the same responsibilities in-house or through a partner. Confirm details such as which WS-Federation features your relying parties require against each product's current documentation.
Which option fits which federation scenario
This table maps common federation scenarios to the platform that usually fits better and why. Read each row against your own estate, then use a protocol inventory to settle borderline cases where WS-Federation, adapters or support requirements decide the outcome.
| Scenario | Better fit | Reason |
|---|---|---|
| SAML and OIDC relying parties only | Keycloak | Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 directly, so most web and SaaS connections map to standard clients and mappers. |
| WS-Federation relying parties still in use | Keycloak alone may not fit | Keycloak's documented protocols are OIDC, OAuth 2.0 and SAML 2.0. Confirm WS-Federation needs in your inventory before choosing Keycloak as the sole hub. |
| Team with strong Kubernetes operations | Keycloak | Keycloak offers an Operator managed through Operator Lifecycle Manager, with custom resources for realms and clients, which suits GitOps-driven platforms. |
| Team with limited container or database operations | Confirm before choosing | Keycloak needs a supported production database with synchronous replication for HA. Ask whether your team can run that, or whether a vendor-backed route is needed. |
| Regulated buyer requiring vendor-backed support | Ping or a supported Keycloak distribution | Red Hat build of Keycloak is a supported distribution of the open source project. Ask Ping and any vendor about support terms, and confirm they match your audit obligations. |
| PingFederate version nearing end of support | Decide on a timeline with both options priced | Compare the cost of upgrading within Ping's support windows against a phased move to Keycloak. Ask Ping for its published end of support dates for your version. |
| Heavy use of Ping adapters and custom integration kits | Plan the migration carefully | Adapter logic and attribute contracts must be rebuilt as Keycloak flows and mappers. Inventory each connection before committing to a date. |
| Need for multi-tenant customer identity | ZITADEL, assessed separately | Keycloak and PingFederate are workforce-oriented hubs in this comparison. Evaluate ZITADEL's Identity System, Organizations and Projects model if tenants are the main requirement. |
Does Keycloak cover WS-Federation relying parties?
The short answer is that Keycloak's documented protocols are OpenID Connect, OAuth 2.0 and SAML 2.0, and WS-Federation and WS-Trust are not among them. Before you decide anything about PingFederate, confirm the current position in the Keycloak server documentation and with the Keycloak project, because protocol support changes between releases and this page cannot settle it for you. Treat any WS-Federation relying party as unmigrated until that check is complete.
The reason this matters is that PingFederate relying parties using WS-Federation need an explicit outcome. Each one must either move to a platform that supports WS-Federation, such as WSO2 Identity Server, or be retired. Moving the SAML and OIDC connections to Keycloak will not carry WS-Federation traffic with it, so a cutover plan built only around Keycloak would leave those applications without a sign-in path on the day the old federation service is switched off.
Start the inventory from the PingFederate side. Export the connection list, then for each SP connection and OAuth client record the protocol actually in use, the endpoint the application calls, and the token format it expects. Applications that consume WS-Federation tokens usually reference a passive sign-in endpoint and a token type such as SAML 1.1 or SAML 2.0 issued through a WS-Trust exchange, so check the application's configuration and its request logs as well as the PingFederate connection. Mark each application as WS-Federation only, mixed, or SAML or OIDC only. Ask the application owners to confirm the result, because a connection that looks like SAML may still depend on a WS-Federation fallback.
PingFederate vs Keycloak capability by capability
This table compares PingFederate and Keycloak on the capabilities that matter when Keycloak becomes the federation hub. Where the supplied research does not settle a point, the cell tells you what to confirm with Ping documentation or the Keycloak docs before you decide.
| Capability | PingFederate | Keycloak |
|---|---|---|
| SAML 2.0, OIDC and OAuth 2.0 | Supported. Confirm the exact protocol profiles and versions your relying parties need in Ping's current documentation. | Supported for OpenID Connect, OAuth 2.0 and SAML 2.0 as a core protocol set. |
| WS-Federation and WS-Trust | Supported. Inventory every WS-Federation relying party before planning, since these are the dependencies that Keycloak does not cover. | Not listed among Keycloak's supported protocols. Confirm with the Keycloak documentation before assuming any coverage. |
| User federation with LDAP and Active Directory | Available through PingFederate's data store and directory integrations. Confirm the directory types and versions your environment uses. | Built-in user federation with existing LDAP and Active Directory servers. |
| Identity brokering | Confirm the supported upstream IdP patterns with Ping documentation. | Included as a core capability alongside single sign-on. |
| Fine-grained authorization services | Confirm which authorization policy features apply to your connections with Ping. | Included as a core capability. Map existing access rules to Keycloak's authorization model before cutover. |
| Admin console | Administrative console for connections, adapters and OAuth clients. Confirm the role model you need for delegated administration. | Included in the platform. Confirm role and realm delegation fits your operating model. |
| Adapters and integration kits | Ping provides adapters and integration kits. Confirm which of your application integrations depend on them and whether they are available for your version. | Keycloak uses its own client configuration, flows and mappers. Custom PingFederate adapters have no direct equivalent, so plan a per-application mapping. |
| Clustering and high availability | Confirm clustering and failover design with Ping's deployment guidance for your version. | Three high availability architectures are documented, and both supported designs need a synchronously replicated database. The multi-cluster v1 design is deprecated. |
| Database support | Confirm the supported data stores with Ping documentation. | Supports MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL (14 to 18), EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL in production. |
| Kubernetes operator management | Confirm the deployment options Ping supports for containers and orchestration. | The Keycloak Operator manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient resources. Manual approval for operator updates is strongly recommended. |
How connection management and clustering differ at scale
PingFederate and Keycloak both serve as a federation hub for many relying parties, but they run, scale and back up differently. The cards below cover the Keycloak facts that shape the design, and the questions to put to Ping about your own PingFederate topology before you compare them.
High availability architecture choice
Keycloak documents three high availability architectures: a single cluster that can optionally span availability zones, multi-cluster deployments (v2) that do not need an external Infinispan cluster, and the deprecated multi-cluster v1 design that used a separate Infinispan cluster per site. Pick the design before you build, because moving between them later is a project of its own. Map your PingFederate clustering model, including how many nodes serve traffic and how many sites you run, against these options and confirm with Ping how its engine nodes and administrative node are deployed in your environment.
Synchronously replicated database
Both supported Keycloak high availability designs require a synchronously replicated database. This shifts a clustering decision into the database tier, where you need a replication model your DBA team can operate and monitor. Keycloak lists PostgreSQL 14 to 18, Aurora PostgreSQL, EnterpriseDB Advanced, MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Azure SQL as supported production databases. Confirm which of these your standards allow and whether your existing database licensing covers the new workload.
Connection and client management at scale
In PingFederate, connections (SP and IdP connections, OAuth clients) are defined in the administrative console and replicated to engine nodes. In Keycloak, each relying party is a client with its own protocol mappers, and clients can be created with the Keycloak Operator through KeycloakOIDCClient and KeycloakSAMLClient resources. Inventory your connection count, how often they change, and who owns each change. Ask Ping how connection changes propagate across engine nodes in your topology and how long a change takes to reach all of them.
Realm export is not a backup
Keycloak exports and imports realms as JSON with the kc.sh export and kc.sh import commands. The documentation warns that this is limited as a backup and restore method, and that all nodes must be stopped while the export runs. Plan for a database-level backup and a tested restore procedure instead, and use realm exports for configuration snapshots and migration staging. Ask Ping what its configuration archive holds, how it is restored and whether engine nodes must be taken offline during restore.
Upgrades and schema migration
Keycloak migrates its database schema automatically at startup by default, and it also supports manual migration, which the upgrading guide suggests for large deployments. The Operator documentation strongly recommends manual approval for operator updates to avoid unintended automatic upgrades. Keycloak plans four minor releases a year, and breaking changes in minor releases are opt-in. Decide who approves schema changes, how a rollback works and where the upgrade is tested before production. Compare this with Ping's Long-Term and Short-Term Support windows, which set the pace of your own upgrades.
Operator-managed deployment on Kubernetes
The Keycloak Operator is installed through Operator Lifecycle Manager, which is the recommended method, or with kubectl or an experimental Helm chart. It manages Keycloak, KeycloakRealmImport, KeycloakOIDCClient and KeycloakSAMLClient custom resources, so clients and realms can be version controlled alongside the cluster. If your PingFederate runs on virtual machines, this is a change in operating model for your platform team. Confirm that your Kubernetes platform, GitOps tooling and on-call practice can support the Operator before you commit to it.
Where the identity data and the platform run
In a self-managed PingFederate deployment, the server runs in your data center or your cloud account, and your team owns the operating system, the Java runtime, the database and the network path to every relying party. Ping supplies the product and, under its support terms, the fixes. User attributes usually come from a directory such as PingDirectory, Active Directory or an LDAP store that you operate, so PingFederate reads identity data rather than becoming the system of record. Signing keys and certificates live in the PingFederate configuration and key stores, and the configuration archive contains private keys, so it must be handled as a secret. Session data depends on the adapters and the clustered engines you configure.
- Data location: Attributes stay in the directory you run, while the configuration archive holds keys and must be stored under your secrets controls.
- Administrative access: Your administrators hold console access, and Ping staff access only what your support engagement grants.
- Compliance evidence: You produce change records, key rotation logs, access reviews for the console and evidence of the support window in force.
- Platform patching: Your team applies the product maintenance windows, which differ between Long-Term and Short-Term Support versions.
- Confirm: Ask Ping in writing where any support or telemetry access terminates and which operator actions it covers.
Confirm the exact support and access terms with Ping before you finalize your evidence plan.
With self-hosted Keycloak, the server, the database and the network sit in infrastructure you control, and the Apache 2.0 license places no vendor on the operating path. User records, credentials and sessions are stored in the database you choose from the supported list, and Keycloak keeps signing keys in its realm key configuration. You can also keep users in LDAP or Active Directory through user federation, so the directory remains the source for attributes. Because the platform is open source, your team or a partner maintains every component, including upgrades.
- Data location: Realms, users, client secrets and session state sit in your production database, which must be synchronously replicated in high availability designs.
- Signing keys: Realm keys are created and rotated under your procedures, and the export and import tooling must be run with all nodes stopped.
- Administrative access: Your administrators hold realm and master realm access, so you define break-glass accounts and review them.
- Compliance evidence: You produce the upgrade records, backup and restore tests, access reviews and logging evidence yourself.
- Operations: Upgrades are your responsibility, and the Operator's manual approval mode is the documented way to control them.
Check how your chosen database, backups and key storage map to the controls your assessor will test.
The Red Hat build of Keycloak is Red Hat's supported distribution of the open source Keycloak project, and it replaces Red Hat Single Sign-On. The runtime still sits in your infrastructure, so data residency and key custody match the self-hosted model, but the subscription changes who answers for defects and security fixes. Red Hat documents its own support lifecycle, which you should map against your change calendar before you commit to a version.
- Data location: Identity data and keys remain in your database and key stores, the same as the community build.
- Support boundary: Red Hat supports the distribution, so ask which components, databases and configurations fall inside the subscription.
- Administrative access: Subscription support staff access systems only through the channels your agreement defines, and you should record those channels.
- Compliance evidence: You still produce access, change and backup records, and you add the subscription and support records as supporting material.
- Version tracking: Confirm the current supported version on the Red Hat product page at the time of your planning.
Confirm the subscription scope and support terms in writing with Red Hat before relying on them as control evidence.
Support lifecycle and licensing: what each contract actually buys
The first thing to pin down is which PingFederate version you run and which maintenance window it sits in. Ping's end of life policy separates Long-Term Support (LTS) and Short-Term Support (STS) versions, each with its own maintenance window, and it sells Extended Limited Support separately for versions that have passed end of support. Read the current policy directly and build a table that lists your version, its window end date and whether Extended Limited Support would be needed. That table, not the license terms, determines how soon you face an upgrade or replacement decision.
Keycloak is licensed under the Apache License 2.0, so there is no subscription that gates the software itself. Its release model is different from a fixed support window. The project plans four minor releases a year and a major release every two to three years, and it says breaking changes in a minor release will be opt-in. That means the upgrade work does not disappear. It moves to whoever operates the platform, whether that is your own team or a support provider. Budget for regular minor upgrades, for reviewing release notes for opt-in changes, and for testing your realms, clients and custom authenticators before each one reaches production.
Red Hat build of Keycloak is the supported distribution if you want a vendor to carry patch and support obligations, and it replaces Red Hat Single Sign-On. Retainers from DeployOpen or another provider can cover upgrades, patching and continuous testing for an agreed scope. Price each option against the same list: which versions and patch levels are covered, who performs upgrades, how many environments are included and who owns incident response. Ask each vendor for its support terms in writing, and confirm the current Red Hat support dates on its product page, because a supported build is only as useful as its published lifecycle.
What drives the cost of each option
Both paths carry licensing or subscription lines, project work and staff time, but they recur on different schedules and move with different inputs. Read each card as a component to price separately, then ask every vendor and partner for a written quote tied to a written scope.
PingFederate subscription and support
This is a recurring line paid to Ping for the PingFederate license and support entitlement. Its size depends on the license terms in your agreement, the environments you license (production, staging, disaster recovery) and the support tier you choose. Ask Ping for a written quote that states which environments, support hours and renewal terms are included, and confirm how the price changes at renewal.
Extended Limited Support fees
If your PingFederate version is past its support window, Ping may sell Extended Limited Support as a separate, recurring charge. Under Ping's end of life policy, Long-Term and Short-Term Support versions have different maintenance windows, so the fee depends on which window your version falls in and how long you stay on it. Ask for the exact end date for your version and the price for each extra year before you plan the bridge period.
Upgrade projects on the Ping side
Staying on PingFederate means one-time upgrade work whenever you move to a supported release. The effort scales with the number of relying parties, custom adapters, OAuth clients and integration kits that must be retested. Ask the partner for a scope that lists each connection to retest, and for the test environments needed to prove the upgrade before production.
Keycloak infrastructure
Running Keycloak on your own cloud accounts or data centers creates recurring compute, database and storage costs, plus a high availability design that needs a synchronously replicated database. Costs rise with the number of nodes, the number of environments and any availability zones or disaster recovery sites. Ask your platform team to size these for your expected login volume and to price each environment separately.
Keycloak support subscription
Keycloak itself is Apache 2.0 licensed and carries no license fee. If you want a vendor-backed support contract, you pay a recurring subscription to a provider such as Red Hat, whose build of Keycloak is supported under its own terms. Ask whether the subscription covers the release train you intend to run, the number of environments and the response times you need, and whether it is priced per node or per core.
Migration and ongoing operations staff
Migration is a one-time project for scoping connections, mapping adapters to Keycloak flows and mappers, testing and cutover. Operations is recurring: patching, upgrades, backups and on-call coverage. The release train you choose drives this line, because Keycloak ships four minor releases a year and a major release every two to three years. Ask partners for a fixed-scope quote with named deliverables, and confirm which upgrade and support hours are retained separately.
What a move from PingFederate to Keycloak involves
The sequence turns an undocumented set of PingFederate connections into a tested Keycloak estate that runs alongside Ping until each application has cut over cleanly. It produces a migration inventory, a target platform and a backup approach that work before the first application moves.
Inventory connections and adapters from the configuration archive
The engagement team reads the PingFederate configuration export and lists every SAML service provider, OIDC client, OAuth client, WS-Federation relying party, IdP connection and adapter. The client's application owners confirm which entries are live, which are retired and who owns each one. The output is a migration inventory with one row per connection, including its protocol, the adapter it depends on and its certificate and signing details. Private keys in the archive are handled under the client's key management rules, not copied into project notes. The step is done when the application owners have signed off on the list.
Map adapters and attribute contracts to Keycloak
For each inventoried connection, the team records which attributes the relying party expects, where PingFederate sources them (directory lookups, adapter fields or transformations), and how Keycloak will supply them through client scopes, protocol mappers and user federation. Adapters that run custom Java code or call internal services need a separate design decision, because Keycloak does not run PingFederate adapters unchanged. The output is a mapping sheet that a second engineer reviews against live test logins. The step closes when each connection has an agreed Keycloak client configuration and a named test case.
Resolve WS-Federation and WS-Trust dependencies
Before any cutover plan is fixed, the team checks whether any relying party depends on WS-Federation or WS-Trust. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so applications using those protocols map to Keycloak clients, but WS-Federation and WS-Trust relying parties need a different answer, such as keeping them on PingFederate, a separate identity server, or a change to the application. The decision belongs to the client, with the application owner and the security lead signing it off. The step is complete when every WS-Federation dependency has a written path, and the Keycloak scope is fixed to the protocols it covers.
Build the target cluster, database and backup approach
The team provisions the Keycloak runtime in the client's own environment, which may be virtual machines, Kubernetes with the Keycloak Operator, or another approved platform. It selects a supported production database from the Keycloak list and confirms the high availability design, which requires a synchronously replicated database. Operator updates are set to manual approval, and the schema migration approach (automatic at startup or applied manually) is chosen and documented. A backup approach is also built now, because the Keycloak documentation notes that realm export and import has limitations as a backup and restore mechanism and that all nodes must be stopped during the process. The team restores a copy into a test environment and confirms the output is a working estate. This step is done when a restore test has passed.
Run both platforms in parallel, application by application
Applications move in batches, starting with low-risk relying parties. For each one, the team points a test tenant or a staging copy of the application at Keycloak, runs the test cases from the mapping sheet, and compares the claims or assertions with what PingFederate issues. Users may be given a choice of login path during a short coexistence window, depending on the client's change process. Discrepancies in attribute values, claim formats or signing certificates are logged and fixed before the next batch. The step is done when each batch has a passing test record and the application owner has accepted it.
Cut over each application with a rollback plan
For each application, the team schedules a change window agreed with the client, switches the relying party's trust configuration to Keycloak, and monitors sign-in success and error rates using the metrics Keycloak exposes. The rollback plan for each application is written in advance: the PingFederate connection stays configured and reversible until the application owner confirms stable operation. Certificates, metadata and redirect URIs are checked at each switch. The output is a cutover record per application that names the change, the test run and the rollback step. The step closes when the last application is confirmed stable and its PingFederate connection is retired under the client's decommissioning procedure.
Operate Keycloak and retire PingFederate
After the final cutover, the client's operations team takes over Keycloak upgrades, backup runs and restore tests, monitoring, and access reviews of the admin console. Keycloak's minor releases arrive several times a year, so the client needs a dated upgrade procedure and a staging environment for each one. The client confirms which support arrangement applies to its Keycloak build, whether community or a commercial distribution such as Red Hat build of Keycloak. Retirement of PingFederate is recorded as a separate change, including the handling of its archive, keys and license file. The step is done when the operations runbook has been used once for a routine upgrade in staging.
How much effort does a PingFederate to Keycloak move take?
What drives the cost of moving PingFederate to Keycloak?
The main cost driver is the number of connections and how much logic sits inside each one. A move costs more when PingFederate serves many SAML and OIDC relying parties, uses custom adapters, applies attribute transformations in the attribute contract, or depends on OAuth clients with unusual token settings. Keycloak can cover most SAML and OIDC flows, but each custom adapter or policy rule has to be rebuilt as a Keycloak flow, mapper or client configuration and then tested. Ask any provider to price the work from a written inventory of connections, adapters, certificates and user stores. Your own licensing and support costs for PingFederate are separate from the one-time project cost, and the project cost is separate from the recurring cost of running Keycloak on your own infrastructure, which includes the database, hosting, patching and support you choose to buy.
How long does a PingFederate to Keycloak migration usually take?
Duration depends on the size of the connection inventory, the number of protocols in use and how many applications can tolerate a parallel run. Teams usually move applications in waves rather than in one cutover, so the number of waves and the test effort per wave set the timeline. We do not publish a fixed duration, and any figure you see for a generic migration should be checked against your own inventory. The biggest schedule risks are WS-Federation relying parties, applications with undocumented claim logic and change freezes on the business side. Ask for a timeline in the written scope, with milestones tied to the applications in each wave.
What does the migration need from our own team?
Your team supplies the knowledge of the business and the applications, and that input is usually the limiting factor. You will need named owners for each relying party who can confirm attribute needs, redirect URIs, logout behavior and test accounts. Your security team should approve certificate handling, key storage, MFA policy and the target network design. Your identity or infrastructure team will need access to the existing PingFederate configuration export and the environment where Keycloak will run, plus a change window for each application. Ask the provider to list these inputs in the written scope so that delays can be assigned to a named person before work starts.
Can our team migrate from PingFederate to Keycloak without outside help?
A team with Keycloak operations experience can migrate a small set of standards-based SAML or OIDC applications without outside help, provided it has time to test and the applications are well documented. The work gets harder when there are many connections, WS-Federation or WS-Trust dependencies, custom adapters, or a high-availability requirement that has to be proven before cutover. Keycloak is licensed under Apache 2.0 and has an active project, so the software itself carries no license fee, but the effort to rebuild and validate each connection is the real cost. A useful test is whether your team can produce a complete inventory and a rollback plan for each application before the first cutover.
What happens to WS-Federation applications during the move?
Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so WS-Federation relying parties are not covered by Keycloak alone. Each WS-Federation application needs a decision before work starts: keep it on a platform that supports WS-Federation, change the application to SAML or OIDC where its owner can do so, or plan a separate federation path for that application. Your inventory should flag every WS-Federation and WS-Trust dependency, along with the token types and claims each one expects. Confirm the approach with the application owners and your vendors, since some of these applications may not be able to change their login code.
Does the Keycloak cluster need a synchronously replicated database?
Yes, for the supported high availability designs. Keycloak documents three high availability architectures: a single cluster optionally spread across availability zones, multi-cluster deployments (v2) without external Infinispan, and the deprecated multi-cluster v1 that used a separate Infinispan cluster per site. Both supported designs need a synchronously replicated database. Keycloak supports PostgreSQL 14 to 18, along with several other production databases, so the database team should confirm the version, replication model and failover behavior before the design is approved. Database licensing and operation are recurring costs, and they should be included in the quote comparison.
What does a fixed-scope engagement with DeployOpen cover?
A DeployOpen engagement is usually fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. In a migration engagement, the written scope should name the applications in each wave, the connection and attribute mappings to be rebuilt, the test and cutover approach, the backup and rollback steps, and the documentation handed over at the end. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. We do not issue audit reports or certifications, so any compliance evidence we prepare is for your assessor. Ongoing support, upgrades and continuous testing are available as retainers. A quote follows from the written scope, and we do not publish a price list.
How DeployOpen helps you decide and move
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For PingFederate vs Keycloak, we start with your federation inventory, test the protocol and adapter gaps against your real relying parties, and only then recommend a path.
How we scope
- We inventory every SAML, OIDC, OAuth and WS-Federation connection, with owners and business criticality, before any design work starts.
- We record which adapters, attribute contracts and clustering needs each PingFederate connection depends on, so gaps are visible early.
- Engagements are fixed-scope, and the written scope sets deliverables, timelines and testing responsibilities before work begins.
How we build
- We deploy Keycloak in your own cloud account, data center or air-gapped network, following the high availability design your uptime requirements call for.
- We map relying party configurations to Keycloak clients, flows and mappers, and test each one against a staging copy of your identity data.
- We plan the database, upgrade method and operator update approach, and document how schema changes are applied in your environment.
How we hand over
- You receive documentation covering the connection inventory, configuration decisions, backup and restore steps and the cutover runbook.
- We prepare the controls and evidence your compliance assessors may ask for, while independent auditors remain responsible for any formal assessment.
- Knowledge transfer sessions walk your platform and security teams through daily operation, monitoring and the process for handling security updates.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover, scoped in writing.
- We can run security testing against your federation endpoints and applications, and report findings for your remediation teams.
- Ask for a quote built from the written scope, with the support, upgrade and testing components priced separately so you can choose what you need.
