Introduction to the Mobile Access Gateway

Introduction to the Mobile Access Gateway This document provides an overview of the AirWatch Mobile Access Gateway (MAG) architecture and security and explains how to enable MAG functionality in the AirWatch Admin Console. For MAG system requirements and installation instructions, please refer to the AirWatch Mobile Access Gateway Installation Guide. The AirWatch Mobile Access Gateway (MAG) provides a secure and effective method for individual applications to access corporate resources. When your employees access internal content from their mobile devices, the MAG acts as a secure relay between the device and enterprise system. The MAG is able to authenticate and encrypt traffic from individual applications on compliant devices to the back-end system they are trying to reach. In This Guide Before You Begin This section covers topics and prerequisites you should familiarize yourself with so you can get the most out of using this guide. Architecture and Security This section provides sample architectures for both SaaS and on-prem deployments and explains how the MAG performs HTTP/HTTPS tunneling. MAG Security & Certificates This section explains how certificates are generated and used to facilitate communication between devices and the MAG. MAG System Settings This sections details some of the AirWatch Admin Console MAG settings you can configure once it is installed. What Business Challenge Does the MAG Address? Whether it s for a global sales staff member, a traveling executive, or any other employee trying to check work email from outside of the office, mobile access to enterprise resources is becoming a necessity in today s work environments. This access extends to far more than just corporate email access. Your employees may require access to: Corporate intranet sites to keep up with internal announcements and collaborate with other employees. Internal content repositories such as SharePoint or corporate network shares to access the latest presentations, board books, or financial records. Other internal resources to gather Business Intelligence (BI) data, provide secure transactions, or fetch the most recent corporate updates from mobile applications. Information Technology (IT) departments are not only faced with the challenges of providing widespread levels of access to their users; they must also address the many security concerns that arise by providing this level of access to a fleet of devices. Since many of the most common solutions such as SSL-VPN technology do not provide the ability to selectively provide access between different applications on mobile devices. Key concerns are the loss of corporate data into personal apps and the possibility of malware infecting your corporate network. To ensure that data-loss protection and infrastructure health are maintained, IT requires a solution to provide mobile access in a way that can: Provide access-control so that only approved and compliant devices may access the corporate network. Provide access to only business applications to prevent data-leakage as a result of unauthorized personal applications accessing corporate resources. View real-time updates of when and where mobile devices are accessing enterprise resources. 1

How Does the MAG Help With This Challenge? The AirWatch MAG makes it possible to meet all of the requirements of employee access and IT security by providing a secure and effective method for individual applications to access corporate resources. By serving as a relay between your mobile devices and enterprise systems, the MAG is able to authenticate and encrypt traffic from individual applications on compliant devices to the back-end systems they are trying to reach. Use the MAG to access the following internal resources over HTTP(S): Internal document repositories and content through AirWatch Secure Content Locker. Internal websites and web applications through AirWatch Browser. Any other enterprise system accessible over HTTP(S) from your business applications through AirWatch App Tunneling. In addition, you can use the MAG's Per App VPN functionality for ios devices to allow both internal and public applications to access corporate resources in your internal network. The App Tunnel mobile app supports both TCP traffic and HTTP(S) traffic. The MAG also provides a number of benefits over other mobile access technologies. Application-Level Mobile Access By providing access through conventional technologies such as SSL-VPNs, devices gain full access to enterprise resources regardless of whether resources are accessed within a business, personal or malicious application. This introduces the possibility of data-loss when sensitive data is collected in personal applications and potentially distributed. Additionally, these technologies put IT at the mercy of end users who may unknowingly have malicious applications on their devices that could compromise an entire network. The MAG includes the AirWatch App Tunnel, which allows individual applications to authenticate and securely communicate with back-end resources over HTTP(S) in the case of App Wrapping and HTTP(S) or TCP in the case of Per App VPN. By enabling the App Tunnel for select business or public applications, you can be certain that unauthorized, personal or malicious apps do not have access to your network. This also makes the MAG a vital component to enable BYOD in your organization. By separating access between personal and business applications and data on your device, a device can be thought of as having two owners: an employee with business needs and an ordinary user with personal needs. This means the MAG will allow business applications to access your enterprise systems over HTTP(S) but keep end-user personal applications segregated by preventing enterprise access. Further still, Per App VPN enables end-users to use some of their favorite public apps to access internal resources while ensuring all traffic remains secure. 2

