About Configuring SSO Between Azure AD and Oracle Access Manager for Oracle E-Business Suite

Now, you will complete the steps necessary to register a new federated service provider in Azure AD, register a new identity provider (E-Business Suite) in Oracle Access Manager, and make any required configuration changes to accomplish federated SSO authentication with Azure AD and E-Business Suite using Oracle Access Manager.

Understand the Azure AD and E-Business Suite Federation Flow

Before proceeding with configuration, you should understand the Azure AD and E-Business Suite Federation Flow.

Description of the illustration ebiz-federation-flow.png

In this scenario, users access E-Business Suite with credentials stored in Azure AD. This access is achieved through a federated authentication setup with the SAML 2.0 protocol, in which Azure AD is the identity provider (IDP) and E-Business Suite is the service provider (SP). Because Oracle Access Manager is deployed in front of E-Business Suite for SSO, it’s also the component that provides the federation capabilities to E-Business Suite. This section provides the required steps for implementing identity federation between Azure AD and Oracle Access Manager.

Note that we are mostly interested in a federation flow that’s initiated on access to an E-Business Suite-protected endpoint. In SAML protocol terms, this is known as a service-provider-initiated (SP-initiated) flow, and is illustrated in Figure 2. In that flow, Oracle Access Manager (OAM) Server detects access to an E-Business Suite-protected resource, creates an authentication request (SAMLRequest), and redirects the browser to Azure AD for authentication. Azure AD challenges the user for credentials, validates them, creates a SAMLResponse as a response to the received authentication request, and sends it to Oracle Access Manager. In turn, Oracle Access Manager validates the assertion and asserts the user identification information embedded in the assertion, granting access to the protected resource.

Note that the configuration presented in this section also accounts for identity-provider-initiated (IdP-initiated) flow, where a request is initially made to Azure AD SAML intersite URL, which in turn sends an unsolicited SAMLResponse to the Oracle Access Manager Server.

SP-initiated single logout (where the logout flow is initiated by E-Business Suite) is also supported by the presented configuration. At the time this paper was initially published, IDP-initiated single logout (where the logout flow is initiated by the Azure portal) is not supported. See the “Known Issue” section at the end of this document for details.

Configure Azure AD as the Identity Provider

First, you need to configure Azure AD as the Identity Provider.

1. Sign in to the Azure portal as a Domain Administrator
2. In the far-left navigation pane, click Azure Active Directory.
3. In the Azure Active Directory pane, click Enterprise applications.
4. Click New application.
5. In the Add from Gallery section, type Oracle Access Manager for EBS in the search box, select Oracle Access Manager for EBS from the resulting applications, and then click Add.
6. To configure Oracle Access Manager as a service provider for the application, click Single sign-on.
7. Select SAML as the single-sign-on method.

   The Set up Single Sign-On with SAML page appears. Here, you will enter the integration details in the following steps.

   Some of the values that you need to enter come from Oracle Access Manager's SAML metadata. To get the metadata, go to http(s)://<oam_hostname>:<port>/oamfed/sp/metadata. The output is XML data, some of which you need in the next steps.

