Keycloak and SiteMinder Federation: SAML and OIDC Integration Guide

Last updated: June 2026

TL;DR

Yes, Keycloak integrates with CA SiteMinder (now Broadcom SiteMinder / CA Single Sign-On / Symantec SiteMinder) over standard federation, and you do not have to kill SiteMinder to start. SiteMinder is a SAML 2.0 IdP and SP, and newer releases speak OIDC too, so Keycloak federates with it the same way it federates with any standards-based partner. The short version:

• You have two clean topologies. Either Keycloak brokers SiteMinder (Keycloak is the SAML SP, SiteMinder stays the auth authority) or Keycloak becomes the IdP and SiteMinder Federation consumes it. Pick based on which direction you are migrating.
• Coexistence is the whole point. Run both. Onboard modern OIDC apps against Keycloak today while your SiteMinder-protected legacy apps keep working untouched, then migrate apps in waves.
• Attributes are the contract. SiteMinder assertion attributes become Keycloak user attributes via Attribute Importer mappers, then become token claims via protocol mappers. NameID format alignment is the part teams forget.
• Single Logout will disappoint you. SAML SLO across vendors is fragile, and front-channel SLO fails silently more often than it works. Converge session timeouts instead of trusting SLO. We will be honest about this below.
• MFA stays where it lives. If SiteMinder is the IdP, SiteMinder Advanced Authentication keeps owning MFA. Keycloak layers step-up per client. Decide who owns step-up so users do not get prompted twice.

We run managed Keycloak for enterprises doing exactly this kind of phased coexistence, so this guide is the same one we walk customers through.

Can Keycloak integrate with SiteMinder?

Yes, because the integration happens at the protocol level, not through any vendor-specific connector. SiteMinder is a Web Access Management product whose Federation services implement SAML 2.0 and WS-Federation, and newer releases add OpenID Connect. Keycloak is fluent in all three, so the two systems federate by exchanging metadata, not by sharing a database.

It helps to be precise about what SiteMinder actually is, because the name has changed roughly once per acquisition. It started as Netegrity SiteMinder, became CA SiteMinder, was rebranded CA Single Sign-On, passed through Symantec, and now lives at Broadcom. Under every name it does the same core job: a policy server plus Web Agents that protect legacy web apps. The Web Agents inject HTTP headers (the classic one is SM_USER) that downstream apps read to identify the logged-in user. That header-injection model is the reason these apps cannot just move to OIDC overnight, and it is exactly why coexistence beats a big-bang cutover.

The mental shift is this: you are not replacing SiteMinder on day one. You are putting a modern, standards-native IdP next to it and connecting the two with SAML or OIDC. From there you migrate apps when each app team is ready, not when a change advisory board picks a doomed weekend. Keycloak’s job in both topologies is to be a clean federation partner that also happens to speak every modern protocol your new apps want. If your modernization spans more than SiteMinder, the same coexist-then-migrate playbook applies to other legacy stacks: see our Cloud Foundry UAA to Keycloak migration guide for the sibling scenario.

What are the two ways to run Keycloak alongside SiteMinder?

There are two coexistence topologies, and the right one depends on which way identity is flowing. According to the Keycloak server administration guide, Keycloak’s identity brokering lets it act as both a SAML SP (consuming an external IdP) and a SAML IdP (serving external SPs), which is precisely the flexibility this problem needs. Topology one keeps SiteMinder as the authority; topology two hands the authority to Keycloak.

Here is the decision in one table.

	Topology 1: Keycloak brokers SiteMinder	Topology 2: Keycloak is the IdP
Auth authority	SiteMinder	Keycloak
Keycloak role	SAML SP / broker	SAML IdP (or OIDC provider)
SiteMinder role	SAML IdP	SAML SP / consumer (Federation)
Who you onboard	New OIDC/SAML apps onto Keycloak	Legacy apps keep trusting the new Keycloak IdP
Migration direction	Early phase: SiteMinder still owns login	Later phase: Keycloak takes over login
MFA owner	SiteMinder Advanced Authentication	Keycloak (or kept at SiteMinder behind it)

