I feel like it shows the quality and strength of a vendor’s solution when we can confidently stand behind what we do and are also aware enough to partner with others to provide better experiences for our joint customers. One of the best examples of this is Okta and VMware coming together to jointly work on and promote a unique partnership where we can leverage the best of both vendor’s portfolio to provide the best user experience while ensuring security for your Organisation.

Outside of being how it all works and integrates (which I’ll deep dive into shortly), I am often asked what the value is for customers. Okta Identity Cloud (as the name suggests) is a cloud-based Identity and Access Management solution that enables Single Sign-On the User Lifecycle to Modern Applications and Services. According to their website, they have over 5500 out-of-the-box integrations and have been consistently called out as a leader in their field.

I have been developing with and using Okta for nearly a year now as part of the VMware and Okta partnership. I’ve found it very powerful and easy to manage, and it seems more and more customers in my region are finding this too. With this, they are now looking to leverage the integrations between Workspace ONE and Okta Identity Cloud to take their Digital Workspace to the next level.

At the risk of taking the wind out of this post’s sails, VMware has a page dedicated to this partnership but I still seem to get asked Why is there a Partnership, What is the Value, and How does it Work? So with this post I am going to answer this.

So channelling my inner Simon Sinek, lets Start With Why?



I think this one is a pretty easy one.

  • VMware Workspace ONE is a leading Digital Workspace Platform with many unique capabilities like Conditional Access and Adaptive Management.
  • Okta is a leading IAM Platform with a key focus, like VMware, on User Experience and Security
VMware and Okta are both dedicated on providing the best user experience for our customers and while ensuring their data, devices and user’s privacy are secured.
What is the Value?
When a company’s solution align and complement like this, its an easy choice where customers choose both vendor’s solutions to better their outcomes.
Outside of each Vendor’s independent standalone capabilities the true value in my opinion is:
  • The ability to maintain your company’s existing investment in Okta and leverage Workspace ONE’s capabilities without disrupting existing SSO federation.
  • Seamlessly authenticate users with Okta while leveraging Workspace ONE’s MobileSSO.
  • Redirect Workspace ONE users and devices to VMware Identity Manager to enforce Conditional Access and evaluate things like Device Compliance, Management Status, Jailbreak Status, Geolocation and Network Location (plus more).

What this really means is that through our integrations we can provide seamless Single Sign On to your Company Applications, while ensuring that only approved, compliant devices from known regions or locations are able to gain access. The other key outcome here is that unlike other Identity Provider integrations, using Okta IDP Routing Rules we can selectively redirect authentication requests to either Workspace ONE or Okta depending on scenario or use case.

To see how it works, there is a video at the end of this post.
How Does it Work?

(cracks knuckles) OK so now lets get down to the technical details. The three components in this solution are Okta Identity Cloud, VMware Identity Manager and VMware Workspace ONE UEM.
Okta in this scenario is purely an Identity Provider (IDP) and for the purposes of our integration, the Service Provider (SP eg. Salesforce) is federated with Okta. Identity Manager is also an IDP however we can use certificates for seamless and transparent SSO with no user auth prompts, and also can validate only approved devices can authenticate. These capabilities are provided by the integration with Workspace ONE UEM, the Unified Endpoint Management platform.
To provide the full outcome we do the following:
  • Configure Identity Manager as an Identity Provider in the Okta Console.
  • Add Okta as an Application Source in the Identity Manager Console.
  • Leverage Device Management, Certificate Deployment and Compliance Checks capabilities of Workspace ONE UEM in Identity Manager.
  • Configure the IDP Discovery Routing Rules in Okta to redirect devices to Identity Manager.
The flow once configured looks like this:
  1. User opens Salesforce (or other SaaS App).
  2. This App has been federated with Okta as the IDP and is redirected to Okta for authentication.
  3. In Okta, this App has been tagged as a Critical App with Increased Security in an Okta Routing Rule so the authentication is redirected to Identity Manager.
  4. When evaluating the Access Policies in Identity Manager, it is checking the details of the device in Workspace ONE UEM.
  5. If the device is non-compliant against the company device security baseline, it is blocked.
  6. If the device meets the security criteria, a valid SAML Assertion is generated and passed back to Okta.
  7. The user gains access to the service.
The last thing to point out here as well is that because Okta and Identity Manager are both federated with each other and Okta is set as a Service Provider in Identity Manager, you can also list Okta Applications inside the Workspace ONE App Catalog.
There is a demo of how this looks at the end of this article.
Great, so how do we set it up?
Glad you asked. But before we kick-off, the assumptions here are you have your On-Prem AD synchronised to Okta, Identity Manager and Workspace ONE UEM and you have at least one SaaS service federated with Okta. Plus, you have a configured and integrated Identity Manager and Workspace ONE environment.
Firstly, go to your Okta Cloud Identity Console. Log in (with your admin credentials) and then go to the Users Tab, and click on Social & Identity Providers.
Here is where we need to add Identity Manager as an Identity Provider. Select ‘Add Identity Provider’ and then ‘Add SAML 2.0 IdP’
Its pretty straight forward to add the IDP. Give it a name (anything) and set the Authentication Settings to what matches your environment. For mine:
IdP Username: I used NameId because the SAML Assertion value sent in this from Identity Manager will match my usernames in Okta (eg. my sAMAccountName from AD).
Match Against: To be safe, I’m letting it check against Username and Email. This allows for other scenarios where I may send ’email address’ in the NameID value of the SAML Assertion.
If no match is found: I don’t want/need to use JIT but enabling this gives you more settings.
For the next 3 settings, we’ll need to log in to your Identity Manager tenant to obtain. Log in to your Identity Manager Admin Console and go to Catalog -> Web Apps and then Settings.

