Configure Relying Party Trust in AD FS

With our Third Party IDP configured in Workspace ONE Access and our Service Provider Metadata in hand, we can now configure a Relying Party Trust in AD FS for our Workspace ONE Access tenant.  This will utilize our Service Provider metadata to establish trust between AD FS as the Identity Provider and Workspace ONE Access as the Service Provider.

1. Connect to the ADFS Server

Double click the Intranet.rdp link from the Desktop.

You will need to modify your ADFS configuration to establish trust to Workspace ONE Access, which must be done from the server where we have installed ADFS.

2. Paste the sp.xml File

  1. Click the File Explorer icon on the taskbar
  2. Click Downloads
  3. Right-click within the Downloads folder and click Paste

3. Add Relying Party Trust

Return to AD FS Management.  If closed, you can either navigate to Server Manager and click Tools > AD FS Management or search for AD FS Management from the Start menu.

  1. Expand Trust Relationships
  2. Click Relying Party Trusts
  3. Click Add Relying Party Trust

This will open the Add Relying Party Trust Wizard.

3.1. Start Add Relying Party Trust Wizard

Click Start.

3.2. Select Data Source

You will now provide the Service Provider Metadata XML that you copied and pasted in the Downloads folder previously when creating your Third Party IDP in Workspace ONE Access to establish trust between ADFS and Workspace ONE Access.  

  1. Select Import data about the relying party from a file.
  2. Click Browse...

3.2.1. Provide Service Provider Metadata XML File

  1. Click Downloads
  2. Click sp.xml
  3. Click Open

3.2.2. Continue After Providing sp.xml File

Your sp.xml filepath will now be displayed in the Federation metadata file location field.  Click Next to continue.

3.3. Specify Display Name

  1. Enter {YOUR_TENANT_NAME} for the Display Name, replacing {YOUR_TENANT_NAME} with the Workspace ONE Access tenant name you accessed in previous steps.
  2. Click Next.

The Display Name has no impact on the Relying Party Trust, but it is recommended to name the trust accurately so you know which service it is integrated with.

3.4. Configure Multi-Factor Authentication

Multi-factor Authentication (MFA) requires a user to complete two or more authentication challenges from multiple categories: Knowledge (something they know, like a password), possession (something they have, like a FOB or device), and inherence (something they are, such as biometrics).  

Multi-factor Authentication configuration is out of scope for this exercise, so click Next to continue without configuring it.

3.5. Choose Issuance Authorization Rules

Issuance Authorization Rules specify if a user is permitted to receive claims, or authentication requests, for this relying party.  We can either permit all users or deny all users from accessing this relying party.

  1. Select Permit all users to access this relying party.  In our case, we want our domain users to be able to use this relying party to authenticate.
  2. Click Next.

3.6. Review and Continue with Relying Party Trust Wizard

Review any desired information about the relying party before clicking Next.  Notice that certificates were also included with the Service Provider Metadata, which will be used to encrypt the SAML assertions from Workspace ONE Access.

3.7. Finish Relying Party Trust Wizard

  1. Leave the Open the Edit Claim Rules dialog for this relying party trust when the wizard closes option enabled.
  2. Click Close.

4. Add Claim Rules for Relying Party

In order to properly authenticate our users, we need to add Claim Rules for our relying party. Claim Rules control the flow of claims and are responsible for taking one or more incoming claims, applying conditions to these claims, and then producing one or more outgoing claims.  Claim Rules and the Claims Engine are responsible for determining if incoming claims should be passed through as they are received, filtered to meet specific business logic criteria, or transformed into a new set of claims before they are issued as an outgoing claim.  

In short, think of Claim Rules as the logic that inspects, processes, and transforms incoming claims to outgoing claims which determine who and how users are authenticated.  For more detailed documentation, check out the Role of Claim Rules.

In this lab, we'll need to create two types of Claim Rules.  

  1. Send LDAP Attributes as Claims:  Meaning that the outgoing claim will contain LDAP attribute values from our attribute store (Active Directory, in this case) that can be used for authentication.
  2. Send Claims using a Custom Rule:  Will use the claim rule language to generate and transform our claim to handle specific business logic requirements needed to authenticate the user in Workspace ONE Access.

4.1. Add Issuance Transform Rules for LDAP Attributes

Claim Rules are processed in chronological order by the claims engine, so the order of our rules is important.  For example, the output of one rule can be used as the input of the next rule, so depending on your business logic, you may need to carefully craft how your claims will be passed through, processed, or transformed.

4.1.1. Add Issuance Transform Rule

From the Edit Claim Rules dialog:

  1. Ensure the Issuance Transform Rules tab is selected
  2. Click Add Rule

4.1.2. Choose Rule Type

  1. Select Send LDAP Attributes as Claims for the Claim Rule Template
  2. Click Next

4.1.3. Configure Claim Rule

  1. Enter Get Attribute Email Address for the Claim Rule Name
  2. Select Active Directory as the Attribute Store
  3. Select E-Mail-Addresses from the LDAP Attribute dropdown
  4. Select E-Mail Address from the Outgoing Claim Type dropdown
  5. Click Finish

For this claim rule, we've mapped the E-Mail-Addresses LDAP attribute as E-Mail Address to our outgoing claim type and have issued the claim.

4.2. Add Issuance Transform Rules for Custom Claims Rule

Our Get Attribute Email Address Claims Rule is now created.  Next, we'll create a Custom Claims Rule.

Click Add Rule to get started.

4.2.1. Choose Rule Type

  1. Select Send Claims Using a Custom Rule as the Claim Rule Template
  2. Click Next

4.2.2. Configure Claim Rule

  1. Enter Transform Email Address as the Claim Rule Name.
  2. Copy and paste the below text for the Custom rule.  
    NOTE: Remember that you can select the text in the manual, then drag-and-drop the text into the console to automatically copy and paste it!
  3. You will need to replace the {YOUR_TENANT_NAME} text at the end for the spnamequalifier with your VMware Identity Manage tenant!  Otherwise this rule will not work.  This rule transforms the outgoing Email Address claim and issues both the email.
    c:[Type == ""] => issue(Type = "", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties[""] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress", Properties[""] = "{YOUR_TENANT_NAME}");
  4. Click Finish.

NOTE: Remember that you can highlight the text within the manual and drag-and-drop the selection into the terminal to paste the text.

4.3. Apply Claim Rules

  1. Click Apply.
  2. Click OK to close the Edit Claim Rules dialog.

5. Return to the Main Console

Click the Close (X) button on the Remote Desktop Connection bar to return to the Main Console.


Add your comment

E-Mail me when someone replies to this comment

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.