Citrix Cloud Access Layer

Where should I put my Access Layer?

The access layer of your deployment relates to your StoreFront infrastructure, and NetScaler Gateway for internal and remote access respectively. These components facilitate access to Citrix resources in your environment. 

There are several ways of hosting the access layer components, but these can largely be simplified down to Citrix Managed (Cloud Storefront/WorkSpace Service and NetScaler Gateway Service) or Customer Managed (BYO Storefront and NetScaler).

In order to make an informed choice of how to deploy your access layer, you need to understand the benefits and drawbacks of the different scenarios and how they can impact on your overall solution.

Citrix Cloud StoreFront/Workspace Service

One of the main strengths of Citrix Cloud is its simplicity, and Storefront is a strong example of this. As soon as your service is enabled, StoreFront in the cloud just works. You have a few configuration options – such as basic branding and enabling NetScaler Gateway Service, but it’s effectively already configured for internal users and only needs an option toggling on to enable.

Simple is good, but it can also have some drawbacks, as with cloud hosted storefront.

Branding is still a bone of contention – more than a few customers would expect to be able to customise the look and feel of StoreFront beyond what is currently capable. There are basic controls available to modify basic colours and add logos, however if your requirements exceed this then unfortunately you’re stuck. There’s currently no capability to modify the CSS beyond what’s exposed in the control panel, and there’s certainly no ability to add custom JavaScript (which is entirely understandable!)

Many customers leverage the ability to inject custom JavaScript to add functionality to StoreFront that does not exist today – for example a pre or post-login EULA, or perhaps for maintenance notifications. If some of these capabilities are available in the cloud hosted StoreFront, then perhaps it would reduce the amount of customisation needed? Or perhaps we always like to tinker?

Today, Cloud StoreFront will only present resources from Citrix Cloud, however using the Citrix Workspace service you will have the option to integrate non-cloud deployments into the Citrix Cloud world. This is a nice touch and has the potential to help organisations making use of their hybrid rights while migrating to the cloud to present a consistent access point for all users.

Authentication

When you use Cloud StoreFront your users authenticate through your Citrix Cloud StoreFront site – typically https://companyname.xendesktop.net. This authentication request is passed through your Cloud Connectors and validated against your Active Directory (AD) using the machine account of your Cloud Connector OS’es. All very simple, and works quite nicely, however there’s a couple of challenges you may face with this.

The Security Team – In larger organisations this may be a team, or it may just be a conversation with the nominated security guy. However in terms of security considerations, where authentication happens can change the conversation completely. If the organisation is cloud-happy and has adopted other cloud solutions, this may be easier, but fundamentally when you are effectively delegating the authentication process to a cloud service this moves your security perimeter to the cloud service. Functionally this is fine, but it can be a harder pitch and receive more pointed questions.

Just using the XenApp and XenDesktop service is not typically a major conceptual challenge to security teams. Data resides where it always has, you’re just moving the brokering process to the cloud. Limited PII (personally identifiable information) is stored, and the encryption policies are acceptable to most. There’s even a page dedicated to security information here. Interestingly, the security page only references credential handling in the context of using a customer managed StoreFront instance.

In-fact, there’s no real security statement on how they handle user credentials when using Cloud StoreFront. Perhaps if you’ve had to look it up, then the answer is use customer managed?

Multi-factor Authentication – This was a major customer request in the early days of Citrix Cloud, but it has recently been solved! Sort of... Customers using the new Workspace service in Citrix Cloud (currently new customers and XenApp/Desktop Essentials) have the ability to use Azure AD to handle user authentication. This has been available for administrative access for a while, and broadly speaking the selection of Azure AD to integrate with is sound as this extends the opportunity to use any one of the many identity providers that integrate with Azure AD, so you can effectively choose your authentication poison.

This only takes you so far though. Azure AD will authenticate you and pass a SAML assertion back to Workspace service. So, at this point, Citrix Cloud has a SAML assertion to prove your identity – and this is enough to enumerate your Workspace entitlements. Then you launch something. Unfortunately, today, Windows doesn’t use SAML as a credential type, so you get another logon prompt – this time from the resource you’re connecting to. Double logons make for unhappy users.

