Zero Trust M&A Strategy: Adaptive Authentication


Those of us in IT understand the complexities with integrating two separate IT environments into one because of a merger/acquisition. How can we provide access to apps from another company with a zero trust network access (ZTNA) strategy? 

This was something recently detailed in the following items

The overall solution incorporates Workspace, Virtual Apps the Desktops Service, and the Secure Workspace Access Service, as detailed in the following conceptual architecture.

Initially, let’s focus on how to deal with the user’s primary identity.

If you plan on merging different identity providers into one, how long does it take?  Will it ever happen?  Does it even make sense to merge?  What happens if you acquire multiple organizations? Your entire job could simply be merging identity providers. 

But it gets more challenging than simply merging identity providers.

For numerous applications, a user’s authorization is based on the user’s primary identity.  Access control lists are based on the user’s primary identity. There are so many things reliant on the user’s primary identity that this change can have huge repercussions.

Using Citrix Workspace, the challenge of dealing with multiple identity providers because of a merger or acquisition because something much easier to handle.  And the solution is easy to expand so if your organization plans to acquire multiple organization, the process just repeats itself.

When a user connects to Citrix Workspace, we will use adaptive authentication to determine the correct identity provider. With Citrix ADC, we create an nFactor authentication policy.

Let’s break this authentication flow down into separate steps

  1. Org Selection: We need to figure out which org the user belongs to.  We can do this easily by implementing a dropdown list or we can be a little more creative and analyze the user’s email address they submit.
  2. Org Check: Once the user selects their company or enters in their email address, our nFactor policy needs to determine which organization they belong to.  For this, we create an expression in our authentication policy to look at the submitted information. This information directs the nFactor policy on the correct path through our authentication flow.
    • Dropdown List: http.REQ.BODY(500).AFTER_STR(“domain=”).CONTAINS(“CompanyA”)
    • Email Address: AAA.USER.LOGIN_NAME.SET_TEXT_MODE(IGNORECASE).AFTER_STR(“@”).EQ(“companya.com”)
  1. Authenticate: Now that we know which organization the user belongs to, we can direct the user to the correct identity provider.
    • Active Directory: Users within CompanyA uses Active Directory.  The ADC does an LDAP-based authentication. Once successful, ADC receives a set of claims about the user’s Active Directory account.
    • Okta: Users within CompanyB use Okta.  The ADC does a SAML-based authentication to Okta, which responds with a SAML Assertion identifying the user’s identity, most likely the user’s UPN.
  2. Account Lookup: Authorization to CompanyA application resources are based on CompanyA Active Directory accounts. In order for CompanyB users to be authorized to CompanyA resources, CompanyB users require a CompanyA account. We want to avoid CompanyB users from having to remember a new account. To make this work, we create a shadow account within the CompanyA Active Directory domain for CompanyB users.  The last part of the nFactor policy is to do an LDAP lookup for the CompanyB user’s Okta UPN name with CompanyA Active Directory account. Once found, ADC receives a list of claims about the CompanyB user within the CompanyA Active Directory domain.
  3. Claims Submission: With the nFactor policy complete, the ADC sends the user’s claims information back to Workspace, which is then able to generate a list of authorized resources.

When a new organization merges into the environment, we simply need to update the Org Selection and Org Check sections of our nFactor flow, then create a new authentication policy to the correct identity provider.

In the next part, we will take a deeper look into how we use the claims information to create a unified application library across multiple organizations.

Until then, remember to take a look at the following pieces of content

Daniel (@djfeller)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.