2014/03/07
7 Mar, 2014

Managing iOS devices with WSO2 EMM - Part 1

  • Dilshan Edirisuriya
  • Software Engineer - WSO2
Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.

Table of contents

  1. Introduction
  2. Why enterprises need an EMM
  3. How an iOS device can be managed without an EMM
  4. Over the air enrollment (OTA enrollment)
  5. The need for MDM
  6. How MDM works
  7. How APNS fits into the MDM solution

Introduction

With the growth of mobile devices in enterprises, it’s imperative to efficiently manage these devices. Like laptops, desktops, etc. mobile devices too contain enterprise resources. Employees tends to browse enterprise data remotely using their mobile devices. Hence, IT managers would be faced with many challenges in managing employees’ mobile devices.

WSO2 Enterprise Mobility Platform (EMM) focuses on the above needs and address some of the problems faced in enterprises. WSO2 EMM offers management of iOS devices as it is the most enterprise-ready platform to date that meets organizational needs.

Why enterprises need an EMM

When it comes to managing devices in enterprises, administrators need to setup email accounts, VPN, WIFI access, LDAP etc. In addition, they need to ensure that enterprise data is secure. For this, administrators may also want to use passcode policies or disable some features on the device. If a device is lost or stolen, they will need to securely wipe the device as well to ensure enterprise data is not exposed to an external party. Based on users’ location or on a particular time of a given day, they would like to trigger or push some events based on policies as well. All of this will require a direct communicate through a mobile device with the help of an administrator rather than asking the user to fetch commands.

When it comes to organizations based on employees, it can be categorized as small- or large-scale enterprises. For small enterprises, one single admin will be able to manage each and every device, but when the number of employees increases, the number of devices will be high and it will be tedious to manage all the devices. For this, administrators would like to have a way to manage devices as a set or based on the users’ roles or designations.

Moreover, over a period of time, the above information tends to change. If a password of a WIFI changes, this would need to be reflected in all the devices; therefore, these types of changes would need to be tracked and addressed. Given the above needs, an enterprise must look into an enterprise mobility solution. The WSO2 EMM platform is a comprehensive suite that supports the above requirements.

How an iOS device can be managed without an EMM

iOS uses a specific type of profile known as configuration profiles. A configuration profile is a XML (plist DTD) file that contains the necessary management information for the iOS device. Here is a sample configuration profile.

  



   
      PayloadContent
      
         
            AutoJoin
            
            EncryptionType
            Any
            HIDDEN_NETWORK
            
            Password
            mypassword
            PayloadDescription
            Configures wireless connectivity settings.
            PayloadDisplayName
            WIFI Settings
            PayloadIdentifier
            com.wso2.wifi
            PayloadOrganization
            WSO2
            PayloadType
            com.apple.wifi.managed
            PayloadUUID
            432532532520-0434423432427432042
            PayloadVersion
            1
            ProxyType
            None
            SSID_STR
            wso2-guest
         
      
      PayloadDescription
      Configures wireless connectivity settings.
      PayloadDisplayName
      Configure WSO2 WIFI
      PayloadIdentifier
      com.wso2.profile.wifi
      PayloadOrganization
      WSO2
      PayloadRemovalDisallowed
      
      PayloadType
      Configuration
      PayloadUUID
      432453532-52375275235230573252
      PayloadVersion
      1
   

Each configuration profile can have multiple commands. As an example, one configuration profile can contain WIFI, LDAP, APN settings, etc. These individual sections are called payloads. Hence, one configuration profile may contain multiple payloads that will be executed at the device end at once. Subsequently, when removing a profile, it will remove all the payloads it embeds in the profile.

These configuration profiles are usually signed and encrypted. The profile installation is done within a public key infrastructure with an addition security, which will be discussed later. These profiles can be installed either through connecting your mobile device to a computer or enrollment can be done over the air, generally referred to as OTA enrollment.

This is a sample profile that can be seen when enrolling. There can be profiles for WIFI, LDAP, APN, VPN, etc. like this in order to install configurations.

There are few way you can execute a configuration profile in your device. The most common way is to use IPCU (iPhone configuration utility). Click here to download IPCU. In addition, you may run a server script at your server to push this into your phone, which will be discussed later. The execution of configuration profiles on your device will not be covered here as there are many resources and video tutorials available on the Internet.