Application-Level Management Visibility and Access Control Because the MAG is architected as part of AirWatch Enterprise Mobility Management (EMM), administrators can view an intuitive and action-oriented display of mobile access information directly from the AirWatch Admin Console. This puts your system administrators in the position to manage proactively instead of reactively by easily identifying at-risk devices and managing exceptions. Since the MAG operates as a centrally managed entry point for devices to access corporate content and data over HTTP(S), access can automatically be configured by device, app and user based on corporate policy. Mobile Access Gateway Technologies and Features The MAG utilizes cutting-edge mobile application technologies in order to meet all the requirements of your users and IT. In general, each application that securely accesses corporate resources over HTTP(S) and through the MAG takes advantage of either Per App VPN or AirWatch App Wrapping, In-App Certificate Authentication and Encryption, and ultimately the AirWatch App Tunnel. In-App Certificate Authentication and Encryption When wrapping an application for corporate access through the MAG, AirWatch will automatically deploy a unique X.509 certificate to every installed application on every enrolled device. This certificate can then be used for mutual authentication and encryption between the application and the MAG. Unlike other certificates used for Wi-Fi, VPN and email authentication, this certificate resides within the application sandbox and can only be leveraged within the specific app itself. By utilizing this certificate, the MAG can identify and allow only approved, recognized apps to communicate with corporate systems over HTTP(S), or, in the case of Per App VPN, TCP and HTTP(S). AirWatch App Tunneling You can enable app tunneling in a couple of ways: through App Wrapping for your internal apps only, or through Per App VPN for public or internal ios apps only. App Wrapping App Wrapping provides a simple and effective form of application tunneling to establish a direct, secure connection between your business applications and internal corporate systems that are accessible over HTTP(S). By wrapping your business applications, embedding a certificate for authentication and encryption, and proxying your HTTP(S) application 3

traffic through the MAG, you can dramatically empower your applications with the data stored within your internal systems that are accessible over HTTP(S) without any code-change or development effort. The workflow to enable and utilize app wrapping in AirWatch is shown below. 1. Start by wrapping your enterprise application through the AirWatch Admin Console and enable the proxy all traffic through the MAG feature. 2. AirWatch will embed a unique digital certificate and proxy settings that direct all traffic to the MAG within your application and deploy the app to your fleet. 3. As the wrapped application fetches data, only business applications on approved, compliant devices will be authenticated for enterprise system access by only trusting messages signed with one of the unique X.509 certificate deployed from AirWatch for app tunneling. 4. Once granted access, the MAG will provide a secure encrypted tunnel for access between business applications and enterprise systems by serving as a proxy between the two over SSL encrypted HTTPS. Per App VPN Per App VPN allows both internal and public applications to access corporate resources that reside in your secure internal network. It does this using ios 7 s Per App VPN capabilities, which lets certain ios applications access internal resources on an app-by-app basis. This means that some apps can be enabled to access internal resources while others are left unable to communicate with your backend systems. This is different from app tunneling via App Wrapping in that is supports both TCP and HTTP(S) traffic and works for both public and internally developed apps. However, for internal apps the App Tunnel App acts as an alternative option only if the sole requirement is tunneling into the internal network. Otherwise, you will need to use App Wrapping to take advantage of features such as integrated authentication, geofencing, offline access control, and so on. The workflow to enable and utilize Per App VPN in AirWatch is shown below. 1. First, you will need to configure the app settings in the AirWatch Admin Console on the MAG Settings page. More details will be available when the app is released. 2. Next, you will need to create an AirWatch App Tunnel VPN profile for your ios devices. Here is where you can select the Per-App VPN check box to enable Per App VPN for apps, and/or the Safari Domains from which end-users can connect to internal resources. 3. Finally, you will need to push any apps that you want to enable with Per App VPN functionality from the AirWatch Admin Console. A Use VPN check box on the Deployment tab of the Add Application page tells the application to use Per App VPN. MAG Use Cases with AirWatch Apps The MAG enables access to your internal resources that are available over HTTP(S), for example, internal websites or content repositories. Secure Internal Browsing By using the MAG in conjunction with AirWatch Browser, you can provide secure internal browsing to any intranet site and web application that resides within your network. Because AirWatch Browser has been architected with application tunneling capabilities, all it takes to enable mobile access to your internal websites is to enable a setting from the AirWatch Admin Console. By doing so, AirWatch Browser establishes a trust with MAG using an AirWatch-issued certificate and accesses internal websites by proxying traffic through the MAG over SSL encrypted HTTPS. This means 4