In here you can get the values you need:
IdP Issuer URI: This value is your Identity Provider (IdP) metadata URL
IdP Single Sign-On URL: This value is https://youridentitymgrtenant/SAAS/auth/federation/sso – make sure you adjust this to match your tenant URL.

IdP Signature Certificate: Download the Signing Certificate (as a file) and upload to the Okta Console.
It should look similar to this.
After we save this, Okta knows about Identity Manager . We now need to configure Okta in the Identity Manager Console so we can add the Okta Federated Apps.
Go back to the same place we were before Catalog -> Web Apps -> Settings and in this window you’ll see ‘Application Sources’. Click on this, and then Okta.
Skip to the Configuration Section, select Manual and fill out the following fields. 
You get these values from your Okta Console, where you configured Identity Manager as an Identity Provider:
Single Sign-On URL: This is the Assertion Consumer Service URL from your Okta Console.
Recipient URL: This is the Assertion Consumer Service URL from your Okta Console.
Application ID: This is the Audience URI from your Okta Console.
Username Format: If you don’t have a reason to change this, leave it as Unspecified.

Username Value: Set the value that you want sent in the SAML Assertion that matches your Okta configuration. In our example, this variable will send sAMAccountName.
Yours should now look like this.
You can now Next through this to Save the integration.
While we’re in the Identity Manager Console, its a good time to talk about how to add Okta Federated Apps into the Workspace ONE Catalog. 
Go back to your Okta Console, and go to Applications. This will show any SaaS Apps you have federated. Go into that App’s settings, Select the General tab, and scroll down to App Embed Link. Copy the Embed Link here as this is what we’ll need to add to Identity Manager. 
To add this to the Identity Manager Console, in the Web Apps Catalog page (same place we were at above), Select NEW and fill give the App a Name.
Click Next, and in the Authentication Type Dropdown select Web Application Link. In Target URL paste the Embed Link that your copied from the Okta Console.
Press NEXT and Save to Continue. We now have Okta and Identity Manager federated with the Salesforce App in the Catalog.
The last part we need to do is configure the IDP Discovery Routing Rules. In your Okta Console, back where we added an Identity Provider (Applications -> Social & Identity Providers), there is another Tab up the top called Routing Rules. Select this and then press Add Routing Rule.
In this Rule configuration page, we just need to set this to match how we want to route our users for authentication.
In the above rule this will:
  • Any user from any network, on any mobile device, accessing Salesforce will be redirected to my Identity Manager Tenant.
Now, if we jump back to our Identity Manager Console we can define Access Policies to enforce conditional access. If you don’t specify anything, any authentication request will process the ‘default_access_policy_set’.
To enforce your Okta App to use MobileSSO and Check device status you can configure a new Access Policy. 
I’m sure you know how to create an Access Policy 🙂 so I won’t outline how to do it, but below are the authentication settings to show.
Add an Access Policy and then in the ‘Applies to’ section select ‘Okta’. This selects and Apps integrated with Okta. Set any policies you need however I will configure a Policy for iOS that enforces MobileSSO and checks device compliance.
A couple of Important Points:
  • Device Compliance only works when using Mobile SSO. This is because the certificate that is used for Mobile SSO has the device UDID as a SAN attribute so we can validate the device in conjunction with the user. You can use more ‘and’ statements, but cannot use Compliance without MobileSSO.
  • This is secure because in this policy you can only authenticate using Mobile SSO which requires a certificate, and the only way to get a certificate is to enrol your device.
  • All of this is invisible to the user. Mobile SSO automatically gets the certificate from the device certificate store and authenticates without user entering credentials.
  • IDP initiated auth works where by a user can open the App from the Identity Manager Console. SP initiated auth (ie. going to the Salesforce URL) also works as it will redirect to Okta for auth, the routing rules kick in redirecting to Identity Manager and then all of the Access Policy settings are enforced.
Phew.
This has been a long article, but below are some videos that show some common scenarios.




Authentication Flow without Routing Rules

Below in the first video we’ll see what it looks like accessing Salesforce when federated with Okta. There are no routing rules in place, and is being accessed on an unmanaged device with an unknown security posture.








Accessing Salesforce Federated with Okta on an Unmanaged iOS Device

In this video Routing Rules are configured in Okta, and the user is redirected to Identity Manager. Because the device is not managed or compliant, they are denied access. This same authentication process is enforced when using the mobile version of the Salesforce App.










Accessing Salesforce Federated with Okta on a device Managed by Workspace ONE

This is what it looks like end to end. Firstly I open the Workspace ONE Intelligent Hub and open the App we added to the Identity Manager Catalog. I already have a SAML assertion so it gets passed to Okta and I authenticate with Salesforce.

In the second part, I open a browser and do SP initiated authentication. I go to Salesforce, redirect to Okta for authentication and then the routing rule redirects me to Identity Manager. The authentication policy challenges my device for a certificate and checks my device posture against Workspace ONE UEM. Once I pass these, I’m sent back to Okta with my SAML Assertion and then authentication to Salesforce.