Cloud computing… A bunch of computing resources delivering some kind of service over the network, typically being the Internet. It includes, or should include, on demand self-service capabilities like: requesting access to certain applications and data, automated account provisioning or perhaps the ability to manage your own VM’s. It’s hot and everybody wants a piece! Services like Google Apps, Amazon cloud drive and Microsoft’s Azure, to name a few, are examples that do just that. These are the cloud solutions often referred to when the Cloud hype gets mentioned. But what about an on-premises solution, building your own private cloud which can be safely accessed from anywhere?!
Before I continue… No, I’m not a Citrix employee, I don’t own stocks nor do I benefit in any other way, I’m just a fan :-) Note: although it’s mostly me, I do use a quote (as per Citrix) here and there from Citrix.com
What is it?
The Citrix CloudGateway gives you the ability the build your own on-premises private Cloud solution including secure remote access through the Citrix Access Gateway. It includes AppController which lets you securely deliver Web and Software-as-a-Service (SaaS) applications, all mobile and HTML5 based applications and integrated ShareFile-based data (will be discussed in some more detail later on). This makes the Appcontroller one of the key components of the CloudGateway suite. It’s a virtual appliance that runs on Citrix XenServer and is managed with Citrix XenCenter. You can also install AppController on VMware ESXi.
When it comes down to web, mobile and SaaS applications you need to take in consideration that most of the security features like: MDX, Micro VPN’s, application specific policies etc… are only applicable if you use either a iOS or Android device with the exception of HTML5 based apps those use MDX as well, just read on :-)
In combination with StoreFront it integrates access to XenApp and XenDesktop resources as well as providing a single place to provision, manage and update enterprise applications and a single point of access for all users. StoreFront enables you to create centralized enterprise stores (your own private App-Store) to deliver desktops, applications and other resources to users on any device, anywhere. It also takes care of (internal) authentication and provides resource delivery services for Citrix Receiver. Besides that it also empowers users with self service capabilities when it comes to selecting and requesting applications.
It also fully supports BYOD through technologies like: Citrix Receiver, MDX and Micro-VPN’s, and with the recent acquisition of Zenprise, which specializes in mobile device and application management, it will be interesting to see which route they’ll follow.
There are a few different ways in which it can be deployed or integrated and some cool features like MDX, Micro-VPN’s, Identity based provisioning, Follow me Data and a few more that need or can be configured. Let’s start with an overview of the individual components that make up the CloudGateway as shown above and an overview of the two editions available.
Editions as per Citrix
Enables XenApp and XenDesktop customers to deliver all their Windows apps and desktops to any device through a self-service app store. CloudGateway Express is available at no additional charge to all XenApp and XenDesktop customers.
It includes the same capabilities as the Express edition plus it delivers enterprise mobility with a solution that enables enterprises to securely deliver mobile, web and Windows apps and ShareFile data to any user on any device.
As per Citrix:
Citrix Receiver comes in two different forms.
Receiver for Web is browser-accessible and hosted by the StoreFront server. It facilitates the user’s initial session until a native Receiver is installed and activated. Receiver for Web is also used for ongoing sessions on platforms that do not support a native Receiver, or when it cannot be installed for some reason.
In contrast, native Receiver is installed client software that can be launched from a user’s start menu (or equivalent) and is designed to take advantage of platform specific capabilities to deliver the best possible user experience.
The Citrix Access Gateway takes care of secure remote access from anywhere, it gives IT administrators a single point to manage access control and limit actions within sessions based on both user identity and the endpoint device. With HDX SmartAccess it can provide endpoint analyses of the client device, it can look at the type of device, configuration settings, operational status and version of available security software. These properties are then evaluated against policies governing access to backend resources.
When using the Citrix Receiver for Web, external connections are distinguished by a remote flag on the HTTP header of the users initial connection that indicates that the traffic is coming from the Access Gateway. The Store service, when using StoreFront, performs a so called ‘remote flag call- back’ in which it confirms that the Access Gateway is indeed the source from where the connection originated (well, not really, but you get the point).
The policy that evaluates as true is communicated to the Store service as part of the Access Gateway response to the ‘remote flag call-back’. This information is subsequently consumed by content controllers (e.g., AppController), XenDesktop, and Citrix XenApp to determine which specific resources a user should be allowed to access and at what level.
The next-generationof the Web interface. It provides a set of service interfaces for use by Receiver that enable access to AppController, XenDesktop and XenApp published applications. From a network perspective, the traffic generated is almost the same as with the Web interface. The biggest change is the technologie architecture. It is modularized for maximum flexibility as opposed to the monolithic design of Web Interface. In fact, most of the Web interface code is re-used within the StoreFront design. It consists of five sub elements:
Reciever for web
This hosted Receiver separates the display logic for browser-based users from the remaining StoreFront services.
When users authenticate at StoreFront, either externally through the Access Gateway or internally, the authentication service forwards the users credentials to other components as well creating a single sign-on experience. AppController lets you configure SSO on an individual and per application basis.
StoreFront lets you create your own private App-Store. The Store service takes care of the application enumeration process. It queries content providers like the XML service for XenDesktop and XenApp resources as well as AppController for access to ShareFile data, Web, SaaS, and mobile applications.
Users can easily self-select (through receiver) their applications from the corporate approved list and access these apps as they roam between devices.
It also looks after the application launch process. In the case of XenDesktop or XenApp resources this happens as we are used too with Web interface. Through information obtained via the XML Broker service an ICA file is created and forwarded to the Receiver on the client device. Internal users connect directly, external users through the Access Gateway. Resources managed by AppController are launched differently, which will be discussed shortly.
A dedicated container within StoreFront for maintaining essential Access Gateway configuration settings. Here you can configure Access Gateway general settings like the display name used for the Access Gateway deployment to connect to App-stores, URL or virtual server of the user logon point, logon type etc…
Help determine if a connection is made internal or externally. This way the system knows whether to include the Access Gateway information into the ICA file as part of the connection. Native receivers use beacons. If Receiver can ping an internal address only accessible from the corporate network (beacon) it knows it’s internal. If it cannot reach the internal beacon but can reach an external beacon, like Yahoo.com, it knows it’s external and will let StoreFront know.
Receiver for web makes use of remote flags in the HTTP header of a user’s initial connection to indicate if it’s made via the Access Gateway or not, see the Access Gateway section earlier.
Let’s you securely deliver Web and Software-as-a-Service (SaaS) applications, all mobile and HTML5 based applications and integrated ShareFile-based data. The communication with StoreFront, SSO and application enumeration, is the same as between StoreFront and XenDesktop (the XML Broker service). However, the application launch process works a bit differently.
When a launch request is received from StoreFront, AppController first verifies that there is a credential mapping for the user / app pair in question, assuming there is, AppController authenticates the user providing an SSO experience. Remember that the StoreFront authentication service forwards the users credentials to other components, AppController being one of them. As mentioned, AppController lets you configure SSO on an individual and per application basis, this is done by configuring and activating the corresponding SSO connector from the AppController catalog.
Assuming that an iOS or Android device is used… Internal web and SaaS applications leverage @WorkWeb (this also applies to HTML5 based applications by the way) and communication is secured through Micro VPN’s, more on this in a bit. When a mobile application gets launched, including HTML5 based apps, it leverages MDX, again only if an iOS or Android device / app is used, which puts it in the MDX vault on the users devices offering several advantages. More on MDX below. ShareFile data is a whole other story on itself, we’ll briefly touch the subject in some detail somewhere near the bottom.
For external web or SaaS appications all this is followed by a 302 redirect that establishes a direct connection between the user’s browser (which still is @WorkWeb but without the Micro VPN) and the desired service from AppController. From this point forward, CloudGateway is no longer in the communication path if it was to begin with. Because @WorkWeb is also used (again, if it is an iOS or Android device) for external Web and or SaaS applications it still opperates from within the MDX Vault, althoug no Micro VPN is used this method still offfers some additional security.
AppController automated provisioning
Most applications with an SSO connector also have corresponding provisioning connectors which support a range of tasks like: creating new application user accounts, disabling and enabling existing accounts, resetting passwords etc… First there needs to be an application to group mapping in AppController, meaning an Active Directory user security group per application. With this in place, when users are added to the Active Directory user group AppController can automatically provision new application user accounts. Vice versa when users are removed from the Active Directory user group the user account will also be automatically removed from the application.
App request and automated workflow
As per Citrix: in some instances, applications will be included in the Receiver list of available apps for example, based on the user’s role even though the user does not yet have accounts for those apps. Such apps will be accompanied by a Request button in the Receiver interface. Clicking on the button triggers an administrator-defined workflow that routes the app account request to designated approvers.
These workflows are powered by, in most cases, Active Directory or some other form of authoritative data store to discover all details about users, such as their titles, roles and relative positions in the organization’s hierarchy.
Although this is another subject all on its own, it is worth mentioning (and more than that) that ShareFile can be fully integrated with AppController letting you access your corporate and personal data wherever and whenever you want even on multiple devices if you like, hence the term: Follow-me data, one of Citrix’s marketing instruments.
Users again have the advantage of the SSO feature as discussed earlier which, if ShareFile is integrated, also gives them direct access to their data with the ability of editing and saving the data included. Data can be stored securely in the Citrix cloud (Amazon web services) or on-premises in your own data center through the use of StorageZones. ShareFile has a central control system for maintaining user account information and brokering services, all this information is securely stored in Citrix managed data centers, as opposed to cloud or on-premises storage this is not a choice. To give you more of an idea, here’s an overview I found on Citrix.com.
Mobile app management
Mobile applications will also be displayed in Receiver alongside the other Windows, web and SaaS applications and work in the same way. One minor exception is that a user-initiated un-subscription will not adhere to the follow-me concept because in the mobile realm, removing an app from one device does not necessarily convey the desire to remove it from all of a user’s other mobile devices.
Citrix Receiver can be made aware (during the enumeration process) of essential information related to specific applications, such as, policy data, URL for package download, device type requirements and more. All Mobile applications (inlcuding the @Work apps) are ‘wrapped’ before being published, this is done by an easy to use integrated toolkit. This process injects the code needed for certain management tasks and policy enforcements once the applications are running on the users device, more info: support.citrix.com/proddocs/topic/cloudgateway/clg-appwrap-landing-page-con.html
iOS App signing
Be aware that you will need to get your Mobile iOS apps signed by Apple before you will be legally allowed to distribute them to your users according to Apple’s EULA. Before you wrap an iOS app, download and install the iOS Distribution Provisioning Profile and Distribution Certificate to your computer, both first need to be requested (and thus signed) with Apple. As per Citrix: Any app that runs on a physical iOS device (other than apps in the Apple App Store) needs to be signed with a provisioning profile and a corresponding certificate. There are two kinds of profiles: Enterprise: allows you to run the app on unlimited devices and Ad Hoc: allows you to run the app on up to about 100 devices. Provisioning files and certificates may differ depending on the app, consult with Apple about the kinds of profiles and certificates Apple may require for a particular app. By the way, this whole process is free of charge!
For Android Mobile applications the process is much the same only Android doesn’t have a strict EULA policy like iOS has. Applications do need to be digitally signed as well see: support.citrix.com/proddocs/topic/apppreptool/clg-appwrap-sys-reqs-con.html for more info. On the same page you will also find some more information regarding the signing process of iOS applications as well.
All the MDX specific features are targeted at iOS and Android devices (HTML5 based apps can cuse MDX as well), including the @WorkMail and @WorkWeb applications which are specifically designed for iOS and Android use and therefore also reside in the MDX Vault, read on below.
My personal favorite! MDX enables management, security and control over web, SaaS, mobile applications and data, including HTML5 apps. Using MDX you can host both business and personal applications together on the same device without them being able to interfere with each other. It also provides IT administrators with the ability to manage business apps completely separate from all personal applications and data.
It separates all corporate web, SaaS, HTML5 based and mobile applications including data from personal applications on the same device by placing them in the MDX vault. This enables IT administrators to manage only the business apps instead of the whole device providing the end users with the freedom they want! All apps in the vault can be secured with encryption, remotely locked and wiped by IT.
Ensures that all MDX enabled applications can interact with each other. MDX enabled apps only open other MDX enabled apps, for example, a link clicked in @WorkMail automatically opens @WorkWeb and not Safari. Using MDX interapp IT can also create and enforce policies to control communication between applications such as allowing cut and paste actions between MDX enabled apps but not to applications not protected by MDX.
With MDX access IT administrators can configure policy based access and management control over all web, SaaS, HTML5 based and mobile applications. It can check the type of device or network you are working on, the device passcode, jail broken policies and more. Based on the rules you define apps will either start or they won’t. Providing you with an extra layer of security keeping your business apps and data as secure as possible. It also offers, and it’s a first, an application specific VPN connection to your corporates internal network, called a Micro VPN, used for internal web and SaaS applications. This way a so called device wide VPN, opening up access to the whole network isn’t necessary. Again, increased security! This way only the web or mobile application has a direct connection into the corporate network.
Secure mobile productivity
CloudGateway includes two new native mobile applications that make use of MDX security features: Citrix @WorkMail and @WorkWeb.
@WorkMail is a new native iOS and Android E-mail, calendar and contacts app. It leverages the security features in CloudGateway through MDX. Using ShareFile users can attach, save and open documents and other attachments as well as open URL’s or send calendar invites with GoToMeeting using the free/busy information of attendees provided by @WorkMail. It supports ActiveSync and Exchange and offers security features, such as encryption, for email, attachments and contacts.
@WorkWeb (a.k.a. MDX Web Connect browser) is a browser for iOS and Android devices. It leverages MDX technologies, such as MDX Access to create a dedicated VPN tunnel for accessing a company’s internal network and encryption for the browser cache, bookmarks, cookies and history to ensure that users can access all of their websites, including external websites with sensitive information.
Besides the complete package which consists of the Access Gateway, StoreFront and AppController, there are a few other ways in which AppController and or the Access Gateway can be deployed or integrated. And because a picture says more than a thousand words… click to enlarge.
Deploying AppController for internal users:
Deploying AppController for external users:
AppController and an existing Web interface:
That just about raps it up, what do you think? Cloud worthy, holds potential, useless, whatever..? Perhaps it has already been implemented by some? If so, please share your experience, did you ran into any issues, did it all went smoothly?
Bas van Kaam ©
Reference materials used: Citrix.com and the Citrix E-Docs site