Cloud Gateway a Wrap-Up so far Part 2

Cloud Gateway a Wrap-Up so far Part 2

Table of Contents :

1 : Introduction
2 : Cloud Gateway architecture and components
3 : Cloud Gateway Mobile Experience (MDX) Technology
4 : Access Gateway : ICA Proxy, Clientless VPN and Secure Browse
5 : Native Receiver VS Receiver for Web
6 : ShareFile
7 : Conclusion

1 : Introduction

A few months ago I wrote a wrap-up about Citrix Cloud gateway and the upcoming 2.0 release, it’s one of the posts on my blog that gets the most hits so I thought I should write a follow-up. If you are new to Cloud Gateway you should read my previous wrap-up first to get a better understanding of the architecture. In this post I’m going through the new features of Cloud Gateway 2.0 and things I came across when setting up a demo environment.

2: Cloud Gateway architecture and components

Cloud Gateway consists of the following key components :

Appcontroller for User provisioning and SSO to Web (internal & external), SaaS and Native mobile apps
Citrix Receivers for connecting to Cloud Gateway

Optional components are :

Storefront Services for connecting to XenApp & XenDesktop back-end and providing access through Receiver for Web \ HTML5
Access Gateway Enterprise (Netscaler VPX/MPX) for external access to Cloud Gateway
Merchandising Services for controlled plugin distribution
– Integration with ShareFile infrastructure (Follow-Me-Data)

All optional components are included in the current Cloud Gateway Enterprise edition, except for the ShareFile subscription fee and the Access Gateway Platform license (universal licenses are included).

Citrix made a clever move by making Storefront services an optional component of Cloud Gateway, in this way they can sell Cloud Gateway as a separate stand-alone product, but on the other hand offer tight integration through Storefront for existing Citrix customers. I think the majority will use Cloud Gateway to extend their current Citrix back-end so Storefront will play a key role in most environments. In the use case that Storefront is not used, Citrix Receivers connects straight to Appcontroller or indirect through Access Gateway to Appcontroller.
Because I think a picture speaks 1000 words, I made a basic diagram of the Cloud Gateway components including ShareFile :

3 : Cloud Gateway Mobile Experience (MDX) Technology

Cloud Gateway MDX is the new marketing term for the features of Cloud Gateway, you can compare it with the marketing term HDX which stands for all the user experience optimizations around the ICA protocol. Let’s translate the MDX features into some more technical descriptions :

Feature Description
MDX App vault Sandboxed container controlled by Citrix Receiver which can be   remotely wiped
MDX Web Connect Embedded (mobile) web browser for secure browse connections
MDX Micro VPN Client side rewrite technology through Netscaler (Secure Browse)
MDX Policy Orchestration Management of (native) mobile apps through Appcontroller and   provides smart access like features

This MDX features gives IT control and security over their apps and data, but at the same time gives the users the freedom to control their own mobile device. I think this is best for both worlds and it prevents that users are going to work around the system.

MDX Ready Program
Citrix will initiate a MDX Ready partner program to validate apps for use with MDX, Citrix self will release an MDX native e-mail app which runs inside the App vault container and doesn’t expose itself to other apps on the mobile device improving security.

4: Access Gateway : ICA Proxy ,Clientless VPN and Secure Browse

Ok now things are getting very interesting, lets start with Access Gateway…

Access Gateway support
Cloud Gateway MDX features are only available in conjunction with Access Gateway Enterprise (Netscaler), there is no support for Access Gateway VPX (STD\ADV), in fact Citrix will shortly announce that Access Gateway VPX will go end-of-life. I wrote a blog about the future of Access Gateway a while ago, I wrote down my thoughts about why Citrix would support 2 products with almost identical features and why I think Access Gateway Enterprise (Netscaler) is the better product. At first I thought they should keep Access Gateway VPX as a replacement for Secure Gateway to provide basic connections and provide it for free, but then they would still need to support 2 products. If we look at the VPX appliances, we have a Netscaler VPX and the Access Gateway VPX, if we look at the MPX appliances we have the Netscaler MPX and Access Gateway Enterprise MPX, did you spot the outsider? Yep the big difference is that Access Gateway VPX is a very different product and the rest is Netscaler only licensed differently, if we look closer there is one edition missing :