Most enterprises start at topology one and end at topology two. Early in a migration, SiteMinder still owns the user database and the MFA policy, so you broker it and quietly start landing new applications on Keycloak’s OIDC endpoints. Later, once Keycloak holds the user store (or federates LDAP/AD directly) and you trust it as the login authority, you flip: Keycloak becomes the IdP and SiteMinder Federation consumes it for the legacy apps that are not migrated yet. You can even run both directions at once during the overlap, which is messy on a diagram but perfectly valid in practice.

We will not re-teach generic SAML broker setup here. For the step-by-step mechanics of adding any external SAML IdP, see our Entra ID SAML in Keycloak guide, and for the general SP role read the Keycloak SAML service provider guide. This post stays SiteMinder-specific.

How do I federate SiteMinder with Keycloak via SAML (Keycloak as the broker)?

In topology one you add SiteMinder as a SAML v2.0 identity provider inside Keycloak, exchange metadata both ways, and let users authenticate at SiteMinder while Keycloak issues its own OIDC tokens to modern apps. Per the Keycloak SAML identity broker docs, Keycloak consumes the external IdP’s SAML assertion and mints fresh tokens for downstream clients, which is the bridge from SiteMinder’s SAML world to your OIDC apps.

The Keycloak-side setup is concrete and well within our domain.

Add SiteMinder as a SAML v2.0 identity provider

In your realm, go to Identity Providers, choose SAML v2.0, and give it an alias like siteminder. The fastest path is metadata import: paste SiteMinder’s federation metadata URL into Import external IDP config, and Keycloak fills the SSO service URL, entity ID, and signing certificate for you. If your SiteMinder team will not expose a live metadata endpoint (common in locked-down government environments), get the metadata XML file and import it manually. Either way, you then export Keycloak’s SP metadata (available at /realms/{realm}/broker/siteminder/endpoint/descriptor) and hand it to the SiteMinder admin so they can register Keycloak as a remote SAML SP, also called a Service Provider partner in SiteMinder Federation.

Set the toggles that actually matter

A handful of settings decide whether the first handshake works or fails with an opaque error:

• NameID Policy Format. This must match what SiteMinder is configured to send. More on this in the failure-modes section, because it is the single most common cause of a broken first login.
• Want AuthnRequests Signed / Validate Signature. Decide signing on both sides and make them agree. If SiteMinder signs assertions, import its signing cert and turn on Validate Signature.
• HTTP-POST vs HTTP-Redirect binding. SiteMinder Federation supports both. Match the binding SiteMinder publishes for its SSO service.
• Principal Type and Principal Attribute. This controls how Keycloak maps the incoming assertion to a Keycloak user, typically by NameID or by a named attribute.

Let new OIDC apps in immediately

Once the broker works, a modern app does not know SiteMinder exists. It points at Keycloak’s standard OIDC discovery document, runs an authorization code flow with PKCE, and Keycloak transparently redirects the user to SiteMinder for the actual login. The user authenticates against SiteMinder, the assertion comes back, Keycloak provisions or links the user, and your app receives clean OIDC tokens. That is the win: SiteMinder stays the auth authority, but every new app you build speaks OIDC against Keycloak. For the deeper pattern of turning an inbound SAML assertion into OIDC tokens, our SAML-to-OIDC bridging guide covers the edge cases, including IdP-initiated flows.

One honest caveat: in this topology SiteMinder remains a hard dependency for every login, including logins to your shiny new apps. That is fine as a phase, but it is the reason topology two exists.

How do I make Keycloak the IdP with SiteMinder as the consumer?

In topology two you configure Keycloak as a SAML IdP (or an OIDC provider where your SiteMinder release supports it) and register it inside SiteMinder Federation as a remote IdP partner. SiteMinder Federation has supported consuming third-party SAML 2.0 IdPs for many years, and on newer releases it can consume OIDC providers as well, so Keycloak slots in as the upstream identity authority for the legacy apps SiteMinder still protects.

This is the direction of travel. You take over the IdP role with Keycloak, but you do not have to re-platform the legacy apps that depend on SiteMinder Web Agents and SM_USER headers. They keep talking to SiteMinder. SiteMinder just stops authenticating users itself and instead trusts an assertion from Keycloak.

Keycloak-side setup

