Setup Azure AD as a IdP in WSO Access (SAML)

For enterprises who has already standardised their SSO portal using Azure AD but want to enjoy benefits from WSO Access such as device compliance and Mobile SSO, they can make AAD a IdP for Access.

This is a step by step guide on how to get it setup.

WSO Access SP Metadata

On your Access console -> Catalog -> Web Apps -> Settings -> SAML Metadata -> Click to get the SP metadata XML file downloaded.

AAD Enterprise Application

On your AAD console -> Enterprise -> Click on New Application -> Click Create your own application

Name it whatever you like and choose “Integrate any other application you don’t find in the gallery”

Create and go to SSO section

Go to SAML

Upload the SP metadata file from WSO Access console by clicking the ”Upload metadata file” on the menu bar on Azure console:

Edit the Basic SAML Configuration like following

Save and go back to the previous screen.

Edit User Attributes & Claims

Have all the additional claims removed. Keep the Required claim entry.

Edit SAML Signing Certificate

Assign the newly created enterprise app to one or multiple user accounts.

Go to WSO Access console to create Azure AD as a 3rd party IdP

Go to Identity & Access Management -> Identity Providers -> Click Add Identity Provider -> Create SAML IDP

Name whatever you like such as Azure AD.

Open the AAD metadata file with a text editor. Copy and paste the content into the metadata text box. Click “Process Metadata”

Under Name ID format mapping, add two lines.

Add a mapping for “urn:oasis:names:tc:1.1:nameid-format:unspecified” and map it to “userPrincipalName”.

Add a mapping for “urn:oasis:names:tc:1.1:nameid-format:emailAddress” and map it to “userPrincipalName”.

Under Users, select the user store where the users exist.

Under Network, select “All Ranges”

Under Authentication Methods, provide a name such as “AzureADPassword”

Under SAML Context, select “urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport”

Enable Single Sign-Out Configuration

Test it out

Now you can edit your Policy rule

Before you give it a test to verify the setup, please make sure you have Principal Name setup properly for your testing user accounts.

The Access user accounts are synchronised from my UEM. For Azure AD login, I populate Principal Name with email address.

To make authentication control more secure, I have AAD 2FA turned on. On Azure admin console, you can turn on 2FA for your testing account(s).

Now user logins to Access will get federated to Azure login screen and prompted for 2FA. Microsoft Authenticator app is required to get approve a login request.

Want to do more conditional access? Azure can provide location based conditional access with

1. GPS

2. IP address

All you have to do is to define your own named locations by selecting the countries you want to block or allow.

Here are named locations for Hong Kong. One is GPS based. The other is IP based.

You can now use your named locations in your enterprise application conditional access rules.

This is demo video when GPS conditional access is on. Please note that the GPS we are talking about here is the Authenticator GPS, not the connecting PC GPS. Azure will prompt you to use Authentication app to have login request approved. The app will provide the GPS to Azure.

This is demo video of IP based location conditional access. It is determined by the connecting PC IP. It is possible to use both IP based and GPS location together for higher authentication control.

When you have your conditional access rules setup, you can use the what if tool to check if it works out as you expect.

For actual sign-in, you can check the Sign-in logs to see if a sign-in is successful with details such as where a sign-in is from and IP address.