How to develop mobile device management application in iOS

Question

I have many iOS devices in my company and I have to manage them centrally, so we tried to use third party MDM applications for eg: airwatch but it is very costly.

W

Answer 1

iOS MDM is clientless protocol. So, you develop a server, but you don't develop a client application for it. Actually, there is a client app, but it's developed by Apple and built into operation system.

So, your server will send a command, built-in MDM client will receive and execute it.

Generally speaking, if you want to develop MDM server, you need to register into Enterprise Developer Program and get MDM documentation.

A documentation here it'll help you create your own mdm solution from scratch I believe

Reference

Some other helpful links on developing mdm server Ref 1, Ref 2

Here is the link to MDM tag in stack overflow browsing this will help you get answer for most of the FAQ

If you want any clarification in getting this done comment below here. I'm ready to help you

Update

Overview

• In order to manage device we can configure it manually using iOS Settings app

  But it has scalability problem and its a lot of work configuring every device manually and it requires physical access

• so apple introduced iPCU(iPhone Configuration Utility) tool using which we can create configuration profiles(.moibleconfig) and we can install it Over USB or OTA(Over the Air)

  But it requires User interaction

• so apple introduced MDM services for iOS it does not require user interaction we can do so many things very easily without user consent such as remote lock, unlock,wipe,configuring mail etc...

  MDM is basically a protocol using which you can manage devices remotely.

  Overview

  Changes we make in iOS settings app are stored in /var/mobile/Library/ConfigurationProfiles as .plist files along with the profiles(.plist) installed by iPCU and MDM

  Lets say we are turning off the App Store app installation in the device so to do that we'll go Settings->Restrictions and turn off the App Store installation so allowAppInstallation would be turned to false in its configuration(.plist) lets say we are configuring the app installation using iPCU as well as MDM then iOS we'll take most restrictive one when conflict comes between the configuration profiles of iOS settings app profile,iPCU profile and MDM profile.

  iOS creates a profile called ProfileTruth.plist by merging all this profiles and iOS works with respect to this plist

  MDM basically consists of these things

  • iOS Device

    It can be any device that runs using iOS.All iOS device has a inbuilt MDM client.It will act upon the instruction fed by MDM server

  • MDM Server

    Its basically a application that is hosted on application or web server and it feeds the command to MDM client that is hosted on iOS Device

  • Signalling

    This a mechanism that invokes the mdm client from Server in our case it is APNS

Herewith I have attached MDM workflow

1. MDM server sends notification using APNS
2. APNS delivers it to device
3. Built in MDM client connects to MDM Server
4. Upon connection MDM Server sends back the commands queued up to the client and client acts upon the commands sent by MDM server and replies with appropriate acknowledgement to the MDM server

Steps to create simple MDM

MDM Enrolment

It starts with MDM enrolment profile

In iPCU you can create a new profile choosing MDM payload

Check In URL

 The is the URL where enrolment of the device happens. 

 i.e upon installation of profile on the device MDM client sends necessary information to the MDM server which MDM server will use to authenticate and connect with the device 

Server URL

 Once the MDM server got the enrolment information.It can use the information to connect the device using APNS and when MDM client wakes up it connects with the URL mentioned in Server URL and Server can send back the queued commands to MDM client

Topic

Enter the subject of APNS certificate that's going to be used for MDM.

Identity

It can be any certificate generated by Certificate Assistant but important thing is it has to be signed by globally trusted CA or in the case of self signed CA the CA has be installed in the device.

Install the MDM Enrolment Profile

You can install this profile using Over the Air or Over the USB

As soon as it installs, iOS Built-in client will connect to MDM server(Check In URL) with Authenticate request

PUT: /checkin

<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
     <key>MessageType</key>
     <string>Authenticate</string>
     <key>Topic</key>
     <string>com.example.mdm.pushcert</string>
     <key>UDID</key>
     <string> [ redacted ] </string>
 </dict>
 </plist>

Now server can either accept or reject the Authenticate request.In order to accept the server has to respond with blank plist

  <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
     "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
     <plist version="1.0">
     <dict>
     </dict>
     </plist>

Upon receiving the response MDM client will send TokenUpdate request

PUT: /checkin

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
     <key>MessageType</key>
     <string>TokenUpdate</string>
     <key>PushMagic</key>
     <string> [ redacted uuid string ] </string>
     <key>Token</key>
     <data> [ 32 byte string, base64 encoded, redacted ] </data>
     </data>
     <key>Topic</key>
     <string>com.example.mdm.pushcert</string>
     <key>UDID</key>
     <string> [ redacted ] </string>
     <key>UnlockToken</key>
     <data>
        [ long binary string encoded in base64, redacted ]
     </data>
 </dict>
 </plist>

Again server needs to send a plain plist to complete the enrolment process

MDM server has to store the following keys in server

PushMagic

Server has to attach this to all the Push notification it sends to connect MDM client

Token

A unique id that identifies the device to APNS

UnlockToken

A key used to clear the passcode of the device.

Managing the Device

Now the server has to send push notification by passing above Token to Token for Push notification library and Payload of Pushmagic as value for the key MDM

 {"mdm":"996ac527-9993-4a0a-8528-60b2b3c2f52b"}

See aps is not present in this payload

Once the device receives the push notification the MDM client contacts the Server URL instead of Check In URL with status idle

PUT: /server

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
     <key>Status</key>
     <string>Idle</string>
     <key>UDID</key>
     <string> [ redacted ] </string>
 </dict>
</plist> 

The server then responds with whatever command it has queued for the device.