that IT can not only provide greater levels of access to their mobile users, but also remain confident that security is not compromised by encrypting traffic, remembering history, disabling copy/paste, defining cookie acceptance and more. Secure Internal Content Access Finally, the MAG can also be used with AirWatch Secure Content Locker to allow your users to securely access content from an internal repository using the same application tunneling technologies. This means that your users can remotely access their documentation, financial documents, board books, and more directly from SharePoint or an internal fileshare. As files are added or updated within your existing content repository, the changes will immediately be reflected in Secure Content Locker, and users will only be granted access to their approved files and folders based on the existing access control lists defined in your internal repository. Using the MAG with Secure Content Locker allows you to provide unmatched levels of access to your corporate content without sacrificing security. Secure Email Access You can push the AirWatch Inbox as a public app and use the AirWatch App Tunnel for ios mobile app to connect to a backend Exchange server that is not public facing. This effectively secures the traffic between the AirWatch Inbox and the backend Exchange server. 5

Before You Begin Overview This section covers topics and prerequisites you should familiarize yourself with so you can get the most out of using this guide. In This Section Requirements See a list of requirements you must meet before configuring MAG settings in the AirWatch Admin Console. Note: For the hardware, software, and network requirements needed to install the MAG, please refer to the AirWatch Mobile Access Gateway Installation Guide. Recommended Reading See a list of additional guides that contain supplemental information about MAG. Getting Started See additional considerations you should know before you begin. Requirements To perform any of the actions mentioned in the MAG System Settings section, you must first install the MAG. For instructions on how to do this, and for the hardware, software, and network requirements needed to install the MAG, please refer to the AirWatch Mobile Access Gateway Installation Guide. Recommended Reading AirWatch Mobile Access Gateway Installation Guide This guide explains how to install the MAG and includes the necessary system requirements. 6

Getting Started Supported Configurations Use MAG in the following configurations: Sitting behind a network load balancer for high availability deployments. Supporting SSL offloading. Using HTTP or HTTPS transport. Supporting HTTP authentication of traffic from a network reverse proxy or Web Application Firewall (WAF). Acting as a relay (MAGR) node to secure traffic through multiple network zones. Definitions Note the following distinction between on-premise and SaaS deployments: On-premise refers to AirWatch deployments where your organization hosts all AirWatch components and servers on its internal networks. SaaS refers to AirWatch deployments where certain AirWatch components, such as the Console and API servers, are hosted in the cloud. 7