Keycloak is a SAML IdP for any client you register as a SAML client. Create a client of type saml for the SiteMinder Federation partner, set its Valid Redirect URIs and the SiteMinder Assertion Consumer Service (ACS) URL, and decide your signing and encryption posture under the client’s Keys and SAML Capabilities tabs. Export Keycloak’s IdP metadata from /realms/{realm}/protocol/saml/descriptor and give it to the SiteMinder admin to create a SAML Authentication Scheme or a remote IdP partner that points at Keycloak.

If your SiteMinder version supports OIDC, you can instead register Keycloak as an OIDC provider, which is generally less brittle than SAML because there is no XML signing dance and no SLO ambiguity. Whether OIDC is available depends on your specific SiteMinder release, so confirm with your SiteMinder team rather than assuming. When OIDC is on the table, prefer it.

Where the user store lives

For topology two to be worth it, Keycloak needs to authenticate users credibly. Usually that means Keycloak federates the same Active Directory or LDAP that SiteMinder was reading, so both systems see one source of truth during the overlap. Our Keycloak LDAP integration guide and Active Directory integration guide cover that wiring. The clean end state is: AD/LDAP holds credentials, Keycloak is the IdP, and SiteMinder is reduced to a federation consumer protecting the legacy apps you have not retired yet.

How do I map SiteMinder attributes into Keycloak tokens?

You map SiteMinder assertion attributes into Keycloak user attributes with Identity Provider mappers (specifically the Attribute Importer), then surface them as token claims with protocol mappers. According to the Keycloak identity broker mapper docs, the Attribute Importer copies a named SAML attribute from the incoming assertion onto the brokered user, which is the join point between SiteMinder’s assertion format and your OIDC token contract.

Think of it as a two-hop pipeline, and both hops matter.

Hop one: assertion to user attribute. In topology one, on the siteminder identity provider, add an Attribute Importer mapper per attribute SiteMinder sends. If SiteMinder’s assertion carries EmailAddress, FirstName, Department, and a memberOf style group attribute, you create one mapper each, naming the SAML attribute exactly as SiteMinder emits it (the friendly name or the full attribute name/URI, whichever the assertion actually uses) and the Keycloak user attribute it lands in. Get the attribute names from a real assertion, not from a wiki, because SiteMinder Federation lets admins name attributes freely and the docs rarely match production.

Hop two: user attribute to token claim. Now those user attributes need to reach your apps. On the OIDC client (or a shared client scope), add User Attribute protocol mappers to write each attribute into the access token or ID token under the claim name your app expects. Group/role data often wants a Group or Role mapper instead. This is standard Keycloak claim work, covered in depth in our attribute mapping during identity brokering guide, so we will not repeat the mechanics here.

The detail people skip is NameID format alignment. SiteMinder’s assertion NameID has a format (unspecified, emailAddress, persistent, or transient) and Keycloak’s identity provider must be set to expect that same format. If SiteMinder sends NameID as emailAddress and Keycloak is configured for persistent, brokering breaks before any attribute mapper even runs. Decide the NameID contract first, set it identically on both sides, and only then worry about the rest of the attributes. To inspect exactly what SiteMinder is putting in an assertion, paste it into our free SAML decoder, which runs in your browser so the assertion never leaves your machine.

Does single logout work between SiteMinder and Keycloak?

Honestly? Not reliably, and you should plan as if it does not. SAML Single Logout is one of the most consistently disappointing parts of cross-vendor federation: front-channel SLO depends on every participant being reachable, returning quickly, and handling a relay of LogoutRequests without one silent failure breaking the chain. In mixed SiteMinder-and-Keycloak estates, that chain breaks often, and worse, it usually fails quietly so the user thinks they logged out when one session is still alive.

Let us bust the myth directly: SLO does not “just work.” The SAML 2.0 SLO profile is real and both products implement it, but real-world SLO across two vendors with different session stores, different timeout semantics, and different proxy layers is fragile by nature. Front-channel SLO (browser-redirected LogoutRequests) is especially prone to dropping a participant when an iframe is blocked, a third-party cookie is gone, or one endpoint is slow. Back-channel SLO is sturdier but is not always available or configured on the SiteMinder side. Banking on perfect SLO is how you ship a “logout” button that leaves a live session behind, which is the exact security gap your auditors will find.

