A few months ago, I wrote about the steps required to create a multi-IDP environment with Citrix ADC nFactor authentication. With that configuration, we were able to leverage Citrix Gateway to front-end the authentication for multiple SAML IDPs; configure the policies required to allow for Citrix Gateway to use a different IDP based on the user’s UPN domain; and set up the Federated Authentication Service (FAS) and Citrix StoreFront for single sign-on all the way to the VDAs.
While this is a beneficial configuration for many Citrix Service Providers, it requires you to deploy both Citrix Gateway and StoreFront at your resource location. An important question comes to mind: What if I need this multiple IDP functionality and want to take advantage of the features of Citrix Workspace and Citrix Gateway service? In this blog post, I’ll cover the steps to deliver this functionality with IDP chaining.
Before we begin, I recommend that you check out my previous blog post. In it, I explain the different objects and policies required to configure Citrix ADC. Also, keep in mind that for this deployment you will need Citrix ADC version 13.0 41.20 or later (12.1 54.13 or later) and an Advanced Edition license. Here are a few additional considerations for this new configuration:
- You do not need to configure a Citrix Gateway vServer. You can (and should) configure a AAA vServer instead. Because we are using Citrix Gateway as the IDP for Citrix Workspace, the Gateway functionality is not required. The Citrix Gateway service will handle the HDX proxy for us. This also means that we do not need to create the authentication profile.
- You need to create an OAUTH IDP policy. This policy is used so that Citrix Gateway trusts requests coming from Citrix Workspace and forwards users after authentication is successful.
- You need an additional LDAP policy. This policy will not “authenticate” users against your Active Directory. It will be used to look up the shadow accounts on your Active Directory and extract the claims required for OAUTH authentication to work. Make sure your user accounts have the minimum required claims, as explained in the Active Directory section of this Citrix docs article.
This blog post will not include a detailed click-by-click guide for this configuration, but I would like to share the required steps. The following list assumes that your Citrix ADC has a license, IP addresses are configured, certificates are bound, etc.
- Create an LDAP authentication action (optional). If you would like to have a specific set of users to authenticate against an Active Directory server (based on their UPN domain), you can create an LDAP action. This is sometimes useful for authenticating admins. For example, you could have users under com to use this LDAP action. This action can be created under Security → AAA – Application Traffic → Policies → Authentication → Advanced Policies → Actions → LDAP.
- Create the SAML actions (servers). You need to create a SAML action for each SAML IDP that you will utilize. These will have the details to “connect” Citrix Gateway to your SAML IDP, and they can be created under Security → AAA – Application Traffic → Policies → Authentication → Advanced Policies → Actions → SAML.
- Create an LDAP NON-authentication action. This will be used to extract the user claims from your Active Directory environment (which contains all your shadow accounts) after the users have been authenticated by their SAML IDP. This action can also be created under Security → AAA – Application Traffic → Policies → Authentication → Advanced Policies → Actions → LDAP. The difference here is that you will un-check the “Authentication” checkbox when creating the LDAP action.
- Create the authentication policies. With the actions already configured, you need to configure the authentication policies. In these policies, you will create the expressions that will define when one policy should be used over the others. For example, here you can configure the expressions to forward users under the com domain to your LDAP action; users under customerdomain1.com to use a SAML action; and customerdomain2.com to use another SAML action. Here, we will also create a couple of “NO_AUTHN” policies. These can be created under Security → AAA – Application Traffic → Policies → Authentication → Advanced Policies → Authentication Policies.
- Create the login schemas. For this configuration, we will need to create three login schemas to be used by our different policies: a “noschema” schema, a “username only” schema, and a “password only” schema. Each schema will require both a profile and a policy, and they can be created under Security AAA – Application Traffic > Login Schema.
- Configure your Policy Labels. These will let you link the different authentication policies and factors. They can be configured under Security > AAA – Application Traffic > Policies > Authentication > Advanced Policies > Policy Label.
- Create your AAA virtual server. As I mentioned before, we are not leveraging any gateway functionality here. We just need a Citrix ADC AAA vServer. This server also needs to be publicly accessible so that Citrix Workspace can reach it. You can create it under Security→ AAA – Application Traffic → Virtual Servers.
- Configure Citrix Workspace to use your ADC as an IDP. With your Citrix ADC AAA vServer created, we will now need to configure Citrix Workspace to use it as its IDP. Additionally, you will need to create a final OAUTH IDP policy on your ADC as part of this configuration. Please review this document for all the details and requirements to configure this portion.
- Configure your FAS server to work with Citrix Cloud services. With the above configuration, everything works, but you will be asked for user credentials when trying to launch a virtual app or desktop. So, our last step will be to configure the Federated Authentication Service (FAS) to work with Citrix Workspace. This document will give you all the details required to complete this configuration.
All these actions, policies, and schemas can get a little confusing. I created the following diagram to help you understand how your configuration should look like after you have completed the above steps, and what the expected behavior will be when a user accesses the environment. Click the image to view larger.
- When a user enters their Citrix Workspace URL on a web browser, the request will be forwarded to the Citrix AAA vServer. There will be an OAUTH IDP policy configured at Citrix ADC with the expression “TRUE.” This means all requests will be evaluated by this policy.
- The user will hit a NO_AUTHN policy and will be presented with the “usernameonly” login schema. The NO_AUTHN policy acts as a “place holder.” This might not seem to have any value in and of itself, but it actually provides the flexibility to make decisions through the authentication flow. NO_AUTHN policies will always return “success” as the authentication result.
- When the user enters their username (in UPN format), the UPN suffix will determine which authentication policy will be evaluated. In this example, domain1.com will be forwarded to an LDAP policy, domain2.com will be redirected to an Azure AD tenant, and domain3.com will be redirected to another Azure AD tenant; all of this will be based on the expressions used by each policy. Also notice that these authentication policies are bound to a “noschema” login schema. This means that nothing will be presented on the user’s web browser.
- If the user enters a username under domain1.com, they will be redirected to an LDAP policy (yes, a traditional LDAP policy). This policy evaluates to “TRUE,” which means that all users that get redirected to this policy will be affected by it. The login schema here will be “passwordonly,” meaning they will only need to enter their AD password because their username was captured in the previous factor.
- If the user enters a username under either domain2.com or domain3.com, they will be redirected to their respective Azure AD tenant for login. In this case, Azure will handle all the authentication, and this is outside the realm of the Citrix ADC. When the user is authenticated, they will be redirected back to Citrix Gateway.
- Once the user is redirected to Citrix Gateway, they will leverage another authentication factor, which is tied to an LDAP policy. However, this time it does not perform authentication. The purpose of this policy is to extract the claims required to authenticate the user back to Citrix Workspace. Notice that all SAML policies will be redirected to this single LDAP policy. Keep in mind that the users will not be presented with a login schema here, and they will not need to enter any information here. This process happens automatically. Also keep in mind that these LDAP no-authentication policies should only be used when the user has already been authenticated by another factor (like in this example), because they will always evaluate to success as the authentication result.
- The user claims are passed to the OAUTH IDP policy. This is a requirement for Citrix Workspace to accept the authentication from Citrix ADC.
- The user is redirected back to Citrix Workspace, and they can now access their resources.
Once this workflow is completed, the user will be back to Citrix Workspace. When they click on a virtual app or desktop, FAS will kick in and ensure SSO works, so users will not need to enter their credentials one more time. With this configuration, you are now able to leverage all the capabilities of Citrix Workspace like microapps, Citrix Content Collaboration, and SaaS apps, while ensuring your multiple authentication requirements are fulfilled.
Learn more about using Citrix ADC can be used as an IDP for Citrix Workspace.
