Legacy App SSO · Siebel CRM
Siebel CRM SSO with Keycloak
Siebel CRM 17.0 and later support both header-based Web SSO and federated SSO with SAML. We connect whichever fits your deployment to Keycloak — hardened against spoofing — so agents and portal users get one login with MFA.
- Web SSO or SAML (Siebel 17.0+)
- Hardened trusted-header path
- MFA at Keycloak
Standards & integrations
- SAML 2.0
- OpenID Connect
- Siebel Application Interface
- Siebel security adapter
- LDAP / Active Directory
Overview
Two ways Siebel trusts a login
Oracle's Siebel security documentation describes two SSO models for Siebel CRM 17.0 and later. With Web SSO, the Siebel Application Interface reads the user name from an HTTP request header set by the component in front of it, and the security adapter trusts it through a shared trust token. With federated SSO, Siebel trusts a SAML assertion from an identity provider, so no trusted header is involved. We pick the model per deployment, make Keycloak the identity provider, and — for header-based setups — make sure nothing but the proxy can set that header.
What we deliver
- Sign-on design for your Siebel release and topology
- SAML federation or reverse proxy with header hardening
- Security adapter and application interface configuration
- Keycloak realms and clients for internal and portal users
- User mapping and reconciliation
- Penetration-style test of the trust path
Capabilities
What Siebel CRM covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
SAML federation with Keycloak
On Siebel CRM 17.0 and later, Siebel trusts Keycloak as a SAML identity provider for interactive users — the cleanest option where your update level supports it.
Keycloak-backed Web SSO
Where headers fit better, a proxy in front of the Siebel Application Interface signs users in at Keycloak and forwards the user name Siebel is configured to trust.
Hardened header path
Client-supplied headers are stripped, the application interface only accepts traffic from the proxy, and the trust token is kept out of reach.
Mapping to Siebel logins
Keycloak identities map to Siebel user IDs through the security adapter's directory, with mismatches resolved before go-live.
MFA for agents and portal users
Contact-centre staff sign in with Entra ID, Okta or AD through Keycloak, and eService or ePartner users each get an MFA policy that fits how they work.
Session alignment
Siebel session timeouts and Keycloak sessions are aligned so users aren't signed out halfway through a customer call.
Compatibility
Siebel sign-on options
Confirmed against your Siebel release and update level during the review.
| Platform | Integration | Notes |
|---|---|---|
| Siebel CRM 17.0 and later | Federated SSO with SAML 2.0 to Keycloak | Keycloak as the identity provider; confirm your update level. |
| Header-based Web SSO | Reverse proxy + trusted header + security adapter | Single sign-on, trust token and user header configured on the security adapter. |
| Earlier Siebel releases | Web SSO through a hardened proxy | SAML federation isn't available; the trusted-header path is locked down instead. |
| eService / ePartner portals | Keycloak realm for external users | Self-registration, social login or customer IdP federation. |
| Siebel Open UI | Same SSO session | The UI framework doesn't change the sign-on path. |
| Mobile and disconnected clients | Reviewed case by case | Offline clients may need their own authentication path. |
How it works
From first call to production
Review release and security adapter
We confirm the Siebel release, update level, application interface topology and security adapter settings, then choose SAML or Web SSO.
Build and attack-test the path
Keycloak clients, the SAML or proxy configuration and adapter settings are set up in a test environment and probed for header injection and direct access.
Switch users over
Agents move first in a planned window, then portal users, with a rollback path at each stage.
Use cases
Where teams put it to work
Contact-centre agents
Agents sign in once at the start of a shift and move between Siebel and their other tools without repeated prompts.
Customer and partner portals
eService and ePartner users sign in through Keycloak with self-registration, social login or their company's IdP.
Retiring OAM or SiteMinder
Replace the access manager that fronts Siebel Web SSO today with Keycloak, without changing Siebel users or responsibilities.
FAQ
Siebel CRM questions, answered
Does Siebel CRM support SAML SSO?
Yes. Oracle's Siebel security documentation covers federated single sign-on with SAML for Siebel CRM 17.0, 18.0 and later, alongside header-based Web SSO. Older releases rely on Web SSO.
What's the difference between Web SSO and SAML SSO in Siebel?
With Web SSO, a component in front of Siebel authenticates the user and passes the user name in an HTTP header that the Siebel Application Interface trusts. With SAML, Siebel trusts a signed assertion from the identity provider, so no trusted header is involved.
Do we need Oracle Access Manager or SiteMinder for Siebel SSO?
No. Those were common front ends for Siebel Web SSO, but Keycloak can take their place — as the SAML identity provider, or behind a hardened proxy for header-based Web SSO.
Can Siebel users sign in with Entra ID or Okta?
Yes. Keycloak brokers Entra ID, Okta or Active Directory for agents, and can offer self-registration or social login for eService and ePartner users.
Is trusted-header SSO secure?
It is when the only way to reach Siebel is through the proxy and the proxy discards identity headers sent by the browser. We enforce both at the network and proxy layers and test them before go-live.
Do Siebel users need new accounts?
No. Existing Siebel users, positions and responsibilities stay as they are. Keycloak changes how users authenticate, and we map each identity to its existing Siebel login.
Ready to roll out Siebel CRM?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.