SSOGEN / Oracle EBS ADFS SSO with Microsoft AD FS

Integration

Oracle EBS ADFS SSO with Microsoft AD FS

SSOGEN is one relying party in AD FS, on your servers or in Azure, and people land in EBS as themselves after signing in.

Microsoft and Oracle EBS logos for Oracle EBS single sign-on with Microsoft AD FS, on premises or in Azure
To the person it looks like any other application behind AD FS.

Oracle HTTP Server with the SSOGEN Web Agent sends the browser to a sign-in source, then opens EBS as the EBS user.

Two steps: run the SSOGEN tool on the web tier, then finish the sign-on setting in PeopleSoft, JD Edwards or EBS.

How a sign-in goes

  1. A person opens https://ebs.acme.example/OA_HTML/AppsLogin.
  2. The SSOGEN Web Agent in the Oracle HTTP Server of the EBS web tier sends the browser to the sign-in page of SSOGEN (or, in the direct path below, straight to AD FS).
  3. SSOGEN sends the browser to AD FS. AD FS signs the person in with Windows integrated authentication or its own form, depending on how your farm is set up.
  4. The browser comes back, the agent hands EBS the signed-in user name, and EBS opens the home page with that user’s responsibilities.

The experience matches any other application behind AD FS. SSOGEN is one more relying party trust; the person does not see it.

No Oracle Access Manager, Oracle Internet Directory or Oracle Unified Directory is involved. The SSOGEN tool sets the EBS single sign-on profile options itself and leaves APPS_SSO_LDAP_SYNC at No.

What you need

  • A working AD FS farm and an administrator on it.
  • Oracle E-Business Suite 12.2, or 12.1, and the SSOGEN integration tool for it.
  • An SSOGEN tenant, here https://acme.ssogen.ai (or the direct path below, which needs only a license key).

Path A: through SSOGEN

On the AD FS side

Add SSOGEN as a relying party trust, with the values SSOGEN shows you:

AD FS asks for Value
Relying party SAML 2.0 SSO service URL https://acme.ssogen.ai/saml/sp/adfs/acs
Relying party identifier https://acme.ssogen.ai/saml/sp/adfs
Claim rule 1, Send LDAP Attributes as Claims E-Mail-Addresses to E-Mail Address, Display-Name to Name, User-Principal-Name to UPN
Claim rule 2, Transform an Incoming Claim UPN to Name ID, format Unspecified, pass through all claim values
Access control policy Permit the group that may use EBS

Every click, the metadata address (https://fs.acme.example/FederationMetadata/2007-06/FederationMetadata.xml) and the AD FS event log errors are on AD FS as the sign-in source.

On the SSOGEN side

Create the AD FS identity provider, validate, test and activate it, and allow it in the policy that covers EBS (Add a SAML identity provider in SSOGEN). Choose Anyone this provider vouches for so each person gets an SSOGEN account at the first sign-in.

On the EBS side

  1. In the SSOGEN console, register EBS as a Web Agent application with the Client URL https://ebs.acme.example. Set Identify the person by to the value that equals the person’s EBS user name. John Doe’s EBS user JDOE needs a value that reads jdoe or JDOE: the agent sends it in capitals and never cuts off a domain part, so a UPN of john.doe@acme.example would not match.
  2. Run the tool on each web node and finish the setting in EBS exactly as on the Oracle EBS single sign-on page. Those steps are not repeated here.
  3. Create the EBS users. EBS links the SSO account to the EBS user at the first sign-in.

Keep the local login for SYSADMIN: https://ebs.acme.example/OA_HTML/AppsLocalLogin.jsp keeps working with the EBS password.

Path B: straight to AD FS, no SSOGEN in between

The same tool connects the EBS web tier to AD FS directly (-mode=saml, with a license key from SSOGEN). Save the federation metadata as ebs-internal-idp.xml in the ssogen folder of the web tier, or put its address in the configuration as SSOGENSamlIdpMetadataURL, then run the tool as described on the EBS page.

Create the relying party trust in AD FS with the two values the tool prints:

AD FS asks for Value
Relying party identifier https://ebs.acme.example
Relying party SAML 2.0 SSO service URL https://ebs.acme.example/ssogen/acs
Name ID The EBS user name. A rule that sends the account name (SAM-Account-Name) as Name ID gives jdoe, which EBS reads as JDOE.

The assertion must be signed, which AD FS does by default. If AD FS publishes a logout address for the trust, set it to https://ebs.acme.example/ssogen/saml/slo.

If it does not work

Symptom What to do
AD FS error page, event MSIS7007 in the AD FS Admin log The identifier on the trust differs from the one the service provider sends. Correct it on the trust.
Event 321 (MSIS7070), name ID policy not satisfied Add claim rule 2 above, or make SSOGEN ask for the format the rule issues.
Sign-in works, EBS does not know the user The name sent is not an EBS user name. Change Identify the person by in SSOGEN, or the Name ID rule in AD FS.
Sign-ins stop weeks later AD FS rolled its token-signing certificate. Fetch the metadata again while AD FS publishes both certificates.