We get a lot of questions about how to solve Single Sign-On (SSO) of users between two Active Directories without trust. Using the federation protocol SAML and VMware Access this is easy to achieve.

In my example we have three Domains, Black, Blue and White. Users in Domain Black want to access resources in Domain Blue and White without being prompted for username or password.

Prerequisites

  • You need three VMware Access either Cloud or on-premise. One in each domain.
  • Federate the resource (a web server in my example) in Domain Blue and White to VMware Access in Domain Blue and White
  • A user object representing the user must exist in all the Domains. One user attribute must be shared across the three domains. In this example we are using the Email attribute. The attribute you choose must uniquely identify the user.
  • We used @idp.com for this demo

If your resource is a Windows application, VMware Horizon and the feature True SSO can be used to achieve SSO access for Domain Black users into a Horizon desktop and applications running in Domain Blue and White.

A screenshot of a cell phone Description automatically generated

Establish SAML based trust

First thing first, once the prerequisites are in place next step is to establish a trust between the three VMware Accesses. This trust is based on SAML and is much easier to establish than traditional Active Directory trust.

You establish trust by exchanging metadata.xml files between the three Identity Managers. In this example users from Domain Black need to access resources in Domain Blue and White. So, VMware Identity Manager Blue and White must trust Vmware Access Black as a third-party Identity Provider (idP).

  • Select IDP metadata

On the VMware Identity Manager in Domain Black navigate to Catalog – Settings – SAML Metadata. Right click on Identity Provider (idP) metadata and choose Copy link address.

Now navigate to the VMware Identity Manager in Domain Blue and White and add a third-party idP. Must use Legacy Connector for Horizon True SSO integration

Give the new Identity Provider a name and paste the link to the idp.xml into the metadata field. Scroll down and click Save.

Once saved you’ll see all the settings being populated.

In this example, we are relying on the Email attribute (@idp.com). Therefore, delete all the other Name ID Formats.

In the Name ID Format drop down change this to: urn:oasis:names:tc:SAML:1.1:nameid:format:unspecified

Name ID value = emails

Next configure the user store where your users are in Domain Blue’s and White’s VMware Access and which network ranges this idP will serve. In this example we have defined this as All ranges.

You need to create an Authentication Method. We will use Password to login users in Domain Black’s VMware Access.

We named the Authentication Method: Black_PWD and password typically use SAMLContext: 

urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport.

But obviously here your settings must match your implementation across all the VMware Accesses and in the AD records for the email attribute.

Scroll down.

Right click on the SAML Metadata, Service Provider (SP) metadata link and choose Save link as…

Now you have downloaded a file called sp.xml. This will be used later.

Click Save

Still on the VMware Access in Domain Blue and White you need to add the new Authentication Method in your access policy.

In this example we simply add it as the second one. In our case we will only support idP initiated flow. If you are planning on supporting SP-init flow you must think about the order of authentication (authN) methods.

In above picture, you can see we added Black_PWD as the third authentication method. (This name was given the authentication method in previous step.)

With these steps, we have now established a SAML based trust. Domain Blue’s and White VMware Access trusts SAML assertions from Domain Black’s Vmware Access.

Configure Users

Next step is to make sure you have user objects in both domains sharing the same attribute.

We are using the Email attribute as the unique User Identifier. (@idp.com)

Above is a screenshot of my test user synced into VMware Access in Domain Blue.

And below is the user object in my Domain Black’s VMware Access.

As you can see in this example most attributes are the same. But the only important attribute is the Email one. That must be identical in both Domain Black, Blue and White.

Run a test

Let’s now run a test to verify the SAML trust works from Black to Blue and White.

We need to create an application in Domain Black’s VMware Access that represents the VMware Access in Domain Blue and White.

Setting an Application to allow you to reach each of the domains with SAML and consume the applications in these domains.

In Domain Black VMware Access, create a new SAML 2.0 based Web Application

Summary = Manual
  • Select URL/XML as per about in the above picture
  • Paste the content of the sp.xml file from the Domain Blue you saved previously into the Meta-data XML field and click on Save.
  • Modify the Configuration to use Email instead of Username:

Name ID Format: Email address

Name ID Value: ${user.email}

Click Save.

Entitle your test user ([email protected]) to the newly created application.

Login to VMware Access in Domain Black as your test user.

Click on the application icon representing the VMware Access in Access Blue Domain or Access White Domain.

SAML Assertion is generated..

If all is correctly configured you should now have been Single Sign-On into the VMware Access in Domain Blue or White. Now all resources entitled to the test user in Domain Blue or White are possible to consume.

Below is a picture showing what we have configured and tested so far.

While the test was successful. This method is not ideal from an end-user experience perspective. Users have to login to one portal and then get SSO:d into another portal. Next users must launch the application. We can solve this by adding resources from Domain Blue or White straight into the portal in Domain Black.

Adding remote resources in VMware Identity Manager portal

VMware Access have one very nice feature and that is that each resource has its own unique launch URL. This can be used in many ways. Customers are placing links that launches applications on their intranet pages and such. But in this case, we will use it to provide a greater user experience.

First, we need to identify the unique application ID used in the VMware Access in Domain Blue and White

In above picture, you can easily find the UUID. This is the key to the unique launch URL. For Web Applications, you can also find the unique launch URL under Configuration tab.

But for Horizon resources it is different. Here you will have to build your own launch URL using the UUID.

The launch URL format is: https://<hostname>/SAAS/API/1.0/GET/apps/launch/app/<resourceUUID>

So now when we know the unique launch URL let’s login to VMware Identity Manager in Domain A and manually create the representation of the resource.

Create a new SAML 2.0 SAML Web Application in Domain A’s VMware Identity Manager.

Configure the new Web Application:

  1. Copy the content of the sp.xml (same one as we used to create the icon for the full Domain B’s VMware Identity Manager) into the metadata field
  2. Name ID Format and Name ID Value should be Email (just the same as we did before)
  3. RelayState, enter the unique Launch URL of the application

Once saved, entitle the new application to your test user..

Now let’s test this new method..

Login to Domain A’s VMware Identity Manager as your test user.

Now launch the application pointing to the unique Launch URL. In my case Office 365 Portal.

SAML Assertion is generated..

..if the configuration is correct you should get straight into your federated application.

Spread the love