SSO and MFA for Oracle E-Business Suite with Entra ID, OCI IAM and the EBS Asserter, Part 4: Entra ID Federation, SCIM Provisioning and Beyond EBS

Up to Part 3, users authenticated against the OCI IAM domain itself. That was fine for the PoC, but the goal was always one corporate identity, and that identity lives in Entra ID.

The federation is standard SAML 2.0. On the OCI side, the identity domain exposes its metadata at:

https://idcs-<guid>.identity.oraclecloud.com/fed/v1/metadata

That metadata is imported into a new enterprise application in Entra ID; in return, the Entra ID federation metadata is registered as an external SAML identity provider in the OCI IAM domain. Oracle publishes a step-by-step tutorial for this pairing; the process took us well under an hour.

The finishing touch is the identity provider policy in the IAM domain: instead of showing a login page with a "sign in with Microsoft" button, the default rule sends every user straight to Entra ID. Combined with the Asserter redirect chain from Part 1, this completes the picture promised there: the user clicks the EBS link, sees the familiar Microsoft login (often already satisfied by the Windows session), and never encounters an OCI IAM screen.

A deliberate design decision: the OCI IAM domain has no factors of its own enabled. MFA is enforced entirely through Entra ID Conditional Access, with the same policies, the same authenticator apps, and the same exemption processes the organization already runs for Microsoft 365 and everything else.

The alternative, enabling MFA in OCI IAM as well, would mean two policy engines, two enrollment flows and double prompts for users. Resist it. If the corporate security team tightens the Conditional Access rules tomorrow, E-Business Suite inherits the change automatically, with zero configuration on the Oracle side.

Matching by e-mail address only works if the user actually exists in the IAM domain. Creating users manually was acceptable for the PoC; for production, the Entra ID enterprise application provisions them via SCIM: assigned users and groups are created in the IAM domain automatically, attribute changes are synchronized on Entra ID's provisioning cycle.

Two lessons from our rollout:

Mandatory attributes bite silently. OCI IAM requires a last name on every user record. Regular employees always have one, but technical accounts and external users maintained sparsely in Entra ID sometimes don't. Those records are simply rejected by SCIM, and the user is missing on the Oracle side until someone completes first and last name in Entra ID. Check your directory hygiene before wondering why individual logins fail. You definitely will want to check the entra provisioning log for the first weeks after go live tightly.

Deprovisioning is a cost topic, not just a security topic. Remember from Part 1 that the Oracle Apps Premium domain is billed per user and month. Here is the trap: when an employee leaves and their Entra ID account is disabled, they can no longer log in anywhere, so from a security perspective everything looks fine. But a disabled Entra ID user may still exist as a user object in the OCI IAM domain, and every user object in the domain is a billed user. The SCIM provisioning must therefore be configured to actually remove (or at least deactive in OCI) leavers from the IAM domain, not just block them. Review the deprovisioning settings of the enterprise application and reconcile the IAM user count against your active workforce once in a while; each forgotten leaver is a small but perfectly avoidable monthly fee.

One behavior to brief your users on: logging out of E-Business Suite terminates the whole chain. The Asserter propagates the logout to the OCI IAM session, which propagates it to Entra ID. A user who logs out of EBS and then opens Outlook on the web will re-authenticate.

We looked into softening this and decided against it: a shared corporate identity means a shared session, and half-terminated sessions are worse for security than a re-login is for convenience. Not a bug, a feature, but one worth a line in the rollout announcement.

A question every EBS project sponsor asks: what breaks? Here is our tested answer, and it is short:

• OA Framework (self service): works, no changes

• Oracle Forms: works, with ebs.renew.session=true (Part 2)

• WebADIworks: no re-login thanks to whitelist.urls (Part 2)

• Proxy authentication (act on behalf of): works, no changes

• APEX integrated with EBS authentication: works, no changes

• iSupplier for external partners: intentionally kept on local login (Part 3)

The most pleasant surprise in that table is the integrated APEX line. Applications that authenticate through the EBS session (the classic pattern of launching APEX from an EBS function with the ICX session propagated) simply keep working, because from their perspective nothing changed: there is still a valid EBS session, it just came into existence via Entra ID instead of a password form.

Which brings us to the systems around E-Business Suite. Besides the integrated APEX applications, we run several standalone APEX applications whose custom authentication schemes validate the user's password against EBS over a database link. That pattern now has an expiration date, for two reasons: it is exactly the kind of password handling this project set out to eliminate, and once users no longer have an EBS password (SSO login type SSO, Part 3), there is nothing left to validate.

One option that suggests itself, and that we ruled out, is reusing the IAM domain as an OpenID Connect provider for these applications. The Oracle Apps Premium domain type is licensed specifically for Oracle Apps scenarios like the EBS Asserter; putting arbitrary custom applications behind it is not covered (or only covered for up to 10 applications), and upgrading the domain to the full Premium tier just for a handful of APEX portals would defeat the cost argument from Part 1.

Instead, the standalone APEX applications connect directly to Entra ID: each application is registered in Entra ID, and APEX authenticates against it with an OpenID Connect social sign-in scheme. Users get the exact same Microsoft login and MFA they already know from EBS, Conditional Access applies unchanged, and the IAM domain stays out of the picture entirely, along with its per-user billing. The DB link password check is deleted, not migrated.

The larger pattern still holds: one corporate identity in Entra ID, MFA policy in one place. E-Business Suite reaches it through the Asserter and the Apps Premium domain; everything else goes straight to Microsoft.

After several months in production, the balance sheet:

• Users log in to E-Business Suite with their Microsoft account and MFA; no EBS passwords, no separate lifecycle.

• Operations run one small Docker host with one lightweight container per environment; clones heal themselves (Part 3).

• Costs amount to the per-user Oracle Apps Premium subscription, kept accurate by SCIM deprovisioning. No WebLogic license, no additional infrastructure of note.

• Compatibility is a non-issue with the right bridge.properties; the table above took more time to verify than to fix.

If you are still running AppsLocalLogin.jsp in 2026, the EBS Asserter is a smaller project than you probably think, and most of what makes it feel large (the clone handling, the console gaps in the documentation, the Forms timeout, the SCIM billing trap) is now written down in these four parts.