Table of Contents

Tutorial: Configure Datawiza for Azure AD SSO and MFA to Oracle JDE

7 minutes read
Bald caucasian programmer in glasses is sitting behind the desk, in front of two black screens, laptop and monitor, looking closely, analysing code lines. He's very attentive and focused.
Table of Contents

This tutorial shows how to enable Azure Active Directory (Azure AD) SSO for an Oracle JD Edwards (JDE) application via Datawiza. Datawiza works as a super lightweight reverse proxy integrating any identity provider, like Azure AD, Okta, Ping, Google, AWS SSO, to enable SSO, MFA and granular access control for any applications.

The benefits of integrating applications with Azure AD via Datawiza includes:

Scenario description

This scenario study focuses on solving the problem when modern identity providers integrate with the classic Oracle JDE application. We could accomplish the integration because JDE supports HTTP Authorization Headers.

In many cases, legacy applications have great difficulty integrating modern SSO, mainly due to the absence of modern protocol support.

The Datawiza Solution effectively reduces the cost of integration, overcomes the gap, and significantly improves application security.

Architecture

The solution for this scenario contains the following components:

  • Azure AD: Microsoft’s cloud-based identity and access management service, which helps users sign in and access external and internal resources.
  • Oracle JDE Application: The legacy application to be protected by Azure AD.
  • Datawiza Access Broker (DAB): A super lightweight container-based reverse-proxy implements OIDC/OAuth or SAML for user sign-on flow and transparently passes identity to applications through HTTP headers.
  • Datawiza Cloud Management Console (DCMC): A centralized management console that manages DAB. DCMC provides UI and RESTful APIs for administrators to manage the configurations of DAB and its granular access control policies.

 

Both SP initiated flow and IdP initiated flow are supported by the architecture discussed here. Below we will use SP initiated flow for demonstration purposes.

AzureAD Login

Steps Description

  1. The user accesses the application URL, which hits the DAB.
  2. The DAB checks the user’s authentication state. If it doesn’t receive a session token, or the supplied session token is invalid, then it redirects the user to Azure AD (OIDC IdP in this example, you can use SAML IdP as well).
  3. Azure AD pre-authenticates user and applies any enforced Conditional Access policies, and then the user is redirected back to DAB and SSO is performed using issued OIDC token.
  4. The DAB evaluates its own access policies and generates attribute values to be included in HTTP headers and forwarded to the application. During this step, the DAB may call out to the identity provider to retrieve the information needed to set the header values correctly. The DAB then sets the header values and sends the request to the application.
  5. The user is now authenticated and has access to the application.

Prerequisites

Prior Datawiza Access Broker experience isn’t necessary, but you need:

  • An Azure subscription. If you don’t have a subscription, you can get a trial account
  • An Azure AD tenant that’s linked to your Azure subscription
  • Docker and docker-compose are required to run DAB
  • User identities synchronized from an on-premises directory to Azure AD or created directly within Azure AD and flowed back to your on-premises directory
  • An account with Azure AD application admin permissions
  • (Optional) An SSL Web certificate for publishing services over HTTPS, or use default Datawiza self-signed certs while testing
  • An existing Oracle JDE environment

Getting started with Datawiza

To integrate JDE with Azure AD, login to Datawiza Cloud Management Console (DCMC).

Welcome to the DCMC homepage! Let’s get started:

Click the orange “Getting started” button, which will guide you through the configuration steps.

  1. Specify a Name and a Description, and click Next.

 

View of the deployment name website page

Add Application

Configure your application with the following values:

  • Platform: Since JDE is a web application, select WEB
  • App Name: The name of your application. Put a meaningful name here. I use the Oracle JDE App.
  • Public Domain: The external facing URL of the application. For example https://jde-external.example.com. You can use localhost DNS for testing purposes. I use https://jde.datawiza.net
  • Listen Port: This is the port that the Datawiza Access Broker listens on. For simplicity, you can use the same port as the one in Public Domain above if you are not deploying the Datawiza Access Broker behind a Load Balancer.
  • Upstream Servers: the URL and port combination of the Oracle JD Edwards Implementation is being protected. Mine is https://10.0.0.122:8080.

 

