For updates on this blog and other blogs: Follow @SteveIDM
There are many use cases when integrating ADFS with Workspace ONE. In this blog, I'm going to focus on the use case of using Workspace ONE as a claims provider. The VMware documentation for integrating ADFS and Workspace ONE is quite good. Please reference the VMware Documentation for the official steps on this integration. My blog is intended to compliment the official documentation.
In this blog, we will focus on:
- Creating Workspace ONE Access as a Claims Provider
- Create your Claims Provider Trust
- Configuring the ADFS Application Source in Workspace ONE Access
- Testing the Workspace ONE Claims Provider
- Configure Workspace ONE Access as the default Claims Provider for an RP
- Modifying your Onload.js
- Using ADFS Access Control Policies
Warning - Do NOT Perform any of these steps on a production ADFS Server without testing in a lower environment. Once you add a second claims provider it will impact the experience for your users.
Creating Workspace ONE Access as a Claims Provider
Download Workspace ONE Access Metadata
- Log into your Workspace ONE Access Administration Console.
- Go to Catalog -> Web Apps
- Click on Settings
- Click on SAML Metadata
- Right-Click and Download your Identity Provider (IdP) Metadata.
Create your Claims Provider Trust
Warning - Do NOT Perform any of these steps on a production ADFS Server without testing in a lower environment. Once you add a second claims provider it will impact the experience for your users.
- Launch your ADFS Management Console
- Right Click on Claims Provider Trust and click "Add Claims Provider Trust"
- Click Start
- Select " Import data about the claims provider from a file"
- Select the Workspace ONE Metadata file you just downloaded.
- Click Next
- Select a Display Name that is recognizable to your users. This name will appear on the ADFS Home Realm Discovery Page.
- Click Next
- Click Next
- Click Close
Configure Claim Rules
- Right Mouse on the newly created Claims Provider Trust and Click Edit Claims Rules
- Click Add Rule
- Select "Send Claims Using a Custom Rule" and Click Next
- Provide a Rule Name
- Paste the following Custom Rule. This rule will transform the incoming claim (Windows Account) and set AD as the source. In using this custom rule, we will not need to modify any existing Relying Parties that are already configured.
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] ==
"urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname",
Issuer = "AD AUTHORITY", OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);
- Click Finish
- Click OK
Configuring the ADFS Application Source in Workspace ONE Access
- Download the federation metadata file for the AD FS server by navigating to the URL: https://{ADFSdomain}/FederationMetadata/2007-06/FederationMetadata.xml where {ADFSdomain} is replaced with the fully qualified domain name (FQDN) your AD FS server.
- Log into the Workspace ONE Access Admin Console
- Select Catalog -> Web Apps
- Click the Settings button
- Click Application Sources
- Click the ADFS Application Source
- Click Next
- Past the contents of the previously downloaded ADFS Metadata into the URL/XML box. It is recommended you paste the contents rather than pasting the URL.
- Click Next
- Click Next
- Click Save
- Click the ADFS Application Source again.
- Click the configuration tab
- Change the Username Format to Unspecified
- Change the Username Value to "${user.domain}\${user.userName}"
- Expand Advanced Properties
- Set Include Assertion Signature to Yes.
- For Signature Algorithm, select SHA256 with RSA.
- Change the Digest Algorithm to SHA256
- Click Next and Save
Testing the Workspace ONE Claims Provider
- Open a Private Browser
- Navigate to Service Provider that is using ADFS
- Verify that you see the ADFS Home Realm Discovery Page. Note: Your page will look different depending on how many claims providers you have configured.
- Select the option for Workspace ONE
- Enter your Credentials for Workspace ONE
- Verify that Workspace ONE responds with a successful SAML Response. Using a SAML Tracer, you can verify that the NameID is returned in a Domain\username format
Configure Workspace ONE Access as the default Claims Provider for an RP
If you have specific applications where you want to redirect all traffic for that application to Workspace ONE, you can perform the following steps:
- On the AD FS server, open a PowerShell session with elevated administrator rights.
- Run the following Powershell command
Replace the placeholders in the command as follows.Set-ADFSRelyingPartyTrust -TargetName "{RP_app}" -ClaimsProviderName "{VMWARE IDENTITY MANAGER CLAIMS PROVIDER}"
Replace {RP_app} with the name of the relying party trust corresponding to the target application.
Replace {VMWARE IDENTITY MANAGER CLAIMS PROVIDER} with the name of the claims provider trust that you configured for VMware Workspace ONE Access.
Use the names of the relying party trust and claims provider trust as they appear in the AD FS Management console.
Modifying your Onload.js
Depending on your use case, you may or may not want to do redirect all applications or all platforms for a particular application to Workspace ONE Access. As we saw above, the ADFS Home Realm Discovery page will by default prompt the user to select the claims provider. Assuming you will not run the previous PowerShell command to default traffic for particular relying party to Workspace ONE Access, we will need to use the onload.js to automate the selection for the users.
We will walk through some of your options in the onload.js. First, lets address some things that you can NOT do:
- You can not redirect to Workspace ONE Access based on username. Although it may appear that usernames appear in the request, you can not code for this reliably. If you use auto acceleration in Azure AD, you will not get usernames in the request.
- You can not redirect based on groups.
- You can not redirect based on network range.
- You can not redirect based on having an enrolled device in Workspace ONE UEM.
Before we walk through what we can do, lets get started by exporting the current ADFS WebTheme.
- Log into the ADFS Server
- Run PowerShell as an Administrator
- Create a working folder by running the following command
mkdir c:\myscripts
- Export the default ADFS web theme
Export-AdfsWebTheme –Name "Default" –DirectoryPath c:\myscripts
- In PowerShell, create a new AD FS web theme
New-AdfsWebTheme –Name "VIDM" –SourceName "Default"
- Re-import the onload.js into the new Web Theme
Set-AdfsWebTheme -TargetName VIDM -AdditionalFileResource @{Uri='/adfs/portal/script/onload.js';path="c:\myscripts\script\onload.js"}
- Activate the new web theme
Set-AdfsWebConfig -ActiveThemeName "VIDM"
- To save your changes, you will need to restart the AD FS instance
Restart-Service adfssrv
- Open C:\myscripts\script\onload.js in a text editor such as Notepad++
- In the next couple section we will go through the possible options that you can make in the onload.js. Once you make a change, you will need to re-import the onload.js. You do not need to activate or restart ADFS.
We are going to use the following placeholders in the following sections:
{AccessTenant} = FQDN of the VMware Workspace ONE Access service ie. https://dsas.vmwareidentity.com
{AD FS Claims Provider} = 'AD Authority' Note: For older ADFS environments, you might need to use: 'http://{ADFSdomain}/adfs/services/trust'
Redirecting Mobile Traffic
// 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');
}else
{
HRD.selection(‘AD AUTHORITY’);
}
Support for IpadOS Devices
// ADDITIONAL LOGIC FOR iPadOS AND iOS 13 iPad DEVICES
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 AUTHORITY’);
}
}
Hiding the HRD Selection
// hide HRD selector from user
var hrdui = document.getElementById("bySelection");
hrdui.style.display = "none";
Applying Conditions to Only Specific Relying PartiesVM
You will need to do some testing to make sure you get the correct values. If you *TEMPORARILLY* add the following code it will help get the correct values:
document.write("\n<b>WindowsLocation=</b>");
document.write(window.location.href);
document.write("<br>\n\n<b>UserAgent=</b>");
document.write(navigator.userAgent);
document.write("<br>\n\n<b>DocumentReferer=</b>");
document.write(document.referrer);
There are two options to choose from:
Option 1:
if ( window.location.href.indexOf(“urn%3afederation%3aMicrosoftOnline”|“https%3a%2f%2flogin.microsoftonline.com%2fextSTS.srf”) != -1 )
{
HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');
}
Option 2:
if (document.referrer.indexOf("https://tenant.my.salesforce.com/") != -1){
HRD.selection('https://{AccessTenant}/SAAS/API/1.0/GET/metadata/idp.xml');
}
Using ADFS Access Control Policies
If you are you using ADFS Access Control Policies, you might see some errors in the event viewer similar to:
"The caller is not authorized to request a token for the relying party "
"Microsoft.IdentityServer.Service.IssuancePipeline.CallerAuthorizationException: MSIS5007: The caller authorization failed for caller identity for relying party trust "
In order to comply with your Access Control Policies, we will need to add a policy to allow requests coming from Workspace ONE.
Here are two approaches that you can use:
Check for 'Federated Authority' in the Claims Request
This approach will not necessarily ensure the claim came from Workspace ONE. It will check if it came from a federated claim provider.
- Edit your Access Policy in ADFS
- Create a new rule that will permit users for a specific claim in the request.
- Select "Account Store" as the the Claim type and "FEDERATED AUTHORITY" as the Claim Value
- Your Rule would look similar to this:
Check for Specific Claim sent by Workspace ONE Access
In this approach, ADFS will validate a specific claim sent by Workspace ONE Access. There are a few more steps required in this approach.
- In Workspace ONE Access, open the Application Source for ADFS (Identity & Access Management -> Catalog -> Web Apps -> Settings)
- Click on Configuration and Expand Advanced Configuration
- Scroll down to Custom Attribute Mapping
- Add the attribute "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
- Select the format "Unspecified"
- Set the value to something like "WS1"
- Click Next, Next, Save
- In ADFS, edit the Claim Rules for the Workspace ONE Claims Provider Trust
- Add A New Claim Rule
- Select "Pass Through or Filter an Incoming Claim"
- Provide a Name and Select "Role" as the incoming claim.
- Click Finish. You may receive a warning, You can click OK or filter the claim value even further.
- Edit your Access Policy in ADFS
- Create a new rule that will permit users for a specific claim in the request.
- Select "Role" as the the Claim and "WS1" as the Claim Value
- Your Rule would look similar to: