2016/05/20
20 May, 2016

[Article] An Introduction to the WSO2 Enterprise Mobility Manager Architecture

  • Nipun Suwandaratna
  • Senior Solutions 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


Introduction

WSO2 Enterprise Mobility Manager (WSO2 EMM) provides a platform for organizations to manage devices that are connected with a respective entity’s business operations. These devices could fall into the categories of corporate-owned, personally-enabled (COPE) or bring your own device (BYOD). WSO2 EMM provides the means to govern device operations and configuration as well as mobile applications. In a typical use case, organizations would want to implement an enterprise mobility manager solution that include the following: 1) mobile device management (MDM), which allows control of COPE and BYOD devices that access corporate data by enforcing policies to control Wi-Fi access, passcodes, camera, VPN, etc. and enabling governance over settings; 2) mobile application management (MAM), which allows provisioning apps and providing updates to devices and enforcing restrictions on the types of apps that can be used (e.g. app allow and deny listing).

WSO2 EMM deals with two mains aspects (MDM and MAM) and has three main components (the EMM Console, App Publisher, and App Store).


WSO2 EMM Component Architecture

Figure 1


The connected device management framework (CDMF)

The connected device management framework (CDMF) is what WSO2 EMM is built upon. It handles policy management, operations management, configuration management, etc.


Device management plugins

A different set of plugins for each OS (Android, iOS, Windows) will provide platform-specific implementations for the features exposed by the CDMF. This architecture allows adding new mobile platforms to WSO2 EMM easily.


EMM console

The EMM console is the interface that allows administrators to control enrolled devices and manage users/roles.

Figure 2


Mobile application management components

Mobile application management mainly consists of two web applications: App Publisher and App Store.


Publisher and Store

The App Publisher and Store web apps provide MAM features.

The Publisher allows users with publisher permission to publish mobile apps to the Store. The Publisher allows users to manage the App lifecycle from publication to depreciation and retiring. Furthermore, users with review permission can approve/reject Apps submitted for publishing.

Figure 3

The Store is used to provision mobile apps to devices. Users can also use the Store to discover and install mobile apps.

Figure 4

An admin can use the mobile app store for Enterprise Install and Uninstall, which allows him/her to push apps to either all devices or a selected set of devices based on user roles or users.

Figure 5

All App Publisher/Store features could also be accessed using REST services. This enables developers to create their own custom web sites/apps that utilize Publisher/Store features.


Runtime architecture

Figure 6


API centric design

Each component of the WSO2 EMM communicates by using APIs. EMM Admins use the MDM console to administer devices. These operations plus device communications happen via an API Gateway.

Refer to [1] for WSO2 EMM REST API Guide.


API gateway and key manager

The key manager handles OAuth 2 access token related operations. When a device is registered with EMM an application is created. This application would be provided with a Client ID and Client Secret tokens that can be used to obtain access using the token API exposed by the Key Manager. When API calls are made using this access token the API Gateway would contact the Key Manager for validation.

The API Gateway and Key Manager components are based on the WSO2 API Gateway and Key Manager, and function in a similar manner.


EMM services

The CDMF provides a core set of functionalities; however, these are not coupled with any platform. Device management plugins provide platform specific implementations that would be utilized by the CDMF. Each mobile platform will utilize these functionalities through APIs.

Device plugins typically carry three primary elements; a Platform Specific Device Management Descriptor Class, an API to expose all controllable features in the form of a control API and related UI bits. Android and iOS operations would go through a JAX-RS API while Windows operations would go through JAX-WS.


Enrolment and device agents

In order to enroll the device with WSO2 EMM you first need to download and install the WSO2 Agent onto the device. Once installed you can carry out device registration and enrollment using the Agent app. The agent app could either be provisioned using a QR code provided via the MDM console [2] or an email that points the user to the download location. In a COPE scenario where the corporation owns the device the WSO2 Agent can be pre-installed on to the devices. In Android and Windows this Agent would carry out MDM tasks. However, in iOS the agent would only carry out tasks such as providing location, message sending (to device) and ringing; the MDM functions would be handled by the OS via profiles. Device enrolment in iOS needs to go through a Certificate Signing process [3], [4].


Pushing operations to devices

Push mechanism:

  1. Admin creates operations/policies that needs to be enforced on a device using the MDM console
  2. MDM console invokes an API on the API Gateway
  3. API Invokes the backend JAX-RS Admin service
  4. Admin Service invokes operation in CDMF
  5. CDMF utilizes plugins relevant to the device platform
  6. Once operation is confirmed CDMF invokes push notifications connector
  7. Push notification connector invokes relevant push notification service (Google Cloud Messaging for Android, APNS for Apple)
  8. Push notification service sends a wake up call to the device informing there is a pending operation
  9. Device invokes API to get operations
  10. API invokes back-end services and responds to the API call sending the operation to the device

Device enrolment would follow steps 1 to 5.


Pull mechanism

Apart from the push mechanism, in the pull mechanism (client side polling) the Agent periodically polls the EMM server to check for any pending operations. Admins can configure the polling interval using the MDM console.


Notifications

Notifications for Android happens either via Google Cloud Messaging (GCM) (push mechanism) or via client side polling (pull mechanism). A preferred method can be selected for notifications. Refer to [5].

iOS is purely reliant on Apple Push Notification Service (APNS).

Windows currently uses client side polling. Windows Notification Service (WNS) based notifications would be enabled in the future.


Policy enforcement and monitoring

Pushing a policy onto a device follows the steps mentioned previously. Once a policy is enforced on a device, the Agent on the device would periodically monitor the policy compliance. Upon enforcing a policy admins can select what action to perform in case of a violation, e.g. the admin could select the Enforce option upon which the CDMF would re-enforce the policy onto the device in the event of a violation.


Conclusion

The mobility requirements of organizations today have evolved and become increasingly complex. To this end, WSO2 EMM provides a platform for organizations to manage devices that are connected with a respective entity’s business operations. WSO2 EMM provides the means for organizations to harness the power of mobile technology to make use of corporate data on the go while providing managed access to backend systems. The customizability and extensibility of WSO2 EMM allow organizations to modify the solution to fit their organizational needs making use of the API driven architecture that WSO2 EMM is based on. For example, by using the WSO2 product platform along with WSO2 EMM, an organization can build an enterprise application platform that allows organizations to expose their backend services and data as managed APIs; it also enables devices (that fall under both COPE and BYOD concepts) to access organizational data along with features such as push notifications, user management, comprehensive device management, app management, etc.


References

 

About Author

  • Nipun Suwandaratna
  • Senior Solutions Engineer
  • WSO2