Select Next.

IdP Configuration

DCMC provides an innovative one-click integration to help you complete the Azure AD configuration. This is the easiest way to install Azure AD. DCMC will automatically complete the configuration for you. With one-click integration, you no longer have to fill out the tedious configuration on Azure AD or copy the configuration to DCMC. DCMC calls the Graph API to do all the work for you. In this way, management costs are reduced and configuration errors are less likely to happen, ensuring smooth configuration to a large extent.

Website page displaying configure page

Note Down a Docker-Compose File

Once clicking on the Create button, the basic configuration on the management console is finished. You will see the final step of the guide, which presents you with a page showing the simple steps to deploy Datawiza Access Broker (DAB) with your application. Note down the docker-compose file of your deployment. The file includes the image of the Datawiza Access Broker (DAB) and a pair of PROVISIONING_KEY and PROVISIONING_SECRET, which are used by DAB to pull the latest configuration and policies from DCMC.

the image of the Datawiza Access Broker (DAB) and a pair of PROVISIONING_KEY and PROVISIONING_SECRET

Single Sign-On & HTTP Headers

The DAB gets user attributes from IdP and passes them to the upstream application via header or cookie.

In order to let the Oracle JDE application recognize the user correctly, there is one more step to configure, which instructs DAB to pass the values from the identity provider to the application under what name through HTTP header.

Such configuration will be done in the Applications tab on the left panel and go to Attribute Pass sub-tab.

For Oracle JDE, please refer to the screenshot below to configure the attribute pass.

  • Field: email
  • Expected: JDE_SSO_UID
  • Type: HEADER

Important: This configuration will use Azure AD’s user principal name as login username used by JDE, if you want to use another user identity, you can go to the Mappings tab to change it.

Image of AzureAD user principal name

SSL Configuration

  1. Certificate Configuration: Select Advanced tab in your application page:
Image of SSL Configuration

2. Enable SSL and select a proper Cert Type: 

3. We provide a self-signed certificate for localhost. It can be used for testing purposes

4. Optionally, you can choose to upload your own certificate from a file: 

Certificate

5. Click Save.

Enable Single Sign-On in JD Edwards EnterpriseOne console

To enable single sign-on in the JD Edwards environment:

1. Sign in to the JD Edwards EnterpriseOne Server Manager Management console as an administrator.

2. In Select Instance, select EnterpriseOne HTML Server.

Oracle JD Edwards

3. In the Configuration tile, select View as Advanced, and then click Security

Oracle Configuration

4. Select the Enable Oracle Access Manager check box, and then enter /datawiza/ab-logout in the Oracle Access Manager Sign-Off URL field.

In the Security Server Configuration section, click Apply.

Security Server Configuration section,

5. Click Stop and confirm that you want to stop the managed instance.
If a message indicates that the web server configuration (jas.ini) is out-of-date, click Synchronize Configuration.

Synchronize Console

6. Click Start and confirm that you want to start the managed instance.

Test a JD Edwards based application

Testing a JD Edwards application involves validating application headers, validating policy and overall testing. Testing using header and policy simulation allows you to validate header fields and policy execution if required.

Complete testing should always be performed to validate that the application is behaving as expected for all URIs.

The easiest way to confirm everything is correct is when you access the JDE application, it will ask you to use an Azure Ad account to login, after checking your Azure AD credentials you should see the JDE properly.

Here is a video clip showing the user experience after a successful integration between Azure AD and Oracle JDE via Datawiza.

Summary

In this article, you learned how to:

  • Configure and Deploy the Datawiza Access Broker
  • Integrate the Datawiza Access Broker with Oracle JDE
  • Enable Azure AD SSO login for Oracle JDE

Written by the Datawiza team — hope you enjoyed! Join us if you have any questions or need any help on our Discord server. 

We're exhibiting at Gartner Identity & Access Management Summit, Aug 22-24, 2022! Visit us at booth 110 and say hi! 👋Learn More
+