Configure Microsoft Azure AD as OpenId Provider

Contents

• Adding IFS Applications to Microsoft Azure AD
• IFS Admin Console configurations
• Mapping the Azure AD user to Foundation1 user
• Configure Secure LDAP (LDAPS) for Azure AD.

Related documents

• Configuring Touch Apps for OpenID Connect

Adding IFS Applications to Microsoft Azure AD

• When Microsoft Azure AD is used as the Open ID Provider the applications that need to be authenticated using Azure AD have to be registered and configured  in Microsoft Azure AD.

Aurena Default Application

To authenticate user logins for Aurena client a new Web application / API needs to be added in Azure App registrations.

• Login to Microsoft Azure (https://portal.azure.com) and go to Azure Active Directory. Select "App Registrations" and click "New application registration".

•  Give the application a name. Application type should be "Web app / API". Enter the Application URL as the Sign-on URL ( e.g.: https://<app_server:port> ). Press "Create" button.

• Once created the application will be added to the list of already available applications.
•  Select the newly created application from the list. The following view will be displayed. Note the Application ID. This would be used later when the IFS Application configuration is completed using IFS Admin Console.

• Click on "Settings" to get the application configuration blade opened. Select "Reply URLs" and add The following Reply URLs for Aurena application.

https://<fully_qualified_domain_name_of_the_app_server:port>main/ifsapplications/projection/oauth2/callback/
https://<fully_qualified_domain_name_of_the_app_server:port>/main/ifsapplications/web/oauth2/callback/

e:g: https://lkppdeTest888.corpnet.ifsworld.com:58080/main/ifsapplications/projection/oauth2/callback/
https://lkppdeTest888.corpnet.ifsworld.com:58080/main/ifsapplications/web/oauth2/callback/

• From the middle blade Select "Keys".

• In the description field give a name for the keys. Give the desired validity period of the keys. Then press the "Save" button. The keys will be generated and the "VALUE" field will display the generated secret key. Copy this value and store it somewhere. Once you leave this blade this key will not be accessible.

• This value is required later when you finish configuring Security for IFS Applications using the IFS Admin console.
• The Web application is created with "Enabled for users to sign-in?" option turned to "Yes". This option is required to be "Yes" for the users to be able to login to the application. To check this select "Azure Active Directory", "Enterprise Applications". Search for the Web application created. Click on "Properties". "Enabled for users to sign-in?" must be set to "Yes".

• All the users who are registered in the Azure Active Directory will be able to access the application. The actions that the user can perform once logged into the application will be controlled using the Permisson Sets and User Grants >>.

Aurena B2B Application

• To authenticate user login for Aurena B2B Client add a new "Web app / API" and follow the steps as given above for Aurena Web Client.
• The following redirect URIs must be added:

https://<fully_qualified_domain_name_of_the_app_server:port>/b2b/ifsapplications/projection/oauth2/callback/
https://<fully_qualified_domain_name_of_the_app_server:port>/b2b/ifsapplications/web/oauth2/callback/

e.g.: https://lkppdeTest888.corpnet.ifsworld.com:58080/b2b/ifsapplications/projection/oauth2/callback
https://lkppdeTest888.corpnet.ifsworld.com:58080/b2b/ifsapplications/web/oauth2/callback

• Take a note of the Application ID and the Secret key of the B2B application as this is required later to finish configuring authentication for IFS Applications using the IFS Admin Console.

IFS Enterprise Explorer and Touch Apps

IFS Enterprise Explorer

• To authenticate user logins for IFS Enterprise Explorer a new Native application has to be added in Azure App registrations. Select "App registrations" in Microsoft Azure portal and select "New application registration"
• Give a name to the application. Select "Native" as the application type. Enter a redirect URI that will be used by the application.

• Select the new application from the application list and complete the configuration.  Select "Redirect URIs" and enter the following redirect URIs.

https://fully_qualified_domain_name_of_the_app_server:port>/int/default/plsqlgateway/oauth2/callback
https://fully_qualified_domain_name_of_the_app_server:port>/int/default/clientgateway/oauth2/callback
https://fully_qualified_domain_name_of_the_app_server:port>/main/default/plsqlgateway/oauth2/callback
https://fully_qualified_domain_name_of_the_app_server:port>/main/default/clientgateway/oauth2/callback

e:g:  https://lkppdeTest888.corpnet.ifsworld.com:58080/int/default/plsqlgateway/oauth2/callback
        https://lkppdeTest888.corpnet.ifsworld.com::58080/int/default/clientgateway/oauth2/callback
        https://lkppdeTest888.corpnet.ifsworld.com::58080/main/default/plsqlgateway/oauth2/callback
        https://lkppdeTest888.corpnet.ifsworld.com:58080/main/default/clientgateway/oauth2/callback

• The native application needs to be granted permission to access the Web application as a resource. To configure this, select "Required permissions" from the middle blade.

• Click the "Add" button. Select "1 Select an API". In the Search bar enter the application ID or the name of the Web API created for the Aurena application previously. Press "Select" to select the correct application. Then tick the "DELEGATED PERMISSIONS" check box to grant the necessary grants. Press "Select" button at the bottom.

• Click "Done" to finish grating access.

• Keep a note of the Application ID given to the Native application. This is required later when authentication configuration is completed using the IFS Admin console.
• Check the "Enabled for users to sign-in?" option to be "Yes" as previously to make sure that users are allowed to login to the Native application..

NOTE: Re-authenitcation behavior: When the user logs in and work in IFS Enterprise Explorer client the client session is refreshed based on the session timeout (Default 10 minutes). When the current session times out the Access Token given by the ADFS server is used to refresh the client session. The Access Token is has a lifetime of about 1 hour by default. Once the Access Token is expired the Refresh token given by the ADFS server is used to obtain a new Access Token. The Azure AD Refresh token has a very long lifetime of about 90 days according to Azure AD documentation. Once the Refresh token is expired it will not be possible to get any new Access Tokens. So re-authentcation will fail and the user will be prompted for credentials.

 Touch Apps Server and Touch Apps

• The Touch apps Server and the Touch Apps are also accessed through the Native application that was created for IFS Enterprise Explorer above. The Redirect URIs for the Touch Apps Server and for each individual Touch App have to be added to the list of Redirect URIs of the Native application.
• Please refer Touch Apps Server Configuration for Redirect URIs for more information

Optional configurations

• If you wish to control the users who has access to the applications you can do this as follows.
• Select "Properties" from the middle blade and scrol down to the bottom. In "User assignment required" selection select "Yes". Now you will have to add the users who should get access to the application.
• 
• Select "Azure Active Directory" from the main menu, then select "Enterprise applications" and select "All applications". Search for the Application for which you want to have user assignments. Click on the application. A blade showing information about the application will appear. Select "Users and groups" from the middle blade. Click on "Add user". 

• Click on "Users" and it will show a another blade where you can search and select users. Search the users by the email address. Select and Assign the user to the application.

IFS Middleware Server Admin Console configurations

After the applications have been added to Azure AD as explained in the above section, some configurations are needed in IFS Middleware Server Admin Console to finish setting up IFS Applications to use Microsoft Azure AD as the Open ID Connect Identity Provider.

Login to IFS Admin Console. Go to "Common > Security".

The DEFAULT tab holds the Open ID provider configuration details for Aurena client and the native applications. Select "Azure Active Directory" as the Identity Provider. Fill in the details as show below.

Parameter	Value
Identity Provider	Azure Active Directory
Identity Provider URL	https://login.microsoftonline.com/<tenant_id>* Note: tenant_id here is the Azure tenant id of your organization. Alternative to the tenant_id you can use the name of the Azure Active Directory with the domaiin (e.g: https://login.microsoftonline.com/ifsdevsys.onmicrosoft.com)
Acceptable Clock Skew (seconds)	This will be the tolerated amount of clock skew when the validity of the token is calculated. E.g.: 60s
Client ID (web)	Application ID taken from Azure AD app registration when Aurena Web application was registered.
Client Secret (web):	Security Key generated when Aurena Web application was registered in Azure AD
Client ID (native):	Application ID taken from Azure AD app registration when IFS Enterprise Explorer and Toch apps were registered as a Native application.

The B2B tab holds the Open ID provider configuration details for B2B client. Select "Azure Active Directory" as the Identity Provider. Fill in the details as show below.

Parameter	Value
Identity Provider	Azure Active Directory
Identity Provider URL	https://login.microsoftonline.com/<tenant_id>* Note: tenant_id here is the Azure tenant id of your organization. Alternative to the tenant_id you can use the name of the Azure Active Directory with the domaiin (e.g: https://login.microsoftonline.com/ifsdevsys.onmicrosoft.com)
Acceptable Clock Skew (seconds)	This will be the tolerated amount of clock skew when the validity of the token is calculated. E.g.: 60s
Client ID (web)	Application ID taken from Azure AD app registration when B2B Web application was registered.
Client Secret (web):	Security Key generated when B2B Web application was registered in Azure AD
Client ID (native):	Leave this blank as there is no native application for B2B.

* How to find the <tenant_id> :
In Azure Portal click on the Azure Active Directory. From the middle blade select "Properties". The properties of the Azure Active Directory will open up in the right most blade. The field "Directory ID" gives the Tenant Id of the the Azure Active Directory.

Mapping the Azure AD user to Foundation1 user

IFS Applications have a user registry of its own in the Oracle Database. These users are know as Foundatoin1 Users. A user authenticated from an External Identity Provider such as Azure AD needs to be mapped to a Foundation1 user for him to get access (authorization) to the application. The Foundation1 users are listed in the table FND_USER_TAB. The DIRECTORY_ID field of this table is used for the mapping between the external user identity and the Foundation1 user identity.

When Azure Active Directory is used as the user repository the email address of the user in the Azure AD (the login id used by the user to login to the Azure AD) must be the value that should be entered as the value for DIRECTORY_ID field. 

If Azure Active Directory is enabled with Domain Services so that the AD is accessible using LDAPS protocol, the Active Directory Synchronization process can be used to synchronize users registered in the Azure AD to Foundation1 users.

Configure Secure LDAP (LDAPS) for Azure AD

To get functions such as Security Check Points to work in an environment where Azure AD is used as the Open Identity Provider it is required to enable Secure LDAP (LDAPS) in the Azure AD. In order to configure LDAPS the Azure AD has to be configured as a Azure AD Domain Service. You need a valid Azure Subscription to be able to do so. Following documentation provided by Microsoft Azure gives  step by step instructions on how to do this:  https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-admin-guide-configure-secure-ldap

Once you have successfully enabled Domain Services in Azure AD you will get a Secure LDAP External IP Address. You can communicate with the Azure Active Directory using the LDAPS protocol and perform functions such as user authentication using LDAPS. Now it is possible to configure the Compatibility AD authenticator to be the Azure AD.

In IFS Admin Console go to Common > Security and select the tab "Integrations and Compatibility".  Fill in the details as given below for Active Directory Authenticator:

More information on Compatibility Active Directory Authenticator can be found here >>.

Links

• How to achieve Single Sign On with Azure Active Directory.