A technical introduction to Citrix Cloud Federated Authentication Service

What exactly is federation?

In its most basic form, federation is the interconnection of domains sans a trust relationship. Most commonly, trusts are used to link internal corporate domains, whereas federation is used to connect partners. For example, if Company A acquires Company B, a domain trust relationship would be the simplest and fastest way to enable new employees from Company B to access resources from the new parent company. Following the acquisition, Company A and Company B are now one big, happy family that trusts all the users and resources.

Federation, on the other hand, is typically used to link customers or partners that need access to specific resources but not full access. Enabling this limited access is consequently more complex because security must be maintained across organizational boundaries. 

Single sign-on (SSO) is a beneficial result of federation. From the user perspective, the user continues to use the home user domain account, e.g., [email protected], rather than having a second user account and password, e.g., [email protected], in the partner domain.

However, before we explore the Citrix-related capabilities, please keep in mind that that how vendors crisply define and implement federation and single sign-on may vary. This article focuses on how Citrix interprets federation.

How does Federated Authentication Service work?

Citrix introduced the predecessor to FAS for Workspace three years ago as part of XenDesktop 7.9. That same basic functionality is taken forward into FAS for Workspace with a few notable differences. Let’s start by discussing the basics of the on-prem FAS solution.

First, a partner company must have a Security Assertion Markup Language (SAML) identity provider (IdP) in place. SAML 2.0 is the current standard and is supported by Azure Active Directory (AAD), Active Directory Federation Services (ADFS), Google, Okta, and other identity providers. A SAML Authentication Policy is configured on the Citrix Application Delivery Controller (ADC; formerly NetScaler). This is sounding like alphabet soup—but hang in there just a little longer!

Long story short: SAML is used to validate the partner user login using the home domain credentials, e.g., [email protected]. But, the internal partner system doesn’t know what to do with that user login after that point, and that’s where Citrix FAS comes to the rescue.

When setting up Citrix Apps and Desktops (formerly XenApp and XenDesktop), the users who will be allowed to access those resources must be visible from that domain. You don’t have direct access to the mydomain.com user accounts, and that’s why shadow accounts bearing the same exact username need to be created in the partner domain.

But, how do you synchronize the user password? In a nutshell, you don’t. In conjunction with a Microsoft Certificate Authority (CA) server, Citrix FAS designates a virtual smartcard as the user password. For security, an AD GPO is applied to the Citrix infrastructure servers which designates the FAS server(s) and functionality. Thus, the user isn’t queried for a password again after successfully authenticating by means of the SAML policy.

The shadow account enabled by FAS is only interjected into the traffic flow if initial authentication is successful. This traffic flow also means that if the user account on the home domain is disabled or deleted, the shadow account can’t be used to access the partner resources; thus, the partner no longer shoulders the responsibility for disallowing a disabled or deleted user.

FAS for Workspace

There are a few notable differences associated with the new FAS for Workspace functionality. Not only is the admin interface more streamlined, but implementation is similar to downloading and installing a Cloud Connector. As part of the FAS for Workspace implementation, the Microsoft CA server is still required, as is configuration of the shadow accounts and an AD GPO.

Because you must configure the SAML Authentication Policy on the Citrix Gateway Service (NetScaler), it will be necessary to bring your own Gateway to Citrix Cloud. Although you can take advantage of Citrix hosting Workspace (cloud version of StoreFront), configuration and maintenance of the Citrix Gateway will be the responsibility of the enterprise. Similarly, the new Okta integration functionality that is currently in tech preview relies on FAS as a solution component.

If your enterprise is moving to Citrix Cloud for its general use cases and you need FAS, an integrated solution now exists. Citrix FAS for Workspace is a bit easier compared with on-premises FAS, because the FAS server(s) are directly linked within the Citrix Cloud admin interface.

Do you really need cloud FAS?

The primary use case for FAS is to eliminate the secondary prompt for credentials that a user would otherwise encounter; thus, a beneficial by-product of FAS is SSO. For example, if you have the need to enable partner accounts with SSO, SAML integration with FAS for Workspace is a viable solution.

However, there are several moving parts associated with this user authentication model that add complexity. There are numerous components touched during the user login, including the SAML configuration in Citrix Gateway, Workspace, AD GPO, AD shadow account, FAS server, CA server, and ultimately the VDA. For example, if the user successfully authenticates but the shadow account has not been created within AD, the user will not be able to access Citrix resources. As such, admins need to consider the creation, maintenance, and troubleshooting aspects of this technology.