Organizations that leverage smart cards for authentication have struggled to reduce the number of PIN prompts required to securely log into published applications and desktop for years.
At Synergy last year, Citrix announced the Federated Authentication Service (FAS). The solution allows an external IdP to assert the identity of a user to the NetScaler. StoreFront will use that identity to request a user cert, via FAS, that will authenticate the user to published desktops and applications. Leveraging the internal side of this solution can allow organizations that use smart cards for authentication to achieve single sign-on (SSON) to published applications and desktops.
What is nice about this solution is that the communication between NetScaler and StoreFront is nothing new. The NetScaler is just asserting to StoreFront the identity of the user. This means that the internal side of the solution, StoreFront, FAS, and a MS CA, can function without the external IdP component. If a user can authenticate to the NetScaler or StoreFront via already available methods, i.e. smart card (CAC/PIV), then FAS can be leveraged to create a short term user certificate. A user can leverage this FAS provided user certificate for login to published applications or desktops without an additional PIN entry. Once in the session the physical smart card is still available for all typical uses, i.e. authentication to other services and S/MIME.
What does it look like?
To implement this solution, simply follow all the instructions for the StoreFront, FAS, and CA components, but ignore the IdP configurations on the NetScaler side. Continue to use the authentication methods on the VIP your organization leverages today. This will most likely be a client cert validation with an AD account lookup. The diagram below shows how there is no IdP component involved.
Notice also that it states Receiver for Web (RfW) and native Receiver. Being that there is no need to redirect to an IdP it is possible to use native Receivers that support smart card authentication. Also, since the FAS “magic” is all on the back-end, no special support is needed in the native Receivers.
Why does the user care?
While PINs are typically short compared to passwords, users hate having to enter them repeatedly. To give a whole picture of how many PIN prompts could be involved in a smart card login, let me do a quick review.
- PIN #1 – User authenticates to a NetScaler VIP that leverages client cert authentication. NetScaler validates this cert locally and organizations typically then do a lookup in Active Directory to confirm the account exists and is enabled.
- PIN #2 – User connects to an application or desktop. This triggers a new initial connection to the VIP and therefore will again authenticate the client certificate.
- PIN #3 – User logs into the actual published application or desktop.
That is three PIN entries to get into an application or desktop! PIN #2 could already be removed by creating a second VIP on the NetScaler for ICA proxy that will not leverage client cert authentication. FAS cannot remove PIN #2 as that communication (TLS handshake) is occurring on the external side of things and FAS only applies on the internal side. That typically left a user with two PIN entries to get into the system until now. FAS can cut out PIN #3 and the great thing is that it is not dependent on Receiver type and version or on complicated Kerberos configurations. The only potential hiccup tends to come from organizational policies. Make sure your organization’s policies allow the creation of user certificates. Some large enterprises may only allow certain groups to perform this function or may set guidelines on what can or cannot appear in those user certificates.
If you have any additional questions around this use case, just reach out to your Citrix engineer or leave a comment. If I missed anything I will update the article. Check out the product documentation for more information on FAS.
