D iOS Mobile Device Management (MDM) Architecture

The following sections describe the Mobile Device Management (MDM) architecture and the device enrollment process:

D.1 Description - MDM Architecture

See the following sections:

D.1.1 MDM Command Cycle

The main purpose of MDM protocol is to send commands to iOS devices and process the results. MDM protocol is based on HTTPS (secure HTTP) which is used for exchanging XML messages called property lists (plists). For more information on plists, see here: http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/PropertyLists/Introduction/Introduction.html

In MDM protocol, the server does not push commands to the device. Instead, the server uses Apple Push Notification Service (APNS) to notify the device that the new commands are available.

Once device receives push notification, it queries MDM server for commands, executes them and sends the results back to MDM server. Figure D-1 shows how this works (for example, the command is GetDeviceInfo).

Figure D-1 Mobile Server MDM Architecture


The following steps explain how the MDM command cycle works:

  1. User logs in to mobile manager via web interface, finds their device and issues command to it. Refer to Section 7.11, "Using Mobile Manager to Manage iOS Devices" for information on how iOS device management is integrated with Mobile Manager. See Section 7.11.3, "iOS MDM Command Management" for information on command management.

  2. Mobile Server queues the command in the repository in command queue table.

    Note:

    The other commands for the same device may be already queued as well.

  3. Mobile Server contacts APNS Server via APNS Gateway and asks to send push notification to the device. APNS servers uniquely identify each device by a binary string called Device Token.

  4. The push notification wakes up the device.

  5. Device contacts Mobile Server to ask if a new command is available. In addition, the request can contain status and results of previous command already executed.

  6. Mobile Server retrieves next queued command from command queue and sends it to the device.

  7. The device executes the command and sends back to the server the command status - success or error (and error description) and the command result (which in our example would be device information).

    Mobile Server will store both command status and device information received in its repository. If there are more queued commands available for this device the next queued command is retrieved from the repository and sent to the device as in step 6.

  8. In Mobile Manager interface, the user can see the command history to verify that the command was executed successfully as well as device information which was retrieved by the command. For more information on Mobile Manager interface, see Section 7.11.2, "View iOS Device Information" and Section 7.11.3, "iOS MDM Command Management".

The cycle continues in this manner. The device executes commands, sends results to the server, asks for more commands and so on as long as more commands are available. If no more commands are available for this device, the device waits until another push notification is sent to it.

D.1.2 Additional Resources

On the internet, one of the most extensive documents provided on MDM is "MDM Protocol Reference". It describes in depth the interaction between MDM Server (in our case, Mobile Server), iOS devices and APNS. This information is helpful in case of any issues.

You need to have Enterprise account (iOS Developer Enterprise Program) to access MDM Protocol Reference document. Follow the steps below to get the document:

  • Go to the Apple Developer's Portal, Member Center, and login with your Enterprise account credentials.

  • Go to "Developer Centers" and click on "Mac" to go to Mac Developer's Center.

  • Click on "Downloads". At the bottom right, you will see a link titled "View All Downloads". Click on this link. You will be taken to "Downloads for Apple Developers" page.

  • Type "MDM" or "mobile" in the search box, and choose "Enter".

  • Download "Mobile Device Management Protocol Reference" (you see that to the right in the search results).

D.2 Device Enrollment Process

Devices enroll in MDM when the server delivers a special configuration profile to the device. This profile contains:

  • MDM Payload

    This is a special payload that tells the device that it will be managed by the MDM server. It contains server URL, push notification topic and other attributes. For more details on MDM payload, see MDM Protocol Reference.

  • Device Identity Certificate

    Mobile Server needs to authenticate connected devices. Since MDM is done automatically without user interaction, a usual user name/password authentication will not work. Mobile Server (as MDM Server) authenticates devices by their identity certificates. This is called Client Certificate Authentication and is done in the server's SSL layer.

    During enrollment, Mobile Server issues identity certificate for the device. Identity certificate is a X509 certificate/private key pair. It is included in the configuration profile in PKCS12 format. Each device certificate is signed by MDM CA (see Section 11.2.1, "Creating and Configuring Certificate Authority"). In addition, each certificate's Common Name (CN) contains unique device id (UDID).

    After enrollment, when device connects to Mobile Server as part of MDM, server's SSL layer will verify that the device certificate is trusted. In addition, after SSL connection is established, Mobile Server will verify that the certificate was signed by MDM CA and that the UDID stored in the certificate's CN matches UDID in the message (each MDM message from the device contains UDID). For more information, see MDM Protocol Reference.

The enrollment process follows OTA (Over The Air) Profile Delivery and Configuration outlined by Apple. See here:

