Setting Up Federated Identity Management for VMC on AWS – Authentication with ADFS

The Federated Identity feature of VMware Cloud on AWS can be integrated with Microsoft Active Directory Federation Services (ADFS). In this integration model, the customer dedicated vIDM tenant will work as the SAML Service Provider and the ADFS will work as the IdP.

Disclaimer:

The ADFS settings in this blog are to demo the integration for vIDM, which may not be the best practise for your environment or meet your business and security requirements.

Note: please complete the vIDM connector installation and the vIDM tenant basic setup as per my first blog of this series (https://davidwzhang.com/2019/07/31/setting-up-federated-identity-management-for-vmc-on-aws-install-and-setup-vidm-connector/) before continuing.

The AD domain name for this blog is davidwzhang.com.

The ADFS is installed on a Windows 2016 standard server. The DNS name for ADFS service is adfs1.davidwzhang.com.

Step 1: Get the ADFS Metadata Information.

The URL to this ADFS metadata is https://adfs1.davidwzhang.com/FederationMetadata/2007-06/FederationMetadata.xml. Click the URL to download the metadata XML file.

Step 2: Create an Identity Provider in vIDM Tenant

Go to the vIDM tenant administrator console and click “Add Identity Provider” and select “Create Third Party IDP” within the “Identity & Access Management” tab.

Input the parameters as below:

  • Identity Provider Name: ADFS01
  • SAML AuthN Request Binding: HTTP Redirect

In the SAML Metadata section, copy the content of XML file FederationMetadata.xml to the text box of the Identity Provider Metadata (URL or XML) then click the button “Process IdP Metadata”. The Name ID Format section will have 3 entries popped up.

Now, click the green plus icon to add a new mapping as the below:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified – userName.

Then from the dropdown of the “Name ID policy in SAML request (Optional)”, select “urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified”

The rest of the settings are as below:

  • Just-in-Time User Provisioning: Disabled
  • Users: davidwzhang.com
  • Network: ALL Ranges
  • Authentication Methods
    • Authentication Methods: ADFS Password
    • SAML Context: urn:oasis:names:tc:SAML:2.0:ac:classes:Password 
  • Single Sign-Out Configuration: Disabled

Then click the hyperlink of “Service Provider (SP) Metadata” to download the Service Provider metadata and upload it to the ADFS server.

Step 3: Update Authentication Policy

Update the vIDM tenant’s default access policy to include ADFS as the first authentication method.

Step 4: Configure ADFS Relying Party

Now it is time to setup the ADFS. First, start the ADFS Management tool from Server Manager and add a Relying Party Trust as the below.

In the welcome screen of “Add Relying Party Trust” wizard, select “Claim aware” and click the Start button.

Select the uploaded sp.xml file in step 2 to import data about the relying party and then click the Next button.

Input “vmccsa-demo” as the relying party display name, then click the Next button.

Choose “Permit everyone” as the Access Control Policy and click the Next button. Note: please select different access control policies for your use case.

Click the Next button.

Now, click the Close button to finish the wizard.

Step 5: Create ADFS Relying Party Claim Rules

Select the newly created relying party, right click and select “Edit Claim Issue Policy…”.

Click the “Add Rule…” button to add a new Transform rule.

In the “Choose Rule Type” step of the “Add Transform Claim Rule” wizard, select “Select LDAP Attributes as Claims” and click the Next button.

Input the following parameters:

  • Claim rule name: Get Attribute Email Address
  • Attribute store: Active Directory
  • Mapping of LDAP attributes to outgoing claim types:
    • LDAP Attribute: E-Mail-Addresses
    • Outgoing Claim Type: E-Mail Addresses

Click the Finish button. Then add the second new rule. The new rule will use “Send Claims Using a Custom Rule” as its rule template.

Next, input the name and custom rule:

The content of the “Custom rule” is as below. Please replace “xxxxx.vidmreview.com” with your own vIDM tenant URL.

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "xxxxx.vidmreview.com");

Now, when you try to log into the VMware Cloud service console with your AD account, your login session will be redirected to the ADFS as below, which authenticates your session.

Setting Up Federated Identity Management for VMC on AWS – Authentication with Active Directory

This blog is the second blog of this Federated Identity Management for VMC on AWS series. Please complete the vIDM connector installation and setup as per my first blog of this series before moving forward. (https://davidwzhang.com/2019/07/31/setting-up-federated-identity-management-for-vmc-on-aws-install-and-setup-vidm-connector/)

VMware Cloud on AWS Federated Identity management supports different kinds of authentication methods. This blog will demo the basic method: authentication with the customer corporate Active Directory (AD).

When VMC on AWS customers use AD for authentication, outbound-only connection mode is highly recommended. This mode does not require any inbound firewall port to be opened: only outbound connectivity from vIDM Connector to VMware SaaS vIDM tenant on port 443 is required. All user and group sync from your enterprise directory and user authentication are handled by the vIDM connector.

To enable outbound-only mode, go to update the settings of the Build-in Identity Provider. In the user section of Built-in Identity Provider settings, select the newly created directory “lab.local” and add the newly created connector “vidmcon01.​lab.​local”.

After the connetor is added successfully, select Password (cloud deployment) in the “Connector Authentication Methods” and click Save.

Now it is time to update the access policy to use corporate Active Directory to authenticate VMC users.

Go to Identity & Access Management.

Click “Edit DEFAULT POLICY” then the “Edit Policy” window pop up. Click Next.

Click “ADD POLICY RULE”.

Then the “Add Policy Rule” window will pop up. At this stage, just leave the first two configuration items as default: “ALL RANGES” and “ALL Device Types”. In the “and user belong to group(s)” config item, search and add all 3 synced groups (sddc-admins, sddc-operators and sddc-readonly) to allow the users in these 3 groups to log in.

Add Password(cloud deployment) as authentication method.

Use Password(Local Directory) as fallback authentication method and click Save.

There are 3 rules defined in the default access policy. Drag the newly defined rule to the top of the rules table, which will make sure that the new rule is evaluated first when a user tries to log in.

Now the rules table shows as below. Click Next.

Click Save to keep the changes of the default access policy.

You are now good to test your authentication set up. Open a new Incognito window in your Chrome browser and connect to the vIDM URL. Type in the username (jsmith@lab.local) and click Next.

Type in the Active Directory password for user jsmith@lab.local and click “Sign in”.

Then you can see that jsmith@lab.local has successfully logged in the vIDM!

Thank you very much for reading!