In an on-premises world, this is where you would look to implement Federated Authentication Services (FAS) as it allows you to authenticate using a SAML identity provider (IDP) and then FAS does the translation into a Windows identity through the clever use of virtual smart cards.

Why can’t we do this with Citrix Cloud? FAS needs to integrate with StoreFront today. The smart money would suggest that at some stage this integration may appear in Citrix Cloud as a tick box option, allowing the integration with an on-premises FAS solution through the cloud connectors, however today that doesn’t exist. So if you require multi-factor authentication, you will have a double logon.

Remote Access (NetScaler Gateway Service)

NetScaler Gateway Service (NGS) is a fantastic concept, it allows you to enable remote access for your resources through Citrix Cloud with an on/off option. How simple is that? Now to support this we’ll accept my previous points and assume you’re happy using the Cloud Workspace Service/StoreFront. We must really as it’s not possible to use with on-premises StoreFront!

For it’s pure simplicity and reach, NGS deserves some consideration. There are numerous PoPs (Point of Presence) globally, meaning that even for smaller organisations, you have truly global reach.

However with simplicity comes compromise, and there are some limitations:

• Can’t mix and match – you either host your own NetScaler Gateways, use NGS, or have split deployments.
• Limited auditing – for most remote access solutions it’s a requirement to maintain logs of who has accessed remotely, what they accessed and how long for. Today that information is not exposed.
• No optimal Gateway routing – users will get directed to a nearby PoP, but which one is not controllable.
• Just ICA proxy – If you’re a tinkerer and like getting your NetScaler session policies “just right” this isn’t for you.
• Global on/off – remote access is enabled on a global level, so there’s no control today of who can access resources remotely as well as in the office.
• No integration with on-premises NetScaler Management and Analytics System (MAS) – if you use MAS to manage/monitor an internal/self-managed NetScaler deployment then you won’t get Gateway Insight or HDX Insight. Note: This is likely to be available as part of the Citrix Cloud MAS service though.
• No endpoint analysis – internet café? Come on in!

Resiliency

Citrix Cloud has a service level goal (note: goal - not agreement) of 99.9% uptime in a calendar month. Sounds good, but that equates as 43 minutes of downtime a month. We’re further constrained by the cloud conundrum which goes as follows:

• Before cloud: Move it all to the cloud then we won’t have to manage it!
• After cloud: It’s broken! Why can’t we just reboot it?

To be clear, this isn’t specific to Citrix Cloud by any means, but with any cloud service lack of control over planned or unplanned downtime is a serious consideration.

So what can we do about this? This subject has been one of my longstanding reasons for keeping the access layer on-premises. As of mid-late last year, your Citrix Cloud connectors have had Local Host Cache (LHC) in place.

If you’re not familiar with LHC, which has been available in the on-premises version for several releases now, LHC is where your delivery controllers - or in this case Cloud Connectors - have a cache of the data required to run your site. This means that if Citrix Cloud becomes unavailable – or you lose internet connectivity to the cloud service, if you host your access layer on-premises then using the LHC on the Cloud Connectors, users can continue launching resources.

Let’s look at two scenarios:

Of course, we should all be using NetScaler SD-WAN (software-defined wide-area network) and have abundant resiliency for our internet connectivity, so the second scenario should not happen. However, these are common stumbling points when moving customers to a cloud service – “what happens if it goes down?” With an on-premises access layer – in theory, nothing.

Summary

Overall, I’ve highlighted some of the limitations of cloud services, but this is by no means saying don’t consider them. There are customers where the simplicity and fast time to value will offset some of the compromises, or others may not see them as issues at all.

The purpose of this is to capture some of the considerations that need to be made when deciding what is best. Cloud is a delivery method, and not the only option available. Making the correct decision based on individual requirements will make sure everyone has the best user experience.

There is a lot of effort going into the development of both Workspace service and NetScaler Gateway service, so it is very much a decision that needs to be revisited as capabilities mature and new functionalities become available.