Integrating Okta & Azure AD Domain joined devices
Lately, I have ran into several cases in which Okta is positioned as the IDaaS solution for Cloud applications. This often requires some type of integration with the existing identity services which might be challenging. Especially in a Microsoft oriented landscape using Office 365, Intune and other Azure AD related services.
In this blog post I’ll cover the scenario to integrate Okta and Azure AD by using Intune managed devices based on Azure AD Domain Join. This enables a Single Sign On experience to either Okta or Azure AD federated applications by logging in just once on their own device. Awesome right? Check the video below for the end user experience:
https://www.youtube.com/watch?v=nO4O9Vt5w2o
Keep reading if you want to know more about the details.
The scenario
The scenario includes an Azure Active Directory tenant on which the Office 365 and Intune services are activated. The overall goal is to establish a fully Single Sign On experience for the end user using Okta as the authentication source. The expected behavior should be slightly different for un-managed and managed devices:
Unmanaged device: This can be considered as the ‘Bring Your Own Device type’ of scenario, but not managed by Intune.
Managed device: In this scenario the device is managed by Intune and onboarded into Azure AD using an Azure AD Domain Join.
The Azure AD Domain Join is required to let user login onto their devices using their corporate ID and establish SSO with Cloud applications without the need of on-premises federation services. The Azure AD Domain Join can be either achieved using the Hybrid Azure AD Domain Join setup or by enabling the standalone Azure AD Domain Join. The scenario in this blog describes the standalone option.
So how does the scenario look like?
- Azure Active Directory is used for Intune and Office 365 purpose. In my demo scenario the account are provisioned using Azure AD connect. Password sync is disabled.
- A federation is being setup between Okta and Azure AD based on the WS-Federation protocol. In this setup Okta is identified as the Identity Provider and Azure AD as the Service Provider.
- Okta is used as the corporate authentication source (IdP). In this scenario the accounts and passwords are provisioned using the Okta Azure AD agent.
- A federation is configured between Okta and Salesforce based on the SAML protocol.
- The Azure AD application portal is used to present applications to the end user.
- A federation is being setup between Azure AD and Okta based on the SAML protocol. In this setup Azure AD is identified as the Identity Provider and Okta as the Service Provider.
The federation described in (diagram) step 6 is required to enable a Single Sign On experience for Azure AD Domain Joined devices. During the login on the device an Azure AD token is retrieved which can be used to enable a Single Sign On experience to Azure AD federated applications. In this scenario, Okta is the Identity Provider which requires an Okta token to enable the same experience. To achieve this, a federation is configured as described to leverage the Azure AD token during the device login to retrieve an Okta token.
The flow of authentication will look like this:
A. The user logs in to the device.
B. An Azure AD token is retrieved during the initial sign in.
C. The Azure AD token is used to access and enable a Single Sign On experience to the Microsoft MyApps portal.
D. The Salesforce application is selected in the application portal which points to the Salesforce configuration settings in Okta. This initiates a redirect + SAML post request to Azure AD.
E. The SAML post requests to Azure AD which consumes the already existing Azure AD token. This initiates a redirect + SAML Post request back to the Okta SAML endpoint.
F. The SAML token is consumed by the Okta endpoints and issues an Okta SAML token.
G. The Okta token is used to access the Salesforce application.
The trace below you’ll find the exact Post and Get messages related to step D-G. Please note that I have enabled MFA in Salesforce which is also visible in the trace below.
Also please note the URL accessed in step D. This URL is formatted in the following way:
Assertion Consumer Services (ACS) endpoint ?fromURI= Embedded link Salesforce application
So how do we set things up?
Now we have an overview of the scenario, it’s time go over the configuration steps. For the sake of this blogpost I will go over specific details regarding this scenario, covering:
- Setup of the integration between Azure and Okta.
- Setup of the SSO, experience to Salesforce
The prerequisites for this scenario:
- Hybrid identity connection between AD and Azure / Okta using Azure AD Connect and the Okta AD agent.
- Federation between Okta and Salesforce.
- Some user identities.