Oracle EBS Single Sign-On (SSO): The Complete Implementation Guide

Updated July 2026: published the complete Oracle EBS SSO implementation guide, including OAM, EBS Asserter, in-app connectors, specialist gateways, and the access proxy path.

Oracle E-Business Suite predates SAML and OIDC, so "add SSO to EBS" is really an architecture question: how do you turn an identity asserted by Microsoft Entra ID, Okta, Ping, or another provider into a valid EBS session for the right FND_USER? This guide explains how EBS authentication actually works, compares five implementation paths, and walks through implementation, including the mistakes that stall projects and one security reason this matters more in 2026.

How Oracle EBS authentication actually works

Out of the box, EBS authenticates users against its own user store, the FND_USER table, with what Oracle calls local authentication. On success, EBS establishes the user's session through the ICX session cookie, which carries the session for everything the user does across EBS responsibilities. There is no native SAML or OIDC support in that flow.

Every EBS SSO approach therefore performs the same fundamental move: authenticate the user somewhere else, then establish a legitimate ICX session for the mapped FND_USER. The paths differ in what performs the authentication, what creates the session, and how much infrastructure - Oracle middleware, directories, WebLogic applications, gateways, connectors, or proxies - you must build, license, and maintain.

Three design constants apply regardless of path:

• Identity mapping. Your IdP asserts a UPN or email; EBS expects an FND_USER username. A cross-reference between the two is a required design step.
• Trust boundary. Whatever creates sessions on users' behalf must be the only path to the EBS application tier. If EBS is directly reachable, the SSO layer can be bypassed.
• EBS security is unchanged. Responsibilities, profiles, and data security continue to work exactly as configured. SSO replaces how users prove identity, not what they can access.

The five implementation paths

Path 1: The classic Oracle stack - OAM + OID + AccessGate

The traditional answer is Oracle Access Manager for authentication, Oracle Internet Directory synchronized with FND_USER, and WebGate or AccessGate components wiring the flow into EBS. It works, and EBS 12.2 formally supports it, but it means running an Oracle identity middleware estate whose main job is EBS login. That is rational where OAM already exists and is staffed; it is harder to justify standing up fresh. Already on OAM and mainly need MFA? See layering MFA onto OAM without touching OAM.

Path 2: Oracle's modern path - EBS Asserter + OCI IAM

Oracle's newer path uses the EBS Asserter, a Java application deployed on WebLogic that obtains the user's identity from OCI IAM, formerly IDCS, and generates the EBS session cookie. It is lighter than OAM, but it is still its own application to deploy, secure, cluster for high availability, and operate. It also makes OCI IAM part of the identity flow, which can add another platform if your enterprise standard is Microsoft Entra ID, Okta, Ping, or another IdP.

Path 3: EBS-specialist SSO gateways

Several vendors sell gateway products purpose-built for EBS SSO. They can be capable products, but evaluate them on the same axes as everything else here: what runs where, what touches your EBS tier, which IdPs are first-class, and what the maintenance profile looks like across EBS patch cycles.

Path 4: In-app connectors

In-app connectors install on the EBS application tier to add SAML support or MFA hooks inside EBS. The appeal is depth, but the trade-off is coupling: components on the EBS tier become part of every EBS patch and upgrade test cycle.

Path 5: Access proxy in front of EBS

A reverse proxy terminates authentication before EBS. The user is redirected to an identity provider such as Microsoft Entra ID, Okta, Ping, Cisco Duo, or Google, which enforces SSO, MFA, and conditional access. On success, Datawiza Access Proxy maps the authenticated identity to the EBS username and uses the configured EBS service-account and DBC-file flow to establish the user's ICX session. The user lands in EBS as themselves, with normal responsibilities. Nothing is installed on EBS servers, no OID synchronization is required, and there is no EBS Asserter WebLogic application to operate. The step-by-step configuration is documented in the Entra ID + Oracle EBS best-practice guide; Lifeway's production deployment shows it at work.

If your real goal is MFA, not SSO, the proxy path also runs without any identity provider. With Datawiza built-in MFA, users keep signing in with their existing EBS credentials, and Datawiza enforces an MFA challenge after the existing EBS login and before application access. That is often the fastest route to a compliance or insurance deadline, covered in depth in MFA for Oracle EBS, including external populations like iSupplier portal users.