The pragmatic answer is to stop relying on SLO as your security boundary and converge your session lifetimes instead. SiteMinder maintains its own session in its session store with idle and max timeouts; Keycloak maintains SSO sessions with SSO Session Idle and SSO Session Max in realm settings. Set these to align so that whichever system holds a session, it expires on a similar clock. If SiteMinder sessions idle out at 15 minutes, do not let Keycloak SSO sessions live for 10 hours. A user closing the browser plus a short, consistent idle timeout on both sides is a more dependable logout story than a fragile SLO relay. Wire up SLO where you can, absolutely, but treat it as best-effort cleanup, not as the thing standing between a walk-away laptop and an open session.

How do MFA and session policies survive coexistence?

The rule is simple: whoever owns login owns MFA, and you must never let both prompt. If SiteMinder is the IdP (topology one), SiteMinder Advanced Authentication keeps owning multi-factor, and Keycloak should not add its own OTP step on top, because that double-prompts the user for two factors to enter one application. If Keycloak becomes the IdP (topology two), MFA moves to Keycloak’s authentication flows.

In topology one, Keycloak can still do useful step-up without duplicating the base factor. Because Keycloak issues the OIDC tokens, it can require step-up authentication per client for sensitive apps using authentication flows and the acr / Step-up mechanism, while delegating the primary factor to SiteMinder. The key is to decide, per application, which system owns step-up, and to make that decision explicit rather than discovering it when a user complains about authenticating three times to read a dashboard. A clean division: SiteMinder owns the baseline login and its MFA, Keycloak owns app-specific step-up for the new apps it fronts.

There is a subtle trap with assurance levels. SiteMinder can express the authentication strength it performed, and Keycloak can read it (often via an attribute or a SAML AuthnContext) to decide whether step-up is even needed. If SiteMinder already did a strong factor, Keycloak should honor that and skip a redundant prompt. Getting this right is the difference between security teams trusting the coexistence and users filing tickets about prompt fatigue. Our custom authentication flow guide covers building conditional step-up flows in Keycloak if you go that route.

What are the common failure modes, and how do I fix them?

Four issues account for the overwhelming majority of broken SiteMinder-Keycloak handshakes: clock skew, NameID format mismatch, signing/encryption misconfiguration, and certificate or metadata drift. According to the SAML 2.0 core specification, assertions carry NotBefore and NotOnOrAfter conditions that receivers must validate, which is why two clocks a few minutes apart can reject a perfectly valid assertion. Here is the field guide.

Clock skew (assertion not yet valid / expired)

SAML assertions are time-boxed. If SiteMinder’s policy server clock and Keycloak’s host clock drift apart, Keycloak rejects assertions as not-yet-valid or already-expired, even though the login succeeded at SiteMinder. Fix the root cause first: NTP on both hosts, synced to the same source. Then give yourself a small buffer by setting Keycloak’s allowable clock skew on the identity provider (a value like 30 to 60 seconds is typical) so trivial drift does not break logins. Do not paper over a 10-minute drift with a 10-minute skew tolerance; fix NTP. We wrote a dedicated Keycloak clock skew fix for the deeper diagnosis.

NameID format mismatch

This is the number-one first-login killer. SiteMinder sends a NameID in a specific format (unspecified, emailAddress, persistent, or transient) and Keycloak’s SAML identity provider must be configured to expect that same format. A mismatch (SiteMinder sends emailAddress, Keycloak wants persistent) produces a failed broker login that looks like a generic error. Decode an actual assertion to see the real format, set Keycloak’s NameID Policy Format to match, and align the Principal Type so Keycloak maps the user from the right value.

Signed vs encrypted assertions

Signing and encryption are independent toggles, and both sides must agree on each. If SiteMinder signs assertions, Keycloak needs SiteMinder’s signing certificate and Validate Signature turned on, or it rejects everything. If SiteMinder encrypts assertions, Keycloak needs the matching decryption key and Want Assertions Encrypted set consistently. The classic symptom is “signature validation failed” (wrong or expired cert) or assertions that arrive but cannot be read (encryption mismatch). Match Want Assertions Signed and Want Assertions Encrypted on both ends, and confirm you imported the certificate that SiteMinder is actually signing with today, not the one from last year’s setup doc.