Architecture & Security Overview The MAG is a service you can install on physical or virtual servers running Windows 2008 R2 or higher. Install MAG on an on-premise server in either a DMZ or secured internal network zone. Additionally, you have the option to install multiple MAGs for load balancing and/or in a relay-endpoint configuration for additional security. When a managed device queries one of the systems with which it integrates, AirWatch App Tunnel encrypts the request and sends it to the MAG to make a local request to the back-end enterprise system. MAG secures the traffic between your devices and the corporate network using unique X.509 certificates for mutual authentication and encryption. In This Section Deployment Models See the various deployment models for both SaaS and on-premise deployments. HTTP and HTTPS Tunneling See descriptions about how MAG directs traffic using either HTTP or HTTPS tunneling. Deployment Models SaaS Deployments Basic Endpoint In a basic endpoint deployment, the MAG is behind a WAF and resides on an internal network. The traffic from your managed devices is sent securely over an HTTP or HTTPS transport and its message level is signed using unique X.509 certificates. All MAG deployment configurations support load balancing and reverse proxy. DMZ Relay In a DMZ relay deployment, the MAG is in the DMZ and internal network as either an endpoint or MAG relay because organizations do not have a WAF or reverse proxy. The diagram below illustrates the relay configuration in a SaaS configuration. This model allows requests from your managed devices to securely connect to the MAG relay node 8

in the DMZ. It also allows for the relay node to further send traffic to an internal MAG endpoint node for back-end system integration. All traffic requests to the MAG relay and MAG endpoint are signed using unique X.509 certificates. It is setup for either HTTP or HTTPS transport. All MAG deployment configurations support load balancing and reverse proxy. On-Premise (non-saas) Deployments Single Mobile Access Gateway In a basic endpoint deployment, the MAG is behind a WAF and resides on an internal network. The traffic from your managed devices is sent securely over an HTTP or HTTPS transport and its message level is signed using unique X.509 certificates. All MAG deployment configurations support load balancing and reverse proxy. Relay for Multiple Network Zones In a multiple network zones deployment, the MAG is used in an on-premise (non- SaaS) environment to integrate with internal systems from a DMZ server connection. All MAG deployment configurations support load balancing and reverse proxy. 9

HTTP and HTTPS Tunneling For both SaaS and on-premise configurations, MAG utilizes one of the following methods for connecting to internal sites such as a SharePoint or wiki site: HTTP Tunneling MAG traffic is sent over both ports 2010 and 2020 using the conventions outlined under HTTP Tunneling. The benefit of this method is you get better network performance, since HTTPS traffic is not being encrypted twice in transit. HTTPS Tunneling MAG traffic is sent over one port either port 2010 or 2020 using the conventions outlined under HTTPS Tunneling. The benefit of this method is you only have to open two ports (2010 or 2020, in addition to 443) as opposed to all three. In essence, both options offer comparable security. In addition, for both methods, general access to internal resources (for example, files on a server) is done over 443 with an SSL connection. These two methods are detailed below: HTTP Tunneling With this method, you will utilize both port 2010 and 2020 to filter HTTP and HTTPS traffic, as described below. Port 2010 (Utilizing an HTTP tunnel for HTTPS traffic) When accessing an end site, such as SharePoint, an intranet, or wiki site on an internal network, that is HTTPS, a device application will request that MAG make a secure tunnel to the site it is trying to reach. The 2010 port is used for HTTP "CONNECT" tunneling of end site traffic all the way up to the final destination server. This will be used only when the end site is HTTPS, so that a secure tunnel is established between the browser and actual site end-to-end. The MAG will not be aware of the traffic inside that tunnel. MAG makes sure the tunnel is certificate authenticated with an end device s certificate and that all traffic is encrypted inside of the tunnel. For example, if a user accesses an internal wiki site, https://<internalsite>.wiki.com, the traffic is encapsulated within an HTTP tunnel and sent over port 2010. The connection terminates once it reaches the MAG and is sent over to the internal resource as HTTPS. 10