Access Gateway Enterprise VPX
To replace Access Gateway VPX, there will be a Access Gateway Enterprise VPX edition (Finally!), this is a stripped down Netscaler which only gives you access to Access Gateway features. Citrix will also provide trade-ups and will adjust the pricing accordingly. So at the end we will have the following Access Gateway appliances left :

CAGEE Physical Appliance (MPX) CAGEE Virtual Appliance (VPX)
MPX 5500 Access Gateway Enterprise VPX
MPX 7500/9500
MPX 9700/10500/12500/15500

If you have a Netscaler MPX\VPX appliance you can enable the Access Gateway component and use it besides all other Netscaler functionality.

Access Gateway Policies and Profiles
The power of Access Gateway Enterprise IMHO is its flexible architecture, Access Gateway Enterprise fits like a glove in a lot of different environments and different access scenarios, because of its modular design. Since the Cloud Gateway release there are a lot of Access Gateway policies and profiles needed for different access scenarios and Receiver types, it will take some time to create and configuring them manually. To address this Citrix added a wizard (since version 10.0.69.6) which will create a baseline of policies and profiles for you. After the baseline is set you can still configure and adjust everything  according your needs, so the wizard helps you with the baseline but there will be no compromise on the flexibility afterwards.

ICA Proxy
ICA Proxy will enable you to do SSO pass-through to Webinterface, it doesn’t use Clientless VPN so you can use it on a VIP in basic mode. ICA Proxy provides the same functionality as Secure Gateway, which means basic ICA connections only. It is not documented anywhere but I can confirm that ICA proxy still works with Receiver for Web so if you want to provide basic access to Xenapp or XenDesktop you can use it just like with Webinterface. If you want more Cloud Gateway functionality you need Smart Access functionality like CVPN :

Clientless VPN
Clientless VPN (CVPN) has been around in Access Gateway for a while now, this Server side rewriting technology is great for providing access to OWA and other webapps behind Access Gateway. But the downside of CVPN is that not every webapp supports it, I can remember spending a lot of time in troubleshooting rewrite policies to intranet applications, but if it works it works pretty well and you don’t have to leverage a full VPN tunnel to allow access to webapps securely. CVPN in a Cloud Gateway setup is only used for traffic to Receiver for Web and traffic to Appcontroller, besides that CVPN is turned off so external Web\SaaS apps are not rewritten by Access Gateway but instead opened directly by Receiver (after SSO is done by Appcontroller), for internal webapps there is a new feature in Cloud Gateway :

Secure Browse
Secure Browse is one of the features I’m most excited about, instead of leveraging CVPN or a Full VPN tunnel, the Receiver for IPAD uses a secure channel between Receiver and Access Gateway called Secure Browse (or MDX Micro VPN). Secure Browse provides secure session based access to internal webapps behind Access Gateway. Another cool thing about Secure Browse is that it’s using an embedded webbrowser (MDX Web Connect) to render both internal and external webapps controlled by Appcontroller. Web Connect is totally controlled by Citrix Receiver and doesn’t expose critical data on the mobile device, Secure Browse will support any webapp because there is nothing rewritten by Access Gateway so no more troubleshooting of rewrite policies and broken links.
Secure Browse is currently only available on the Receiver for IPAD, other Receivers will still leverage a full VPN tunnel to provide access to internal webapps, but it’s expected that Citrix will extend Secure Browse to other Receivers as well.
I tested Secure Browse with OWA and SharePoint and it works really well, I can’t wait to see this functionality on other Receivers to.

5: Receiver for Web VS Native Receiver

In my previous wrap-up I talked about the difference between Receiver for Web and Webinterface, it’s clear that there are still features missing in Receiver for Web in comparison to Webinterface, but Citrix is closing this gap in upcoming releases of Storefront, in version 1.2 for example they already made some enhancements by separating Desktops from Apps and allowing user initiated desktop restarts. In this wrap-up I made a list of different functionality I noticed when using the Receiver for Web and the Native Receiver, please note that this list can quickly become out dated when updates of the Receivers are released.

Receiver for Web Native Receiver
User initiated Desktop restarts Yes No
Desktop viewer used Only for XenDesktop Also for XenApp published desktops
ShareFile integration Through web SSO Embedded in Receiver
Location aware with Web Beacons No* Yes
SSO through Appcontroller Yes Yes
Initiate full VPN by clicking app No Yes
Separated views for Apps and Desktops Yes No
Auto Subscribed applications Yes Yes
Auto launch applications Yes** No
Sticky (mandatory) applications Yes*** No