Certificate and metadata drift

Federation breaks months after it worked because a signing certificate rotated on one side and nobody told the other. SiteMinder rotates its signing cert, Keycloak still trusts the old one, and every login starts failing signature validation overnight. The durable fix is to consume metadata by URL where possible (so cert rotation propagates automatically) and to track certificate expiry dates on both sides as calendar events, not as tribal knowledge. If you imported metadata as a static file, you own the job of re-importing it whenever either side rotates a key. Build that into a runbook, because the failure mode is a silent time bomb.

Frequently asked questions

Can Keycloak integrate with SiteMinder?

Yes. SiteMinder (CA SiteMinder, CA Single Sign-On, Broadcom SiteMinder) is a SAML 2.0 IdP and SP, and newer releases speak OIDC, so Keycloak federates with it over standard protocols by exchanging metadata. You can run Keycloak as a broker in front of SiteMinder or as an IdP behind it, with no vendor-specific connector required.

How do I federate SiteMinder with Keycloak via SAML?

Add SiteMinder as a SAML v2.0 identity provider in your Keycloak realm under Identity Providers, import SiteMinder’s federation metadata, then export Keycloak’s SP metadata so the SiteMinder admin can register Keycloak as a remote SP. Align the NameID format and signing settings on both sides, and users will authenticate at SiteMinder while Keycloak issues OIDC tokens to your apps.

Does single logout work between SiteMinder and Keycloak?

Not reliably. SAML Single Logout is fragile across vendors, and front-channel SLO often fails silently, leaving a session alive after the user thinks they logged out. Wire up SLO as best-effort, but do not depend on it. Converge the idle and max session timeouts between SiteMinder’s session store and Keycloak’s SSO sessions so both expire on a similar clock instead.

Can Keycloak replace SiteMinder entirely?

Eventually, yes, but not in one step. The realistic path is coexistence: broker SiteMinder first, land new OIDC apps on Keycloak, then flip Keycloak to be the IdP that SiteMinder Federation consumes. You retire SiteMinder only after the last legacy app behind its Web Agents is migrated, which is usually a multi-quarter program, not a weekend.

What happens to legacy apps that read SM_USER headers?

They keep working in coexistence. SiteMinder Web Agents inject HTTP headers like SM_USER for header-based legacy SSO, and those apps stay behind SiteMinder until they are migrated. When Keycloak becomes the IdP (topology two), SiteMinder still protects and header-injects for these apps; it just trusts a Keycloak assertion for the actual authentication instead of doing the login itself.

Should I use SAML or OIDC between SiteMinder and Keycloak?

Prefer OIDC when your SiteMinder release supports it, because it avoids the XML signing complexity and the SLO ambiguity that make SAML federation brittle. Many SiteMinder estates are still SAML-only, in which case SAML 2.0 is perfectly workable. Confirm OIDC support with your SiteMinder team rather than assuming, since availability depends on the specific release.

Summary

You do not have to rip out SiteMinder to modernize your identity stack. Run Keycloak alongside it: broker SiteMinder as a SAML IdP while you onboard new OIDC apps, then flip Keycloak into the IdP role and let SiteMinder Federation consume it for the legacy apps that are not ready to move. Map assertion attributes through Attribute Importer and protocol mappers, align the NameID format, and stop trusting SLO in favor of converged session timeouts. Keep MFA where login lives, and watch the four classic failure modes: clock skew, NameID mismatch, signing/encryption disagreement, and certificate drift. Done this way, the migration is a series of small, reversible app moves instead of one terrifying cutover.

The part that drains your team

The federation handshake takes a sprint. Operating a hardened, highly available Keycloak next to SiteMinder for the full length of a multi-quarter migration is the part that quietly eats your roadmap: HA, upgrades, patching, monitoring, and on-call for a brand-new IdP at exactly the moment your architects are busy migrating apps.

That part is outsourceable. Skycloak runs the Keycloak side with an enterprise SLA, upgrades, and on-call handled, so your team spends the coexistence period migrating apps off SiteMinder instead of babysitting a new identity platform. If you are planning a SiteMinder exit, talk to us and we will sanity-check your topology and wave plan for free.