Legacy App SSO · JD Edwards
JD Edwards EnterpriseOne SSO with Keycloak
EnterpriseOne's documented single sign-on runs through Oracle Access Management rather than SAML or OIDC directly. We keep that trusted path intact, federate it to Keycloak, and give web client users one login with MFA — including their Entra ID, Okta or AD credentials.
- Keeps JDE's OAM token validation
- Entra ID, Okta or AD via Keycloak
- EnterpriseOne user IDs linked
Standards & integrations
- SAML 2.0
- Oracle Access Management
- JDE_SSO_TOKEN
- EnterpriseOne HTML Server
- Oracle WebLogic
- LDAP / Active Directory
Overview
How JD Edwards SSO actually works
EnterpriseOne's HTML server doesn't trust an external identity provider directly. In Oracle's documented setup for Tools Release 9.2.6 and later, Oracle Access Management authenticates the user and passes a token in the JDE_SSO_TOKEN header, which the HTML server validates against OAM's REST API before creating the session. We keep that path and make Keycloak the identity provider behind OAM over SAML 2.0 — so users sign in at Keycloak, with MFA and their existing Entra ID, Okta or AD credentials, while EnterpriseOne keeps validating the same OAM token.
What we deliver
- SSO assessment for your Tools Release, OAM version and topology
- Keycloak realm with MFA and directory or Entra ID brokering
- Oracle Access Manager federation to Keycloak over SAML 2.0
- EnterpriseOne user ID mapping and reconciliation
- Review of AIS and service connections
- Rollout and rollback runbook per environment
Capabilities
What JD Edwards covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
Tools Release-aware design
We confirm your Tools Release and OAM version, and follow the SSO method Oracle documents for that combination.
OAM federated to Keycloak
OAM trusts Keycloak as its identity provider over SAML 2.0, so users stop signing in at OAM while EnterpriseOne's token validation stays unchanged.
MFA enforced at Keycloak
Users complete MFA at Keycloak before OAM issues a token — OTP, passkeys or push, per your policy.
User ID mapping
Keycloak identities, including those brokered from Entra ID, Okta or AD, map to EnterpriseOne user IDs — even where the JDE ID differs from the directory username.
Environment separation
Production, pre-production and development each get their own configuration, so a test login can never reach production.
Session and logout alignment
HTML server, OAM and Keycloak session timeouts are aligned, and signing out ends all three.
Compatibility
EnterpriseOne sign-on options
The route depends on your Tools Release and OAM version, confirmed against Oracle's documentation before design.
| Platform | Integration | Notes |
|---|---|---|
| Tools Release 9.2.6 and later | OAM token validation (JDE_SSO_TOKEN), OAM federated to Keycloak | The HTML server validates the OAM token through OAM's REST API. |
| Earlier Tools Releases | OAM-based SSO, OAM federated to Keycloak | Older OAM setups differ; we follow Oracle's documented method for your release. |
| Entra ID, Okta or AD users | Brokered through Keycloak | Users keep their existing credentials. |
| AIS and orchestrator clients | Existing service authentication | Reviewed separately from browser SSO. |
How it works
From first call to production
Assess Tools Release and topology
We review the Tools Release, HTML and AIS servers, WebLogic and your OAM deployment, and confirm how EnterpriseOne validates SSO today.
Federate in pre-production
OAM is federated to Keycloak and user mapping is configured in pre-production, then tested with real roles and environments.
Roll out by environment
Environments move one at a time with a rollback path, finishing with production in a planned window.
Use cases
Where teams put it to work
Plant and warehouse users
Shift workers sign in with the same credentials as other plant systems, with session timeouts suited to shared stations.
MFA for financial modules
Protect finance users with MFA to meet internal control requirements without changing EnterpriseOne code.
Mixed Oracle estates
Organisations running JDE alongside EBS or PeopleSoft move all of them to one identity provider.
FAQ
JD Edwards questions, answered
Does JD Edwards EnterpriseOne support SAML or OIDC natively?
Oracle's documented EnterpriseOne SSO runs through Oracle Access Management rather than SAML or OIDC directly. That's why we federate Keycloak into OAM instead of connecting EnterpriseOne to Keycloak itself — the HTML server keeps validating the same OAM token.
What is JDE_SSO_TOKEN?
In the OAM-based setup for Tools Release 9.2.6 and later, OAM passes its session token to the HTML server in the JDE_SSO_TOKEN header, and the HTML server validates it against OAM's REST API before creating the EnterpriseOne session.
Can we use Entra ID (Azure AD) or Okta with JD Edwards?
Yes. Keycloak brokers Entra ID, Okta or Active Directory, and OAM trusts Keycloak as its identity provider, so users sign in with the accounts they already have.
Do we need to keep Oracle Access Manager?
For EnterpriseOne's documented SSO, yes — OAM is what the HTML server validates against. What changes is that OAM stops being where users sign in: Keycloak takes that role, with MFA and passkeys.
Does this affect AIS and orchestrations?
Browser sign-on and service calls are separate. AIS and orchestration clients keep their existing authentication unless you choose to change them; we review them so nothing breaks during the switch.
Ready to roll out JD Edwards?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.