* When connecting with Receiver for Web through Access Gateway, the connection is always established through Access Gateway. In Webinterface it was possible to configure the connection method based on the IP range, Web beacons makes the decision based on internal and external URLs but this only works for the Native Receiver.

** Auto launch is default enabled in Receiver for Web when there is only 1 published desktop, if you have more desktops published you can manually edit the Default.htm.script.min.js file to define which one should be auto launched, expected is that auto launch will be enabled through a keyword  just like with auto subscribed applications

*** Sticky applications removes the delete cross when you hover over the app icon, to enable this you need to manually edit the Default.htm.script.min.js file, expected is that sticky apps will also be enabled through a keyword in the app description

So it’s clear that there are some functional differences between this Receivers, which one you should use depends on the functionality you want and the access scenario you need to provide.
For example : If you want ShareFile integration besides published apps go for the Native Receiver, if you want to provide a (kiosk) access model for published desktops go for Receiver for Web.

6: ShareFile

ShareFile is another element of Cloud Gateway i’m very excited about, if you integrate ShareFile into your Cloud Gateway setup, you can give your users a true follow-me-data experience on every device without compromising on security. IT can remotely wipe data from lost or stolen devices and data is stored in an encrypted format to further improve security. Data is also available offline with ShareFile sync. Besides follow-me-data ShareFile enables users to share (large) files with colleagues, but also with external contacts, you can trace who downloads files or control the amount of downloads. Besides that file versioning, drive mappings and Outlook integration are all features that are available with ShareFile. Some elements are comparable with other follow-me-data solutions like RES Hyper-Drive, which is also a nice on-premise follow-me-data concept from RES Software, because ShareFile is now part of Citrix there is a tight integration with Cloud Gateway and the Receivers.

ShareFile and Appcontroller
You can establish a SAML trust between Appcontroller and ShareFile to provide account provisioning, in this way your AD users are automatically created inside ShareFile, I noticed in my demo environment that  this process sometimes take a while, so before you start troubleshooting wait a bit. Also be sure to create a role for ShareFile users inside Appcontroller, because if you select All Users, every AD account will be created in ShareFile consuming all your licenses (learned this the hard way). What’s very cool is that you can configure ShareFile to only allow authentication through Appcontroller and SSO, in this way users cannot connect to ShareFile directly further improving security. If SSO to ShareFile isn’t working please check the time settings on Appcontroller, if it’s a few minutes of SSO doesn’t work correctly, it took me some time to figure that out.

ShareFile Storage Zones
With ShareFile storage zones you can control where data is stored, a Storage Zone can also be On-Premise, more awesomeness will come in feature releases of Storage Zones when we can connect ShareFile to existing CIFS shares and SharePoint environments, imagine the possibilities!

7: Conclusion

Congratulations! you made it to the conclusion section 😉 sorry it was a bit of lengthy post but that’s because Cloud Gateway and surrounding technologies are a big deal and there is so much to cover. Cloud Gateway lets you aggregate and secure Cloud services and On-premise services into one logical logon point with the same look and feel on every device. Integration plays the key role in Cloud Gateway. I’m very excited about Cloud Gateway 2.0 and the upcoming features, on one hand its giving IT the flexibility and control over data, apps and security they need and on the other hand gives the user freedom to choose whichever device they like to use, I really think this concept is the future and I think it will change the traditional desktop as we know it today.

If you want to be notified when Part 3 or another blogpost comes out, subscribe to my blog site or follow me on Twitter : @bramwolfs

Please note that the information in this blog is provided as is without warranty of any kind, it is a mix of own research and information provided by Citrix. Some information is based on speculations and predictions.

Advertisements

3 comments on “Cloud Gateway a Wrap-Up so far Part 2

  1. Question about you getting Secure Browse to work? I am configured an AppController for Saas apps which works fine however I am trying to get our internal Intranet site working and AppController rejects the website URL.

    I put in http://intranet and click Save it errors with ‘Enter Missing Information’. When I put in http://intranet.com (which address doesn’t work or exist) it saves successfully.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s