8. In the Basic SAML Configuration area of the Set up Single Sign-On with SAML page, provide values for Identifier (Entity ID), Reply URL (Assertion Consumer Service URL), and Logout Url.
   • Identifier (Entity ID) corresponds to the entityID attribute of the EntityDescriptor element in the SAML metadata. At runtime, Azure AD adds the value to the Audience element of the SAML assertion, indicating the audience that is the expected destination of the assertion. Find the following value in the Oracle Access Manager metadata and enter that value:

     <md:EntityDescriptor
     …
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      ID="id-4TfauRP-ZeWyweEXkrqcBA0w0nRhe64hOPfnY2YR"
      cacheDuration="P30DT0H0M0S"
      entityID="http://myoamserver.mycompany.com:14100/oam/fed"
      validUntil="2029-03-19T21:13:40Z">
     …

   • Reply URL (Assertion Consumer Service URL) corresponds to the Location attribute of the AssertionConsumerService element in the SAML metadata. Be sure to pick the Location attribute that is relative to the HTTP_POST binding, as shown in the following example. The Reply URL is the SAML service endpoint in the federation partner that is expected to process the assertion.

     <md:AssertionConsumerService
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     Location="https://myoamserver.mycompany.com/oam/server/fed/sp/sso"
     index="1"/>

   • The Logout Url corresponds to Oracle Access Manager’s SAML logout endpoint. That value corresponds to the Location attribute of the SingleLogoutService element in Oracle Access Manager’s SAML metadata. This value is used exclusively in IdP-initiated logout flow.

     <md:SingleLogoutService
     Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     Location="https://myoamserver.mycompany.com/oamfed/sp/samlv20"
     ResponseLocation="https://myoamserver.mycompany.com/oamfed/sp/samlv20"
     />
     

   Note:

   The Sign on URL and Relay State properties aren’t relevant to this scenario, so you can skip them.
9. In the User Attributes and Claims area, configure the user attributes that will be inserted in the SAML assertion and sent to Oracle Access Manager. For this scenario, it suffices to send some form of unique user identification.
   Leave the values as the default for the Name identifier value: user.userprincipalname [nameid-format:emailAddress] because userprincipalname is a unique attribute within Azure AD. The implication of such configuration is the need to import the userprincipalname value into the user entry in Oracle Access Manager's identity store (the LDAP server store).
10. . In the SAML Signing Certificate area, click the Download link next to Federation Metadata XML, and save the file on your computer. You will use it later when configuring Oracle Access Manager as the service provider.

Assign Users to the Application

Next, assign users to the application. After Azure AD receives an authentication request from the application, only those users that you assign to the application can log in.

1. From the Azure AD application that you created in the previous section, click Users and groups, and then click Add user.
2. Select the Users and groups: None Selected option, and perform the following steps:
   1. In the Select member or invite an external user search box, enter the name of a user, and then press Enter.
   2. Select the user and then click Select to add the user.
   3. Click Assign.
   4. To add more users or groups, repeat these steps.
3. To prevent users from viewing this enterprise application that is meant only for SSO configuration, click Properties, change value of Visible to users to No, and click Save.

Create a New Identity Provider for Azure AD

Next, create a new identity provider for Azure AD. This step assumes that Oracle Access Manager federation services have been enabled.

1. Sign to the Oracle Access Manager console as an Administrator
2. Click the Federation tab at the top of the console.
3. In the Federation area of the Launch Pad tab, click Service Provider Management.
4. On the Service Provider Administration tab, click Create Identity Provider Partner.
5. In the General area, enter a name for the Identity Provider partner and select both Enable Partner and Default Identity Provider Partner. Go to the next step before saving.
6. . In the Service Information area:
   1. Select SAML2.0 as the protocol.
   2. Select Load from provider metadata.
   3. Click Browse (for Windows) or Choose File (for Mac) and select the Azure AD SAML metadata file that you saved previously.
   4. Go to the next step before saving.
7. In the Mapping Options area:
   1. Select the User Identity Store option that will be used as the Oracle Access Manager LDAP identity store that is checked for E-Business Suite users. Typically, this is already configured as the Oracle Access Manager identity store.
   2. Leave User Search Base DN blank. The search base is automatically picked from the identity store configuration.
   3. Select Map assertion Name ID to User ID Store attribute and enter mail in the text box.

   Note:

   This configuration defines the user mapping between Azure AD and Oracle Access Manager. Oracle Access Manager will take the value of the NameID element in the incoming SAML assertion and try to look up that value against the mail attribute across all user entries in the configured identity store. Therefore, it’s imperative that the Azure AD user principal name (in the Azure AD configuration shown previously) is synchronized with the mail attribute in Oracle Access Manager's identity store.
