At Citrix Synergy 2016 last week, we announced the Federated Authentication Service for XenApp and XenDesktop 7.9, giving customers new levels of flexibility in authentication and identity handling.

Whether you are giving trusted partners federated access to in-house applications, adopting the latest password-free authentication methods, or putting a SAML Identity Provider at the heart of your access architecture, XenApp and XenDesktop now offer you more options than ever to say yes.

Let’s have a quick look at each of these examples.

B2B

One of the classic federation scenarios is, in order to access applications in your Active Directory environment, using a SAML Identity Provider to allow trusted partners to vouch for their employees when they come to NetScaler Gateway. XenApp is perfect for making those applications accessible externally while still maintaining control over the data and visibility of everything that happens.

By using federation, you don’t need to issue and manage passwords for your partners’ personnel, nor do you have to worry about how to lock down their access to just this entry point and those apps. The external users don’t get passwords for your environment and so can only come in via the gateway configured to accept them. Importantly, this puts responsibility for confirming the authenticity and status of the external users where it belongs, with the partners themselves.

B2B Federation with Federated Authentication Service

The way it works is pretty simple. NetScaler accepts SAML tokens, such as AD FS during browser logon, from the partner’s Identity Provider. A built-in Citrix SSO mechanism passes the identity to StoreFront, with NetScaler translating the SAML name to the corresponding AD account name. For a B2B scenario, this would be a shadow account created specifically to correspond to the external user, using an out-of-band process. StoreFront checks that the AD account is valid using a Kerberos mechanism and performs resource enumeration.

When an application is launched, StoreFront first contacts the Federated Authentication Service to ensure a credential is ready for the user account. FAS is configured with a list of StoreFront servers that are trusted to perform this step. The credential itself is a smart card certificate issued by the Enterprise CA for Active Directory for a private key that is owned by FAS. FAS returns a credential handle to StoreFront, which is passed to the VDA ready for the user to connect. When Receiver connects to the VDA, the credential handle is used to perform a smart card logon. Voilà! One full domain logon accomplished!

There’s lots more to say about the details of this process, as well as some unexpected bonus capabilities that it brings, but I’ll save those for another time. For now let’s cover the other two examples I mentioned.

Flexible Authentication: Go Password-Free!

In the flow above, you may have noticed that by the time FAS is invoked it doesn’t matter that it was a SAML logon for B2B. In fact, as long as StoreFront knows the user identity, it can use FAS to allow the domain logon. So, in the general case, you use any credential or auth method considered trusted to get in, and the system will securely provide the AD credential you need to do your work.

This is the ultimate in auth flexibility for Windows. And the beauty of FAS is that you are not compromising the capability of the Windows session if you chose to go password-free. With XenApp 6.5 and earlier, we had long offered the ability to do a domain logon without a password, but the mechanism was based on Kerberos delegation, which brought limitations that, in some cases, affected the service quality that could be delivered. For delivering B2B apps, that was not a problem, but for delivering a full desktop in most environments, particularly with complex AD deployments, it would be a concern.

Credential Service to separate backend from frontend

For consistency, I’ve labelled the service that performs user authentication as an IdP. In this case, the IdP is Citrix NetScaler—or even StoreFront itself—using its built-in Authentication Service.

The choice of auth methods is impressive today and set to grow; the intention is that you pick what works for you, and if you don’t see it available, ask. We already have a rich set of Auth SDKs and expansions are planned that will allow for even greater integration options in the future. Ultimately, the aim is that the authentication to NetScaler and StoreFront will be completely replaceable, whether using browsers or Receivers to connect.

IdP as the Core of IAM

I don’t need another picture for this case because in technical terms it is implied by the previous two. However, that shouldn’t detract from the significance of this final use case I want to mention. In years past, the preceding two use cases were the primary ones that customers brought up – and although they were and still are hugely significant to those individual customers, they are relatively niche cases when you look across our full customer base.

This one is different.

What I’m hearing increasingly today is that customers are embarking on a major change in the way they approach IT, which goes to the heart of how they manage identities and access. The premise is simple: since we need an IdP anyway to support the SaaS solutions that are rapidly becoming the preferred way to consume IT, why do we have another system that works differently and only for apps running on premises?

The answer is that the IdP becomes the central hub for authentication, for everyone, for all scenarios and for all resource access. (Well, that’s the direction anyway.) With FAS, you can now use the full power of XenApp and XenDesktop to bring all of the AD linked applications to the party. Even if your IdP logons are still primarily password-based for the time being, that will change at some point. By using FAS, you break the hard dependency that has existed until now between the credential for authenticating users and the credential that is needed to access AD resources.

Production-Ready

The FAS that ships with 7.9 is the production version of a Tech Preview we released in March, and the design is unchanged. As mentioned earlier, FAS relies on AD Certificate Services for the authority to generate secure certificate credentials that AD will accept for interactive session login. To Windows on the VDA, it’s as if the user has a normal smart card, but the private key is actually held securely on the FAS server (or in an HSM if you prefer) and is never in the user’s possession. Even the VDA never has possession, but is merely allowed to use the credential for logon, based on a FAS trust policy that can be audited.

One notable benefit from this approach is that the credentials can be cached for reuse to enhance performance and availability; another is that the certificate can be made available inside the session to Internet Explorer, Outlook, Chrome and other apps, to authenticate to network resources that use PKI. This feature is attractive to customers who use smart cards normally and need to allow equivalent access from devices that can’t support them, or for scenarios where the user isn’t allowed to possess one directly but needs access to systems that are protected with PKI authentication.

Feedback from customers and partners on the preview has been overwhelmingly positive; the common experience has been that it was easy to setup and “just works” so most questions have been about the scenarios it can support. That’s the type of question I love! We’ll dig into the individual scenarios in more detail in the coming weeks.

For now, I’ll finish with a quick update on what’s changed since the preview. The StoreFront and VDA add-ons are now integrated, so FAS itself is the only new component to think about. Lots of performance and robustness improvements have gone in, and for a v1 technology I am delighted with the results from our qualification testing. There is a difference compared with ordinary password based logon, but it is barely noticeable in normal use and within a factor of roughly two even in the worst case scenario at high load. We’ll have more to share soon on this and other aspects of production deployment and operation.

So, for everyone who has been asking “when is it shipping,” you now have the answer. Let us know about your experiences with it, and we look forward to helping you be successful, whatever your scenario and goal.

Citrix_Mobilize Windows_Banner 2_728x90_Static_Compete_F_072715