ADFS Integration with Omnissa Access (Mobile Only Traffic)

Posted byNavjyot Singh ChaneyPosted inWorkspace ONE AccessTags:, , , , , , , , ,

Important Terms used in this blog

Web Theme Name: OMNISSAACCESS

ADFS: Active Directory Federation Services

Claims Provider: This is to add services as an Identity Provider in ADFS

Relying Party Trust: This is to add services as Service Providers in ADFS

Workingfoldername: Name of the folder you want to create

1. Introduction

ADFS remains a widely used Identity Provider for both Microsoft and third-party applications.

This blog explores how ADFS can be integrated with Omnissa Access by configuring ADFS to recognize Access as a third-party Identity Provider. This setup enables key use cases such as Mobile SSO and Certificate-Based Authentication. Additionally, Omnissa Access enhances identity services by offering features like a unified application catalog and conditional access policies based on device posture.

While Omnissa Access is fully capable of functioning as a standalone Identity Provider, replacing existing systems like ADFS, Ping, or Okta in a production environment can be complex and disruptive. To minimize effort and preserve the end-user experience, this integration approach allows organizations to leverage Access without removing their existing Identity Providers.

Workflow:

Application–>ADFS(forwarding the traffic to Access)–>Workspace ONE Access (for authentication)–>ADFS (assertion token)–>Application logged in

2. Process

  • Add Omnissa Access as a Claims Provider (Identity Provider) Trust in ADFS
  • Configure ADFS as a Service Provider in Access
  • Test the Workflow and the Authentication

NOTE: Please follow docs.omnissa.com to achieve the above 3 configuration

Assuming the above is configured correctly, the next step is to configure the redirection of authentication flow for mobile devices only. This is done to automatically redirect mobile users to Access and keep Windows traffic restricted to ADFS

For a Windows device the authentication flow will look like this:

Web App–>ADFS Authentication–>Web App log in

For Mobile (as mentioned above):

Application–>ADFS(forwarding the traffic to Access)–>Workspace ONE Access (for authentication)–>ADFS (assertion token)–>Application logged in

ADFS uses a Web Theme to display the Home Realm Discovery page that contains the mobile redirect code. Now, let’s move on to the actual steps

3. Steps

  • Log in to ADFS and Admin Privileges
  • Create a Folder
    1. Mkdir c:\workingfoldername
  • Export the default ADFS theme
    1. Export-AdfsWebTheme –Name “Default” –DirectoryPath c:\workingfoldername
    2. This creates an onload.js file within that folder. This is where you will have to make the changes.
  • Add the following code to the beginning of the onload.js file. I’ve also seen this work if you place it at the bottom as well. However, just to follow Omnissa best practices, place it right in the beginning
  • Change the Access Tenant and ADFS Claims Provider details
    • For ADFS 4.0 – ADFS Claims Provider would be ‘AD Authority’
    • For ADFS 3.0 – ADFS Claims Provider would be ‘http://{ADFSdomain}/adfs/services/trust’ 
var myCheckHRD = document.getElementById('hrdArea');
if (myCheckHRD)
{
// redirect mobile traffic to Workspace ONE
if (navigator.userAgent.match(/iPad|iPhone|Android|Windows Phone/i) != null)
{
HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');
}
// ADDITIONAL LOGIC FOR iPadOS AND iOS 13 iPad DEVICES
else if (navigator.userAgent.match(/Macintosh/i) != null)
{
if(navigator.maxTouchPoints > 2)
{
HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');
}
else
{
HRD.selection('{AD FS claims provider}');
}
}
// else authenticate with local AD claims provider
else
{
HRD.selection('{AD FS claims provider}');
}
// hide HRD selector from user
var hrdui = document.getElementById("bySelection");
hrdui.style.display = "none";
}

Courtesy: Omnissa Docs

  • This promotes Access as the default form of Authentication for Mobile users
  • Next, replace the onload.js file with the old one
  • Create an ADFS web theme. This is needed to apply it to the newly created onload.js
    1. New-AdfsWebTheme –Name “OMNISSAACCESS” –SourceName “Default”
  • Import the onload.js
    1. Set-AdfsWebTheme -TargetName OMNISSAACCESS -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path=”c:\workingfoldername\script\onload.js”}
  • Activate this theme
    1. Set-AdfsRelyingPartyWebTheme -TargetRelyingPartyName “Microsoft Office 365 Identity Platform” -SourceWebThemeName “OMNISSAACCESS”
    2. Microsoft Office 365 Identity Platform is the default name. Make sure to match it with what you have under the Relying Party in ADFS
  • Restart ADFS service
    • Restart-Service adfssrv

One important thing – Make sure to apply the Web Theme to the Relying party ID in ADFS. This is done to override the existing theme

Set-AdfsRelyingPartyWebTheme -TargetRelyingPartyName “Microsoft Office 365 Identity Platform” -SourceWebThemeName “OMNISSAACCESS”

4. Conclusion

Modifying the onload.js file is only necessary if you intend to redirect mobile traffic to Access. If all traffic is to be redirected, no changes to onload.js are required.

To revert the changes, run the following command:

Set-AdfsWebConfig -ActiveThemeName “Default”

The integration process is straightforward, and all steps mentioned in this blog are also documented in the official Omnissa Docs. For the most accurate and up-to-date guidance, always refer to the official documentation.

Hope this was helpful!

Leave a comment