As we continue our look at the technical challenges with mergers & acquisitions, one thing will become a priority early on: providing users from one company with access to applications from the other company.
The first part is to verify the user’s identity with their original, primary identity provider, which we can easily do with adaptive authentication.
In part two, how do we use their identity to authorize access to resources?
This sounds easy, simply assign users to resources. But when we look deeper, things get a little more complex for an M&A strategy.
Take the following scenario:
- CompanyB user authenticates to Citrix Workspace using their primary identity provider, which in this case is Okta.
- The CompanyB user needs to be authorized to access a CompanyA private web app or private client/server app.
- The private web app and private client/server app for CompanyA are based on Active Directory credentials.
How can I use Identity-Provider-A to authorize access to Identity-Provider-B users?
With federation, we can link a user’s identity across numerous and separate identity providers. In order to make this work, we need a common attribute. Questions that always come up with federation is:
- Does the user have accounts in both identity providers? Yes. Because the organization providing access to a resource only knows about the identity provider it uses.
- Does this mean the user has to remember another identity? No. The user only has to remember their primary identity. Federation links the user’s primary identity with a secondary identity.
- How are the accounts linked? We use a common attribute between the federated identity providers, most likely a UPN.
I always find that this diagram helps explain the concept of a federated identity. This one is based on SAML.
CompanyB users will have an account in CompanyA domain, however that account will be unknown to the user. We can give the account any user name. For example, let’s say our CompanyB user is Homer Simpson. The account for Homer Simpson in the CompanyA domain could be called Chuck Norris. We can provide it with any name. We can give it a 100 character password. The only thing that matters is that one identified attribute is identical between CompanyB identity provider (Okta) and CompanyA identity provider (Active Directory)
Within Citrix Workspace, the admin must authorize users to the appropriate resources using a group from the CompanyA identity provider. In this case, we have an Active Directory group called “CompanyB_Users” within the CompanyA domain. The CompanyB_Users group contains the Active Directory accounts associated with CompanyB users. These accounts are often called Shadow Accounts.
In order to send Citrix Workspace the right information (claims) about the user, we need to make sure our authentication policy is doing a proper lookup. This authentication flow was detailed in the Adaptive Authentication blog and the identity lookup is step 4.
To verify the authentication policy is working as expected, we can look at the ADC authentication logs by going to the CLI and doing the following
shell cat /var/aaad.debug
Once entered, when a user tries to authentication, you will see a stream of information about the authentication process.
First, because the user is authenticating to Okta, which will use SAML, I can see the SAML assertion communication. It tells me the user name and that the assertion request was a success.
Next, we are starting the cascade authentication (nFactor). It is going to look for my username (email@example.com) in the CompanyA LDAP directory. Towards the end, we can see the search was a success.
With the user found in the CompanyA identity provider, the policy will now get a list of parameters for the user (Claims). You can see the SID, GUID, givenName, and more.
And finally, we see what groups the user belongs to within the CompanyA identity provider.
This information is sent back to Citrix Workspace, which uses this information to create a list of authorized resources.
Hopefully, this sheds some light into how we handle federated identities and how to verify that the Citrix ADC is sending back the right information
In the next part, we will take a look at how we provide zero trust network access to private web apps.
Until then, remember to take a look at the following pieces of content
- Reference Architecture: Zero Trust Mergers & Acquisitions Strategy
- User Experience Demo Video: Zero Trust Mergers & Acquisitions Strategy
In Part 2 of the #ZeroTrust #Mergers and #Acquisition strategy, learn how federated identities create a unified app library that integrates resources from multiple companies. All with #CitrixTweet