AgeSA: Single Sign-On and Oracle EBS Integration for 3,000 Employees

Oracle E-Business Suite remains the backbone of finance and HR operations for thousands of enterprises worldwide. Yet its authentication model predates modern federation standards — it does not natively support SAML 2.0, OAuth 2.0, or OpenID Connect. Integrating SSO into Oracle EBS is therefore not a simple toggle but an architectural challenge that requires bridging legacy authentication with modern identity providers.

This guide presents a proven architecture for integrating SSO with Oracle EBS using Azure AD (Entra ID) as the identity provider. The patterns are drawn from enterprise SSO integrations across regulated industries including insurance, banking, and manufacturing.

Why Oracle EBS SSO Is Hard

Oracle EBS was designed in an era when each application managed its own user credentials. The challenges are specific and well-documented:

• No native federation support: EBS does not speak SAML or OAuth. You cannot simply point it at an identity provider and enable SSO
• Tight coupling to Oracle Internet Directory (OID): EBS user provisioning relies on OID for user-to-responsibility mapping, adding an intermediate directory layer that must be synchronized
• Custom authentication hooks: Many EBS deployments have accumulated custom login pages, password policies, and session management code over 10–15 years. SSO integration must work with — not against — these customizations
• Multi-population complexity: Enterprise EBS environments serve diverse user types — internal employees, external agents, contractors — each requiring different authentication policies

Architecture Options

There are three primary approaches to integrating SSO with Oracle EBS. Each has trade-offs:

Option 1: Oracle Access Manager (OAM) + Azure AD via WS-Federation

This is the most robust approach for production environments. OAM acts as the Oracle-side SSO agent, delegating authentication to Azure AD (Entra ID) via WS-Federation or SAML. OID maintains the EBS-specific user provisioning layer. This approach preserves EBS's internal user-to-responsibility mapping while externalizing authentication.

Option 2: Custom SAML Gateway

A lightweight reverse proxy or custom gateway intercepts EBS login requests and redirects to a SAML identity provider. Simpler to deploy than OAM but less resilient — session management and token refresh require custom code that becomes a maintenance liability.

Option 3: Oracle Identity Cloud Service (IDCS)

Oracle's cloud-based identity service can bridge EBS and modern IdPs. Suitable when the organization is already invested in Oracle Cloud, but adds a dependency on Oracle's cloud infrastructure and may conflict with existing Azure AD or Okta investments.

For most enterprises with an existing Azure AD (Entra ID) deployment, Option 1 — OAM with Azure AD federation — provides the best balance of robustness, maintainability, and compatibility with EBS customizations.

Active Directory Integration Pattern

The recommended three-layer architecture:

1. Identity Provider Layer: Azure AD (Entra ID) as the authoritative identity provider, synchronized with on-premises Active Directory via Azure AD Connect. Use password hash sync and seamless SSO for a frictionless user experience. This layer owns authentication — it is the single source of truth for "who is this user?"
2. Federation Bridge Layer: Oracle Access Manager (OAM) configured to delegate authentication to Azure AD via WS-Federation. OAM validates the Azure AD token and creates an EBS-compatible session. Oracle Internet Directory (OID) maintains the mapping between Azure AD identities and EBS user accounts with their associated responsibilities
3. Policy Engine Layer: Azure AD Conditional Access policies enforce context-aware authentication — MFA for EBS access, claims processing tools, and external portals; single-factor with device compliance for internal workstation logins. Different user populations get different policies without building separate authentication flows

Session Management Across EBS Modules

One of the trickiest aspects of EBS SSO is session management. EBS modules (Financials, HR, Procurement) may run as separate Apache/OC4J instances, each with its own session cookie. Key considerations:

• Session propagation: OAM's WebGate must be deployed on every EBS web tier to intercept requests and validate the SSO session consistently across modules
• Timeout alignment: Azure AD session lifetime, OAM session lifetime, and EBS session lifetime must be aligned. Mismatched timeouts create scenarios where users are authenticated to Azure AD but get session-expired errors in EBS
• Single logout: Implement SLO (Single Logout) so that logging out of any system terminates sessions across all systems. Without SLO, orphaned sessions become a security risk
• Form-based authentication fallback: Maintain a fallback authentication path for break-glass scenarios. If the IdP is unavailable, administrators must still be able to access EBS

Security Considerations

Before enabling SSO, conduct a full user account audit across all connected systems. Enterprises typically discover:

• Orphaned accounts: EBS accounts with no corresponding AD account (from employee departures never cleaned up). Expect to find 5–10% of accounts in this state
• Privilege drift: Accounts with EBS responsibilities inconsistent with current job roles — accumulated over years of role changes without proper deprovisioning
• Shared accounts: Service accounts or shared logins that cannot be attributed to individuals. These must be converted to named accounts or explicitly exempted from SSO with compensating controls

Remediate all anomalies before SSO cutover. Then implement automated provisioning and deprovisioning through Microsoft Identity Manager or Azure AD lifecycle workflows to prevent recurrence.

Rollout Strategy

Never enable SSO for all users simultaneously. A phased rollout is essential, especially in regulated environments:

1. Wave 1 — IT and Finance (5–10% of users): Technical pilot group. Run for 4 weeks minimum. Monitor helpdesk tickets, authentication logs, and session errors intensively
2. Wave 2 — Headquarters (40–50% of users): Largest cohort. Run legacy authentication in parallel for 2 weeks as a fallback. This wave validates scale
3. Wave 3 — Regional and Field users (remaining): Remote rollout with self-service onboarding materials. These users often authenticate infrequently, so edge cases surface here

Plan for a 60-day stabilization period after full rollout before decommissioning legacy authentication. Track password-related helpdesk tickets as your primary success metric — a well-executed SSO integration should reduce them by 70–80% within the first two months.