Port 2020 (HTTP traffic encrypted and sent as HTTPS) This port is used for MAG to act as a reverse proxy, in case the end site you are accessing is HTTP. A request to access the end site comes over as HTTPS to MAG, so that the entire traffic is encrypted up to the MAG over the Internet. Essentially, the MAG performs a port reversal: HTTP Traffic is encrypted and sent on the HTTPS port. HTTPS traffic is encapsulated within an HTTP tunnel and sent to the HTTP port. Any kind of communication is authenticated using the certificates generated by the root certificate, which is unique to every AirWatch instance. For example, if a user accesses the same wiki site, except at http://<internalsite>.wiki.com, the HTTP traffic is encrypted and authenticated using certificates and sent over port 2020. This connection terminates once it reaches the MAG and is sent over to the internal resource as HTTP. Note: When utilizing HTTP Tunneling, you will specify port values for both the Default HTTP Port and Default HTTPS Port in Console Settings, as described in the Mobile Access Gateway Installation Guide. Refer to the diagram below to see an illustration of these separate ports and their usage: HTTPS Tunneling With this method, you will utilize one port either 2010 or 2020 to filter both HTTP and HTTPS traffic through an encrypted HTTPS tunnel, as described below. Port 2010 or Port 2020 (Traffic sent through an HTTPS tunnel) When accessing an end site, such as SharePoint, an intranet or wiki site, traffic is sent through an HTTPS tunnel, regardless of whether the end site is HTTP or HTTPS. For example, if a user accesses a wiki site, whether it is http://<internalsite>.wiki.com or https://<internalsite>.wiki.com, the traffic is encrypted in an HTTPS tunnel and sent over either port 2010 or port 2020 whichever you have configured. This connection terminates once it reaches the MAG and is sent over to the internal resource as either HTTP or HTTPS. Note: When utilizing HTTPS Tunneling, you will enter '0' for Default HTTP Port and either 2010 or 2020 for the Default HTTPS Port in System Configuration, as described in the Mobile Access Gateway Installation Guide. Refer to the diagram below to see an illustration of these separate ports and their usage: 11

12

MAG Security & Certificates Overview This section outlines how the certificates used to authenticate communication among the AirWatch Admin Console, MAG, and end-user devices. In This Section Initial Setup See the process flow that occurs upon initial setup of the MAG. Certificate Integration Cycle See the process flow for how certificates are created and routed when using the MAG. Initial Setup 1. MAG connects to the AirWatch API and authenticates with the AirWatch Admin Console Username and Password. Traffic requests are SSL encrypted using HTTPS. Setup authorization is restricted to admin accounts with a role enabled for an MAG setup role (see preliminary steps). 2. AirWatch generates a unique identity certificate pair for both the AirWatch and MAG environments. The AirWatch certificate is unique to the group selected in the AirWatch Admin Console. Both certificates are generated from a trusted AirWatch root. 3. AirWatch sends the unique certificates and trust configuration back to the MAG server over HTTPS. The MAG configuration trusts only messages signed from the AirWatch environment. This trust is unique per group. Note: Any additional MAG servers set up in the same AirWatch group as part of a highly available (HA) loadbalanced configuration are issued the same unique MAG certificate. For more information about high availability, please refer to the AirWatch High Availability and Disaster Recovery Guide. Certificate Integration Cycle 1. AirWatch generates Device Root Certificates that are unique to every instance during the installation process. The Device Root Certificate is used to generate client certificates for each of the applications and devices. 2. The certificate an application uses to authenticate with the MAG is only provided after the application attempts to authenticate with the AirWatch enrollment credentials for the first time. 3. MAG gets the chain during installation. The MAG installer is dynamically packaged and picks these certificates at the time of download. 13

Communication between the MAG and device-side applications (such as AirWatch Browser, Secure Content Locker, wrapped applications using app tunneling) is secured by using the identity certificates generated during installation. These identity certs are child certificates of the Secure Channel Root certificate. 4. MAG makes an outbound call to the AWCM/API server to receive updated details on the device and certificates. The following details are exchanged during this process: DeviceUid, CertThumbprint, applicationbundleid, EnrollmentStatus, compliancestatus. 5. MAG maintains a list of devices and certificates and only authenticates communication if it sees a certificate it recognizes. X.509 (version 3) digitally signed client certificates are used for authentication. 14