Lets see a example for Device Lock

 The server has to respond with command like this to the client request

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
       <key>Command</key>
       <dict>
             <key>RequestType</key>
             <string>DeviceLock</string>
       </dict>
       <key>CommandUUID</key>
       <string></string>
 </dict>
</plist>

When the MDM client receives this for its status idle request that was sent earlier.It'll immediately lock the device and respond the server with following standard acknowledgement

<?xml version="1.0" encoding="UTF-8"?>
     <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
     "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
     <plist version="1.0">
     <dict>
           <key>CommandUUID</key>
           <string></string>
           <key>Status</key>
           <string>Acknowledged</string>
           <key>UDID</key>
           <string> [ redacted ] </string>
     </dict>
    </plist> 

You can find some list of Commands here

That's all.This approach would do a simple demo thing.

Note:

I will try to fine tune or add more content here for easier understanding

Answer 2

Please go through this link and content

About Mobile Device Management

The Mobile Device Management (MDM) protocol provides a way for system administrators to send device management commands to managed iOS devices running iOS 4 and later, OS X devices running OS X v10.7 and later, and Apple TV devices running iOS 7 (Apple TV software 6.0) and later. Through the MDM service, an IT administrator can inspect, install, or remove profiles; remove passcodes; and begin secure erase on a managed device.

The MDM protocol is built on top of HTTP, transport layer security (TLS), and push notifications. The related MDM check-in protocol provides a way to delegate the initial registration process to a separate server.

MDM uses the Apple Push Notification Service (APNS) to deliver a “wake up” message to a managed device. The device then connects to a predetermined web service to retrieve commands and return results.

To provide MDM service, your IT department needs to deploy an HTTPS server to act as an MDM server, then distribute profiles containing the MDM payload to your managed devices.

A managed device uses an identity to authenticate itself to the MDM server over TLS (SSL). This identity can be included in the profile as a Certificate payload or it can be generated by enrolling the device with SCEP.

Note: For information about about SCEP, see the draft SCEP specification located at datatracker.ietf.org/doc/draft-nourse-scep/. The MDM payload can be placed within a configuration profile (.mobileconfig) file distributed using email or a webpage, as part of the final configuration profile delivered by an over-the-air enrollment service, or automatically using the Device Enrollment Program. Only one MDM payload can be installed on a device at any given time.

Configuration profiles and provisioning profiles installed through the MDM service are called managed profiles. These profiles are automatically removed when the MDM payload is removed. Although an MDM service may have the rights to inspect the device for the complete list of configuration profiles or provisioning profiles, it may only remove apps, configuration profiles, and provisioning profiles that it originally installed. Accounts installed using managed profiles are called managed accounts.

In addition to managed profiles, you can also use MDM to install apps. Apps installed through the MDM service are called managed apps. The MDM service has additional control over how managed apps and their data are used on the device.

Devices running iOS 5 and later can be designated as supervised when they are being prepared for deployment with Apple Configurator 2. Additionally, devices running iOS 7 and later can be supervised using the Device Enrollment Program. A supervised device provides an organization with additional control over its configuration and restrictions. In this document, if any configuration option is limited to supervised devices, its description notes that limitation.

Unless the profile is installed using the Device Enrollment Program, a user may remove the profile containing the MDM payload at any time. The MDM server can always remove its own profile, regardless of its access rights. In OS X v10.8 and later and iOS 5, the MDM client makes a single attempt to contact the server with the CheckOut command when the profile is removed. In earlier OS versions, the device does not contact the MDM server when the user removes the payload. See MDM Best Practices for recommendations on how to detect devices that are no longer managed.

A profile containing an MDM payload cannot be locked unless it is installed using the Device Enrollment Program. However, managed profiles installed through MDM may be locked. All managed profiles installed through MDM are removed when the main MDM profile is removed, even if they are locked.

At a Glance

This document was written for system administrators and system integrators who design software for managing devices in enterprise environments.

The MDM Check-in Protocol Lets a Device Contact Your Server The MDM check-in protocol is used during initialization to validate a device’s eligibility for MDM enrollment and to inform the server that a device’s device token has been updated.

Related Chapter: MDM Check-in Protocol The MDM Protocol Sends Management Commands to the Device The (main) MDM protocol uses push notifications to tell the managed device to perform specific functions, such as deleting an app or performing a remote wipe.

Related Chapter: Mobile Device Management (MDM) Protocol The Way You Design Your Payload Matters For maximum effectiveness and security, install a base profile that contains little more than the most basic MDM management information, then install other profiles to the device after it is managed.

Related Chapter: MDM Best Practices The Device Enrollment Program Lets You Configure Devices with the Setup Assistant The HTTP-based Device Enrollment Program addresses the mass configuration needs of organizations purchasing and deploying devices in large quantities, without the need for factory customization or pre-configuration of devices prior to deployment.

The cloud service API provides profile management and mapping. With this API, you can create profiles, update profiles, delete profiles, obtain a list of devices, and associate those profiles with specific devices.

Related Chapter: Device Enrollment Program The Volume Purchase Program Lets You Assign App Licenses to Users and Devices The Volume Purchase Program provides a number of web services that MDM servers can call to associate volume purchases with a particular user or device.

Related Chapter: VPP App Assignment Apple Push Notification Certificates Can Be Generated Through the Apple Push Certificates Portal Before you receive a CSR from your customer, you must download an “MDM Signing Certificate” and the associated trust certificates via the iOS Provisioning Portal. Then, you must use that certificate to sign your customers’ certificates.