Over the air enrollment (OTA enrollment)

Over the air profile delivery consists of authentication, enrollment, and device configuration. These are the steps it gets executed during the OTA enrollment.

  1. User navigates to the URL to load the page. This can be sent through a SMS, email or asking user to navigate to a specific link. The specified URL needs to be loaded in safari.
  2. Login web page is loaded to the user. The user needs to enter the username and password. You may validate this with your company LDAP, for instance, and reject it if it is invalid.
  3. If the authentication is successful, a profile will be sent to the device with an authentication challenge where it will be useful to trace the user in future.
  4. Then the user needs to install the profile, and post the installation, the mobile device will talk to the server and communicate the hardware information, such as UDID, IMEI, ICCID, OS version, and product model.
  5. Thereafter, the Simple Certificate Enrollment Protocol (SCEP) comes into picture. This is to transmit identity. In this phase, first the mobile device will generate a public/private key pair. Then the public key is sent to the server where the server needs to communicate with a certificate authority to get that certificate signing request (CSR) and generate the certificate.
  6. The server signs the certificate generated and keeps a copy and then sends the signed certificate over to the device.
  7. Now the device has the generated private key and the signed certificate (public key).
  8. From the server side it now has a copy of the public key that can be used to encrypt profiles.

Now, to push a custom profile, the server has to generate it and encrypt it using the public key. This automatically gets installed and apply the operations allowed in that. As an acknowledgement, the server will receive a notification upon success.

A full step-by-step guide to the OTA can be found here.

The need for MDM

With OTA enrollment profiles can be pushed over the air. However, in actual implementations, these configurations tend to change. As an example, credentials for LDAP may change, WIFI passwords may change, etc. In addition, as discussed above, the above SCEP (Simple Certificate Enrollment Protocol) generated certificates can also expire.

To incorporate these changes, one solution can be to ask the employee to re-enroll, which is not always practical with major changes. Mobile device management (MDM) was introduced to automate this.

MDM manages devices over the air as well as on demand. This works over WIFI and cellular networks. Hence, this is supported on iPhones, iPads as well as iPod touch. Moreover, another major advantage is transparency. Unlike above, users do not need to trigger event to download the profile and install. Profiles will be downloaded in the background without user consent. In MDM there are remote commands, operations, and queries where these will be used to control the employees’ devices.

The major technique Apple has introduced for MDM is the Apple push notification service (APNS); this drains the battery less and is also a push technique rather than polling the server at regular intervals.

How MDM works

MDM also needs to execute the same steps as discussed in the OTA enrollment section. The major difference is there is no custom profile associated with this. Instead of the custom profile generated, the MDM server will now create an MDM payload. These are the steps associated with the MDM enrollment.

  1. The flow will go as the OTA enrollment up to custom payload generation.
  2. Apart from generating the custom payload as mentioned in the OTA enrollment section, this will generate the MDM payload.
  3. After successful installation of MDM, the payload device will bind to your MDM server. For this, the SSL certificate will be validated at the device end.
  4. Then the device goes to idle state and will wait for Apple APNS notifications, which will be discussed later in this article.
  5. When receiving wake up calls from Apple APNS, the MDM server needs to query the pending operations at the server end and push payloads appropriately.

How APNS fits into the MDM solution

Apple APNS is a cloud messaging service hosted by Apple. In an MDM solution, all the messages are polled at the MDM server end where the MDM connects to the APNS to initiate the communication. APNS is responsible to wake up the device. Once the device is woken up, it will contact the MDM through a secure channel (HTTPS) over 3G or WIFI. Click here for further reading.

As discussed above, with the use of the MDM server, you can install the MDM profile. Thereafter, for each operation or for a set of operations, you can install payloads that have specific operations, such as WIFI, APN, LDAP, etc. These profiles become managed profiles since it is bound to the installed MDM profile. All managed profiles can be replaced or removed if it is allowed to be removed. If it has been blocked by adding permission to the profile, you cannot remove it. However, if the MDM profile is deleted, all other managed profiles under it will be removed as well.

Click here to download WSO2 EMM.
 

About Author

  • Dilshan Edirisuriya
  • Software Engineer
  • WSO2