MAG System Settings Overview Once the MAG is installed you can configure a number of advanced settings and enable MAG functionality in the AirWatch Browser and Secure Content Locker apps. Doing so will ensure all HTTP(S) traffic for the specified apps/content repositories is routed through the MAG. In This Section Configuring Advanced MAG Settings See the additional MAG settings you can configure after it is installed. Configuring AirWatch Browser with MAG See how to enable the AirWatch Browser to leverage the MAG and secure your internal network from the public Internet. Configuring Content Repository Access through the Secure Content Locker with MAG See how to enable access to an integrated content repository through the MAG using the AirWatch Secure Content Locker. Configuring an External App Repository with MAG See where to configure authentication settings for your external app catalog, if applicable. Configuring Advanced MAG Settings A number of advanced MAG settings let you change the log levels and outbound proxy behavior between a MAG relay and API/AWCM servers from the AirWatch Admin Console. 1. Navigate to Groups & Settings All Settings System Enterprise Integration Mobile Access Gateway and select the Advanced tab. 2. Configure the following settings: a. Enable API and AWCM outbound calls via proxy Enable this option if the communication between the MAG relay and AirWatch API or AWCM is through an outbound proxy. b. Show detailed errors Enable this option to ensure client applications (for example, AirWatch Secure Browser) are informed when the MAG fails to authenticate a device. c. Log Level Set the appropriate logging level for the MAG service, which will determine how much data is reported to the MAG.log files. 3. Select Save. Note: After modifying any of these settings, you must restart the MAG service for the changes to take effect. 15

Configuring AirWatch Browser with MAG Following MAG installation, configure the AirWatch Admin Console for communication with the MAG by enabling proxy mode to protect your network from the public Internet: 1. Navigate to Groups & Settings All Settings Apps Settings and Policies Security Policies. 2. Select Enabled for App Tunnel and specify the App Tunnel Mode as Mobile Access Gateway. 3. Optionally, enable the split MAG Tunnel for ios devices by entering URLs into the App Tunnel Domains field. If a URL that is about to be invoked contains a domain that matches the list in the settings, this URL request goes through the MAG. If the URL's domain does not match the domain in the list, it should go directly to the Internet. Leave the text box empty to send all requests through the MAG. 4. Select Save. 5. Ensure the AirWatch Browser is using the Shared SDK profiles for ios and Android by navigating to Groups & Settings All Settings Apps AirWatch Browser and selecting them under SDK Profile. Configuring Content Repository Access through the Secure Content Locker with MAG The Content Repository allows administrators to link to folders, network drives or SharePoint directories containing various documents for upload into the Secure Content Locker. You can do this by: 1. Navigate to Content Settings Content Repository. 2. Select Add. 3. Enter a Name relevant to the content directory. 4. Provide the Type of content repository with which you wish to integrate and the full path to Link to the directory location rather than the root domain. For example, input http://sharepoint/corporate/documents instead of http://sharepoint. 5. Enter Organization Group and User details as necessary. 6. Enable Access via MAG to communicate with a SharePoint directory within the corporate network. Complete this action if the file system or SharePoint drive is not accessible from AirWatch server s domain. 7. Complete the remaining settings. Note: When setting up repository access via the MAG, the entire folder hierarchy will not be synced when you add the repository. By default, repository content will sync only up to two folder levels. Other sub-folders will sync as the AirWatch Admin Console or devices request them. On the Console, the sync occurs when performing a manual sync action inside of a sub-folder. On the device, the sync occurs when an end user navigates to a sub-folder. Note: On some locked down environments where the MAG server does not have permission to impersonate the calling user to check access to a shared network folder, end users will receive an Impersonation Failed message when trying to access a content repository using their credentials. To resolve this issue, administrators need to add Allow log on locally and Log on as a service to each user in the Local Security Policies on the MAG server under Security Settings > Local Policies > User Rights Assignment > "Allow log on locally". This needs to be done for all users that will be accessing content so they can successfully invoke user impersonation from the MAG Windows Server to the Windows Network File Share. 16

Note: For more information about how to integrate with content repositories, refer to the AirWatch MCM Guide. Configuring an External App Repository with MAG Traffic to and from the External App Repository, if used, also flows through the MAG though no additional configuration by the end user is required. To verify External App Repository credentials to ensure access, navigate to Groups & Settings All Settings Apps Catalog External App Repository. 17