https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/Introduction/Introduction.html

  • As described in Section 7.11.1, "iOS Device Enrollment", user provisions the device with MDM CA certificate. This is needed so that the device can accept certificates signed by this CA that will be provisioned in the following steps.

    In addition, as described in Section 11.2.2, "SSL Configuration for MDM," if the Mobile Server's SSL certificate was not obtained by trusted certificate authority, it should be signed by the MDM CA. In this case, having MDM CA certificate on the device will make the device trust the server's SSL certificate.

  • User enters their credentials and clicks on the "Enroll" button (see Section 7.11.1, "iOS Device Enrollment").

  • Mobile Server receives user's credentials and authenticates the user. If authentication is successful, a special configuration profile is sent to the device asking for the device's UDID. This profile also contains a special challenge token.

  • Device responds with its UDID and the challenge token it has received. The challenge token allows Mobile Server to associate UDID received with the user authenticated in the previous step. It also verifies that the server is talking to the device that was previously authenticated.

  • Mobile Server generates another identity certificate and sends a configuration profile containing this identity certificate to the device. This is not the same profile or identity certificate used by MDM described above. This special certificate/private key pair is required by OTA process. This OTA certificate is also signed by MDM CA.

  • Device sends back a response signed by the OTA private key received above. The response contains device's UDID.

  • Mobile Server receives the response above and verifies it's signature. If the verification is successful, MDM configuration profile containing MDM Payload and Device Identity Certificate will be sent to the device.

  • At this point the device is considered enrolled. A special command is be issued that will install all uploaded Configuration and Provisioning profiles to the device and will also install all published applications assigned to the device's user. In addition, device information will be collected and stored in the repository.

This process mostly follows the diagram of OTA enrollment. See here: https://developer.apple.com/library/ios/documentation/networkinginternet/conceptual/iphoneotaconfiguration/OTASecurity/OTASecurity.html#//apple_ref/doc/uid/TP40009505-CH3-SW1

One significant difference is that Mobile Server does not use SCEP protocol to sign identity certificates. Instead, the certificate/private key pair is generated by the Mobile Server and sent to the device as part of configuration profile in PKCS12 format. This is safe because all communication takes place over secure (SSL/HTTPS) connection.

D.3 Application Server Configuration for MDM

If you choose to enable MDM on your Mobile Server, additional configuration steps on your application server are performed. You do not need to perform these steps manually, they will be done automatically by the Mobile Server Repository Wizard (refer to step 15 of section 4.3.1.1, "Installation of the Mobile Server" of the Mobile Server Installation Guide). However, it may be useful to know the details in case you need to customize your Application Server.

By default, Mobile Server, when SSL is enabled, uses 1-way SSL protocol, where only the server presents its certificate to the client, but the client is not required to have or present certificate to the server (if client authentication is needed, it is done on an application level). However, MDM protocol uses 2-way SSL where both server and client present their certificates to each other, since the default way for the MDM client to be authenticated is via the client certificate.

Mobile Server supports both 2-way SSL (for iOS MDM) and 1-way SSL (for the rest of Mobile Server functionality) by using 2 different HTTPS listeners - one configured with 1-way SSL and the other with 2-way SSL. If you choose to enable MDM during Mobile Server installation, 2 SSL listeners will be configured each running on its own port. The default 1-way SSL listener is used for all Mobile Server functionality except iOS MDM (for example, sync, device management for non-Apple platforms, Mobile Manager access, and others). The 2-way SSL listener is used for iOS MDM exclusively.

The following sections show example configurations for supported application servers:

D.3.1 Glassfish

In Glassfish Administration Console, if you navigate under Configuration->Server Config->HTTP Service->Http Listeners, you see 3 HTTP listeners:

  • HTTP listener for regular HTTP access

  • HTTPS listener for SSL access to Mobile Server via 1-way SSL

  • HTTPS listener with 2-way SSL used for MDM protocol

In Figure D-2, they are named http-listener-1, http-listener-2 and mdm-listener respectively. All these listeners are running within the same server instance.

Figure D-2 Glassfish HTTP Listener Configuration


The "mdm-listener" is HTTPS listener with 2-way SSL enabled. You can see "Client Authentication" check-box selected in Figure D-3:

Figure D-3 Mdm-listener SSL Configuration


Note:

The "Key Store" and "Trust Store" are not specified as this listener uses default Glassfish keystore and truststore located under GLASSFISH_HOME\domains\DMS_Domain\config directory in files keystore.jks and cacerts.jks respectively. These are the same keystore and truststore used by the 1-way SSL listener (http-listener-2 in our example). The "mdm-listener" also uses the same server identity (server private key/certificate pair) as the 1-way SSL listener.

This is specified by the same certificate alias (NickName).

If you decide to change the location of your keystore, trustrore or server identity, be sure to specify the same for both SSL listeners.

D.3.2 WebLogic

In WebLogic, you can specify the main server ports called "Listen Port" and "SSL Listen Port" for HTTP and HTTPS respectively, as well as create additional HTTP or HTTPS listeners called "Channels" which are running within the same server instance.

In WebLogic Administration Console, if you navigate to your server's main configuration page (Environment->Servers, then click on your server), you will see SSL Listen Port specified, as in Figure D-4:

Figure D-4 WebLogic Server Configuration Page


This is the default 1-way SSL Listen Port used for all of Mobile Server functionality except iOS MDM. To see the 2-way SSL Listen Port used for iOS MDM, click on "Protocols" and then choose "Channels". You see a channel called "mdm-channel" configured for HTTPS protocol, as shown in Figure D-5:

Figure D-5 WebLogic Server Channels Page


This channel runs on different port from the main server's SSL Listen Port. If you click on the "mdm-channel" and then click on "Security" tab, you will see that it is configured for 2-way SSL, as in Figure D-6:

Figure D-6 Channel Security Configuration Page


Note:

The "Two Way SSL Enabled" and "Client Certificate Enforced" check-boxes are selected, which means that valid client certificate is required to access this port.

This channel uses the same keystore, truststore and server identity as on the main SSL listen port.