Federated Authentication Service architectures overview
Introduction
The Federated Authentication Service (FAS) is a Citrix component that integrates with your Active Directory certificate authority (CA), allowing users to be seamlessly authenticated within a Citrix environment. This document describes the various authentication architectures that are appropriate for your deployment.
When enabled, the FAS delegates user authentication decisions to trusted StoreFront servers. StoreFront has a comprehensive set of built-in authentication options built around modern web technologies, and is easily extensible using the StoreFront SDK or third-party IIS plug-ins. The basic design goal is that any authentication technology that can authenticate a user to a website can now be used to log in to a Citrix XenApp or XenDesktop deployment.
This document covers some example top-level deployment architectures, in increasing complexity.
- Internal deployment
- NetScaler Gateway deployment
- ADFS SAML
- B2B account mapping
- Windows 10 Azure AD join
Links are provided to related FAS articles. For all architectures, the Federated Authentication Service article is the primary reference for setting up the FAS.
How it works
The FAS is authorized to issue smart card class certificates automatically on behalf of Active Directory users authenticated by StoreFront. This uses similar APIs to tools that allow administrators to provision physical smart cards.
When a user is brokered to a Citrix XenApp or XenDesktop Virtual Delivery Agent (VDA), the certificate is attached to the machine, and the Windows domain sees the logon as a standard smart card authentication.
Internal deployment
The FAS allows users to securely authenticate to StoreFront using various authentication options, including Kerberos single sign-on (SSO), and connect through to a fully authenticated Citrix HDX session.
This allows Windows authentication without prompts to enter user credentials or smart card PINs, and without using “saved password management” features such as the SSO service. This can be used to replace the Kerberos Constrained Delegation logon features available in earlier versions of XenApp.
All users have access to public key infrastructure (PKI) certificates within their session, regardless of whether they log on to the endpoint devices with a smart card. This allows a smooth migration to two-factor authentication models, even from devices such as smartphones and tablets that do not have a smart card reader.
This deployment adds a server running the FAS, which is authorized to issue smart card class certificates on behalf of users. These certificates are then used to log on to user sessions in a Citrix HDX environment as if a smart card logon was used.
The XenApp or XenDesktop environment must be configured in a similar manner as the smart card logon, which is documented in CTX206156.
In an existing deployment, this usually involves only ensuring that a domain-joined Microsoft certificate authority (CA) is available, and that domain controllers have been assigned domain controller certificates. (See the “Issuing Domain Controller Certificates” section in CTX206156.)
Related information:
- Keys can be stored in a Hardware Security Module (HSM) or built-in Trusted Platform Module (TPM). For details, see the Federated Authentication Service private key protection article.
- The Federated Authentication Service article describes how to install and configure the FAS.
NetScaler Gateway deployment
The NetScaler deployment is similar to the internal deployment, but adds Citrix NetScaler Gateway paired with StoreFront, moving the primary point of authentication to NetScaler itself. Citrix NetScaler includes sophisticated authentication and authorization options that can be used to secure remote access to a company’s websites.
This deployment can be used to avoid multiple PIN prompts that occur when authenticating first to NetScaler and then logging in to a user session. It also allows the use of advanced NetScaler authentication technologies without requiring AD passwords or smart cards.
Note:
There are no differences if the back end resource is either Windows VDA or Linux VDA.
The XenApp or XenDesktop environment must be configured in a similar manner as the smart card logon, which is documented in CTX206156.
In an existing deployment, this usually involves only ensuring that a domain-joined Microsoft certificate authority (CA) is available, and that domain controllers have been assigned Domain Controller certificates. (See the “Issuing Domain Controller Certificates” section in CTX206156).
When configuring NetScaler as the primary authentication system, ensure that all connections between NetScaler and StoreFront are secured with TLS. In particular, ensure that the Callback Url is correctly configured to point to the NetScaler server, as this can be used to authenticate the NetScaler server in this deployment.
Related information:
- To configure NetScaler Gateway, see How to Configure NetScaler Gateway 10.5 to use with StoreFront 3.6 and XenDesktop 7.6.
- The Federated Authentication Service article describes how to install and configure the FAS.
ADFS SAML deployment
A key NetScaler authentication technology allows integration with Microsoft ADFS, which can act as a SAML Identity Provider (IdP). A SAML assertion is a cryptographically signed XML block issued by a trusted IdP that authorizes a user to log on to a computer system. It means that the FAS server now allows the authentication of a user to be delegated to the Microsoft ADFS server (or other SAML-aware IdP).
ADFS is commonly used to securely authenticate users to corporate resources remotely over the Internet. For example, it is often used for Office 365 integration.
Related information:
- The Federated Authentication Service ADFS deployment article contains details.
- The Federated Authentication Service article describes how to install and configure FAS.
- The NetScaler Gateway deployment section in this article contains configuration considerations.
B2B account mapping
If two companies want to use each other’s computer systems, a common option is to set up an Active Directory Federation Service (ADFS) server with a trust relation. This allows users in one company to seamlessly authenticate into another company’s Active Directory (AD) environment. When logging on, each user uses their own company logon credentials. ADFS automatically maps this to a “shadow account” in the peer company’s AD environment.
Related information:
- The Federated Authentication Service article describes how to install and configure FAS.
Windows 10 Azure AD Join
Windows 10 introduced the concept of “Azure AD Join,” which is conceptually similar to traditional Windows domain join but targeted at “over the internet” scenarios. This works well with laptops and tablets. As with traditional Windows domain join, Azure AD has functionality to allow SSO models for company websites and resources. These are all “Internet aware,” so will work from any Internet connected location, not just the office LAN.
This deployment is an example where there is effectively no concept of “end users in the office.” Laptops are enrolled and authenticate entirely over the Internet using modern Azure AD features.
The infrastructure in this deployment can run anywhere an IP address is available: on-premises, hosted provider, Azure, or another cloud provider. The Azure AD Connect synchronizer will automatically connect to Azure AD. The example graphic uses Azure VMs for simplicity.
Related information:
- The Federated Authentication Service article describes how to install and configure FAS.
- The Federated Authentication Service Azure AD integration article contains details.