Why this matters in 2026: internet-facing EBS remains exposed

A 2025 Datawiza breach analysis covered attacks targeting internet-facing EBS systems, including exposed portals, password-reset abuse, MFA bypass, and patch-cycle lag. The architectural lesson was not only to patch faster. It was that EBS application tiers directly reachable from the internet, such as iSupplier, iStore, and other external portals, create the attack surface. See the EBS breach's hidden risk for the original framing.

An authenticating proxy in front of EBS means unauthenticated internet traffic does not reach the EBS tier. Every request passes an identity check first. If your EBS serves external users, the SSO project and the exposure-reduction project are often the same project.

Comparison

Step-by-step: implementing EBS SSO with an access proxy

1. Design the identity mapping. Decide which IdP attribute maps to the FND_USER username; build a cross-reference for mismatches.
2. Create the EBS service account. In the Datawiza docs, the example user is DWSSOUSER, with the Apps Schema Connect role assigned. The DCMC application settings then use the EBS Service Account, EBS Account Password, EBS User Mapping, and EBS DBC Content generated from the EBS environment. Follow the best-practice guide for exact setup details.
3. Deploy the proxy, either SaaS or self-hosted container, with the EBS web entry point as upstream.
4. Register the application in your identity provider and configure OIDC or SAML in the Datawiza console, or enable built-in MFA if you are running without an IdP.
5. Lock the trust boundary. Firewall the EBS application tier so it accepts traffic only from the proxy. For internet-facing EBS, this is the exposure-reduction step, not just SSO hygiene.
6. Test beyond the happy path: responsibility switching, session timeout, sign-out, deep links and bookmarked URLs, and external user populations such as iSupplier or iStore.
7. Pilot, then cut over DNS, and retain IdP policy exports and authentication logs as audit and insurance evidence.

Common mistakes that stall EBS SSO projects

• Treating FND_USER mapping as a detail. It is often the schedule risk.
• Leaving the EBS tier directly reachable, which bypasses the SSO layer and preserves internet exposure.
• Forgetting external populations. iSupplier and iStore users are in scope for MFA questionnaires too, and they are often the reason built-in MFA exists.
• Assuming a directory sync is required. OID synchronization is a Path 1 artifact, not a law of EBS SSO.
• Coupling SSO components to the EBS tier and re-testing them at every patch cycle.
• Deferring MFA. With an IdP in front, MFA is an IdP policy decision; without one, Datawiza built-in MFA covers the challenge after the existing EBS login and before application access.

Frequently asked questions

Does Oracle EBS support SAML or OIDC natively?

No. EBS authenticates against FND_USER local authentication and has no native SAML or OIDC support. External SSO requires a component that authenticates the user elsewhere and establishes the EBS session.

Do we need OAM and OID for EBS SSO?

No. The classic OAM + OID stack is one path, not a requirement. An access proxy achieves SSO and MFA with your existing identity provider without Oracle identity middleware or directory synchronization.

Do we need the EBS Asserter or OCI IAM?

No. The Asserter is Oracle's path and requires OCI IAM plus a WebLogic application to operate. A proxy connects EBS directly to Entra ID, Okta, Ping, Duo, or Google, or runs with no IdP using built-in MFA.

How does the proxy create the EBS session without changing EBS?

After the user authenticates, Datawiza maps the authenticated identity to the EBS username and uses the configured EBS service-account and DBC-file flow to establish the user's ICX session. The user lands in EBS as their own FND_USER with normal responsibilities.

Which EBS releases does the proxy approach support?

The Datawiza docs state that supported Oracle EBS versions include v12.0 or later, including common 12.1 and 12.2 deployments. Because nothing is installed as an EBS application-tier plugin, the approach also reduces SSO retesting during EBS patch cycles.

Can we add MFA to EBS without any identity provider?

Yes. Datawiza built-in MFA keeps existing EBS logins unchanged and enforces an MFA challenge after the existing EBS login and before application access. See MFA for Oracle EBS.

Does SSO change EBS responsibilities or security?

No. Responsibilities, profiles, and data security are untouched. SSO replaces the sign-in step only.

Ready to implement Oracle EBS SSO?

The Datawiza EBS SSO and MFA solution delivers the proxy architecture as a product. See Lifeway's deployment, or book a demo with your EBS release and identity provider in mind.