I am pleased to announce a technology preview of SAML authentication for XenApp and XenDesktop running on top of version 7.8.
With the preview, SAML federated identity is enabled for logon, starting at NetScaler, through StoreFront and on to the workstation or terminal server VDA. The result is user access to XenApp and XenDesktop with identity rooted to an identity provider outside the XenApp/XenDesktop/Active Directory world.
How it works
The black boxes in the diagram are the technical preview. This includes:
- StoreFront code to communicate with User Credential Service for federated single sign-on operations
- Addition of a new service, the User Credential Service to map IdP identity into AD identity
- VDA enhancements (Terminal service and workstation) to log user on using UCS
Active Directory supports primarily two authentication types, 1) username/password and 2) smart card. In the SAML case, user authentication occurs on the identity provider, and the IdP statement of identity is used by StoreFront and the User Credential Service to log the user onto the domain. The process is initiated by the Receiver for web (RFWeb) or HTML5 Receiver access to NetScaler/StoreFront, which redirects to the identity provider, where user logon occurs. A SAML assertion is given to the NetScaler, signed by the IdP, indicating that the user is authenticated. NetScaler hands the single sign-on request to StoreFront, who uses the User Credential Service to complete the logon to XenApp/XenDesktop and Active Directory.
Once an AD user token exists, everything is as it has always been, the user gets their lists of apps and can launch them via standard Receiver and StoreFront operations.
Note that no update of Citrix Receiver is needed; this works with any web-based Citrix Receiver access to NetScaler/StoreFront. Since the SAML authentication originates in web actions, this technology is not applicable to the native receivers which logon to StoreFront outside of web protocols. Additionally, NetScaler has supported SAML authentication for a long time, so any recent version of NetScaler can support this technical preview.
Active Directory logon permits two techniques, username/password and smart card. The StoreFront and User Credential Service accept a SSO assertion based on the identity provider, and convert that into a network virtual smart card logon for active directory.
We could have done passwords and this would eliminate the need to include Microsoft Certificate Services in the puzzle, but that method would create headaches of having to hold the passwords and then manage synchronization. Using virtual smart card means that the UCS does not have to maintain state or a database of credentials.
During logon, UCS “mints” smart cards and then uses those smart cards to log users onto the domain. This works because the domain is configured to permit smart card authentication via Microsoft Certificate Services, and Certificate Services is configured to permit the UCS to perform certificate generation operations – yes, that is a big power. End answer is that the user performs a smart card logon to the domain, but the user never knows they have a smart card on the domain, they are just logged in once the IdD approves.
Is it product?
No! It is a technical preview, and no, I cannot comment as to when–or even if–it will ship. It is new technology that has some unanswered questions and with the preview, we can get these questions answered.
The questions include: Is the solution “right”? How long should the virtual smart cards be cached? What is the performance burden placed upon Certificate Services? How close is it to ready? What else should exist to assist usage of an identity provider outside of the domain?
Download links: The preview is available to Citrix partners and customers.
Start with a vanilla installation of XenApp or XenDesktop 7.8. Add Microsoft Certificate Services to enable Smart Card logon to the domain. CTX206156 has details on how to enable smart card authentication to the domain. Download the ZIP and extract. Start with the readme.txt and then User_Credential_Service_Administrator_Guide.pdf. Though the preview is small in size, there are 4 MSIs, one for each of the black boxes in the diagram above, two for the VDA 32/64. Note: the user interface for the UCS installer in the preview is pretty rough, but it works.
UCS – on its own server
The User Credential Service will run on any Server OS that supports XenDesktop 7.8. While the UCS could be run on the same computer as StoreFront, guidance is that the UCS should have its own dedicated server to assist with security boundaries.
Additionally, for fault tolerance the UCS can be “plural.” The StoreFront code that communicates with the UCS can fail over to backup UCSs when a primary is unavailable. This means that with a set of UCS servers, individual UCS can be powered off for maintenance at any time.
How long do the virtual smart cards live?
The network virtual smart card that converts from IdP stated identity to AD identity is technically needed only for the completion of the domain logon. It isn’t even needed while the user remains logged on. Minting a certificate though is an expensive operation so there is a trade off on number of logons vs. amount of minting to occur. The UCS caches the smart card certificates for a configurable period which defaults to 2 weeks.
We look forward to your feedback on what period should be the default and discussions to the tradeoffs vs. load placed on the UCS server and Certificate Services. There is no sharing of certificates between UCS servers, if a UCS server goes away, so does its certificate cache and the next time a user logs on, it will go to another UCS, who will create another certificate. This is expected. Eventually, the certificate generated by the first UCS will either timeout or get used again when that UCS comes back online.
Technical support and feedback
For comments and questions please use the tech preview feedback forum, link. The UCS dev and test teams will be monitoring the forum for the duration of the preview.