8. Click Save to save the identity provider partner.
9. After the partner is saved, come back to the Advanced area at the bottom of the tab. Ensure that the options are configured as follows:
   • Enable global logout is selected.
   • HTTP POST SSO Response Binding is selected.
     This is an instruction that Oracle Access Manager sends in the authentication request telling Azure AD how it should transmit the SAML assertion back. If you inspect the authentication request that Oracle Access Manager sends, you would see something like the following example. Note the bold ProtocolBinding attribute of AuthnRequest element in the example.

     <?xml version="1.0"?>
     <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
     xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
     xmlns:enc="http://www.w3.org/2001/04/xmlenc#"
     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
     xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     Destination="https://login.microsoftonline.com/4e39517e-7ef9-45a7-
     9751-6ef6f2d43429/saml2" ID="id-y5nmx61xB8QWXtDmYWcH7rPYs5zXtV-fcKRyyM9" IssueInstant="2019-04-23T17:01:25Z"
     ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
     Version="2.0">
     <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameidformat:entity">http://myoamserver.mycompany.com:14100/oam/fed</saml:Is
     suer>
     <dsig:Signature>
     <dsig:SignedInfo>
     <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xmlexc-c14n#"/>
     <dsig:SignatureMethod
     Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
     <dsig:Reference URI="#id-y5nmx61xB8QWXtDmYWcH7rPYs5zXtV-fcKRy-yM9">
     <dsig:Transforms>
     <dsig:Transform
     Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
     <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
     </dsig:Transforms>
     <dsig:DigestMethod
     Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <dsig:DigestValue>pa00UWdqfywm4Qb59HioA6BhD18=</dsig:DigestValue>
     </dsig:Reference>
     </dsig:SignedInfo>
     <dsig:SignatureValue>X4eZRyFD6sznA0g3BJebU2c6ftunG2UvwbMptO+10wFky0aAL
     nnr0Na+5fF83U4Ut99OvAIZ41K3YMNaR4A8zr37SSlBrb72X7CTtxjh2mAphWDRPmkJx4v
     S0HACzZh0MHimdwq+qVXuFRbSLBE+9XNSGWJzGAh//WqGBlNrKnw=</dsig:SignatureV
     alue>
     </dsig:Signature>
     </samlp:AuthnRequest>

   • Enable HTTP Basic Authentication (SSO artifact binding) is not selected.

     This setting asks Azure AD to send the assertion via an HTTP POST request. When receiving a request like this, identity providers typically create an HTML form with the assertion as a hidden form element that is automatically posted to the service provider's Assertion Consumer Service (ACS).

10. In the General area, click the Create Authentication Scheme and Module button.
    An authentication scheme and module are created with the partner name. The only configuration left is attaching the authentication scheme to the E-Business Suite resources that require Azure AD credentials for authentication, which you will do in the next section.
11. You can check the authentication module that was created by following these steps:
    1. Click the Application Security tab at the top of the console.
    2. Under Plug-ins, select Authentication Modules, click Search, and find your federation module.
    3. Select the module, and then click the Steps tab.
    4. Note that the value in the FedSSOIdP property is the identity provider partner

Associate the E-Business Suite Resources with the Authentication Scheme

The final configuration step is to associate the E-Business Suite Resources with the Authentication Scheme. Perform these steps while logged in to the Oracle Access Manager console as an Administrator

1. At the top of the console, click Application Security.
2. Under Access Manager, select Application Domain, click Search, and select the application domain that was created during E-Business Suite script execution for the integration that would have registered the E-Business Suite WebGate.
3. Click the Authentication Policies tab, and then click Protected Resources Policy.
   Change the Authentication Scheme by changing the previously created authentication scheme with the new federation authentication scheme. This is how Oracle Access Manager ties a protected resource to an identity provider
4. Click Apply to save the change.