Configure Device communication when using an existing SSL Certificated with Enterprise Mobility Manager

The two main components of WSO2 Enterprise Mobility Manager are mobile device management and mobile application management. Setting up WSO2 EMM can be done by following the “Getting Started” guide as mentioned in the documentation. This article mainly emphasizes on how to obtain the certification configuration for your personal domain.

Enrolled devices and WSO2 Enterprise Mobility Manager communicates using the HTTPS protocol. This is to make sure that the private and sensitive data stored in the mobile device cannot be retrieved by a third party or unauthorized personals. All the communication carried out between devices, APNS and EMM server is based on certificates included in the key-store files with the extension “jks”. These security features are critical since EMM supports both cooperate owned (COPE) and personal (BOYD) device management. In the section “Configuring the product” guide you have been provided with the steps to configure the EMM server to used in your local subnet where the server and the devices uses a SSL certificate issued by the inbuilt Certificate Authority of the EMM server.

Communications between devices and EMM server

WSO2 EMM server consists of the following components:

• SCEP server component.
• CA server component.
• Device Management Component.

The iOS device acts as a SCEP client where it sends the SCEP request to the Server. For enrollment purposes, this communication requires a certificate which will be generated by the CA server component of EMM. The iOS device will generate a private/public key pair and send a certificate signing/authorization request to the CA where the CA component will need to generate the public key certificate and store the public key for encryption which will be used later.

There is communication between IOS devices and APNS as well as Android devices and GCM for policy monitoring and to perform operations. All the devices will communicate with the EMM server using the agent applications. All these communications must be secured using certificates.

You can see the communication flow in Figure 1 given below.

In order to provide secure communication between the components represented in Figure 1, you have to obtain an SSL certificate for your domain from a Certificate Authority. When hosted under a public domain the obtained SSL certificates needs to be included into the key stores.

Obtaining an SSL Certificates for your domain

You can choose one of the SSL certificate providers available in the market according to your requirements and budget. You can successfully obtain an SSL certificate for your domain by following the steps provided below accordingly:

1. Purchase a SSL certificate.
2. Create a CSR form including your domain and project data
3. Submit the CSR to the SSL vendor
4. Verify the CSR request by validating that you control the domain the certificate will protect.
5. Your SSL certificate will be delivered to you or can be downloaded as facilitated by your certificate vendor.

You can follow the “Get SSL on my website” guide for more information on how to obtain SSL certification.

Configuring for IOS device management

Configuring the IOS device management and communications is a three step process :

1. Obtaining a signed CSR from WSO2.
2. Configuring EMM server for IOS device management.
3. Configuring the IOS client.

Obtaining a signed CSR from WSO2

Create a Certificate Signing Request (CSR) file from the EMM server using your private key. You can use commands given below to generate the CSR file:

openssl genrsa -des3 -out <Your_Private_Key_File> 2048

openssl req -new -key <Your_Private_Key_File> -out <You_CSR_File>

Make sure to create both Your_Private_Key_File and Your_CSR_File files with .pem extension

Provide correct information to the prompted questions related to your organization and the project. Make sure to provide the actual organization name as this is a required field. The Email address provided should be valid as this will act as the identification of your CSR request in order to identify you in a CSR expiration situation. Common name stands for the fully qualified domain name of your server. Make sure that the information you have provided is of high accuracy since the artifacts provided will bind to the provided domain name. IOS device can be only managed by the server which is hosted under the provided host name.

You can submit the CSR request to the “Obtain the signed CSR file” form. Make sure to enter the same information as you entered in the CSR request when filling the above form.

You will be provided with the following artifacts which is required to configure the EMM server to manage IOS devices:

1. The signed CSR file in .plst format.
2. Agent source code.
3. P2 repository, which contains the feature list.

Please refer “Obtaining the Signed CSR File” guide for more information on obtaining a signed CSR file.

Configuring EMM server for IOS device management

IOS server configuration is a complex and prolonged process which can be described by the following steps. By following these steps in order you can easily configure the EMM server for iOS device management:

1. Installing IOS feature to EMM server.
2. Configure general IOS server settings.
3. Generate the MDM APNS certificate.

Installing IOS feature to the EMM server

Start the EMM server in order to install the features from the P2 repository obtained via the CSR request.

You can navigate to the carbon console using <YOUR_DOMAIN>/carbon and then navigate to the configure tab. Then select the features option from the list.

IOS related features will be available in the P2 repository provided to you with the signed CSR. Install all the three features given. After the installation of the features is completed, stop the EMM server and process to the following location : <EMM_HOME>/repository/conf

You will find a new configuration file “ios-config.xml” in the directory. Modify the “iOSEMMConfigurations” accordingly. Please refer to “Installing WSO2 EMM iOS Features via the P2 Repository” guide for more information.

Configure general IOS server settings.

In order to setup your server with IOS, follow the instructions given in “ General iOS Server Configurations” guide until Step 5.

After completing Step 5 follow the instructions given below:

• Convert the downloaded ssl certificates from your vendor to .pem files.

openssl x509 -in <RA CRT> -out <RA CERT PEM>

Example:

openssl x509 -in your-domain-com-apache.crt -out your-domain-com-apache.pem

openssl x509 -in your-domain-com-ee.crt -out your-domain-com-ee.pem

• Create a certificate chain with the root and intermediate certifications.

cat <CERTIFCATE 1> <CERTIFICATE 2> ... >> <CERTIFICATE CHAIN>

Example:

cat your-domain-com-apache.pem your-domain-com-ee.pem >> clientcertchain.pem

cat your-domain-com-apache.crt your-domain-com-ee.crt >> clientcertchain.crt

• Export the SSL certificate chain file as a PKCS12 file with "wso2carbon" as the alias.

openssl pkcs12 -export -out <KEYSTORE>.p12 -inkey <RSA_key>.key -in clientcertchain.crt -CAfile clientcertchain.pem -name "<alias>"

Example:

openssl pkcs12 -export -out KEYSTORE.p12 -inkey ia.key -in clientcertchain.crt -CAfile clientcertchain.pem -name "wso2carbon"

After following the steps as above resume the configuration from Step 7.b as in “General iOS Server Configurations” guide.

Note that Step 6 and 7.a need to be skipped since the server configuration mentioned in those steps is for the public domain with already obtained SSL certificates.

Generate the MDM APNS certificate.

Go to the Apple Push Certificate Portal and upload the .plist file provided with the signed CSR from WSO2 and generate the MDM certificate. Follow the instructions given in “Generate MDM APNS Certificate” guide in order to convert the downloaded certificate to .pxf format.

After completing the instructions given, you can proceed with the IOS platform configuration as instructed in the “IOS Platform Configuration” guide.

Configuring Android device management

To enable secure communication between android devices and your EMM server please follow the “Android Configurations” guide. You can skip the certificate generation described in Step 1 under “Generating a BKS File” and move to Step 2 directly since you have already completed the above when configuring the IOS device communication.

If not follow the IOS Configuration instructions given above for certificate generation. Do not follow Step 1 mentioned under “Generating a BKS File” in the documentation.

Configuring Windows device management

There are no additional configurations needed to enable windows device management.

App Management Capabilities in WSO2 Enterprise Mobility Manager

The two main components of WSO2 Enterprise Mobility Manager are mobile device management and mobile application management. Setting up WSO2 EMM can be done by following the “Getting Started” guide as mentioned in the documentation. This article mainly focuses on the  mobile application management capabilities of WSO2 EMM.

When monitoring and managing devices in an organization, monitoring an application on the device and maintaining it in -house is required in order to have a complete control of the organization’s devices and confidential information. WSO2 EMM ships with a separate app store and an app publisher along with application management features in order to provide end -to -end application management capabilities.

Application Management Components.  

EMM contains three major components which enable mobile application management capabilities.

App Publisher - Enables the organizations to easily publish their apps, share documentation, and gather feedback on the quality and usage of apps. App Publisher is powered by  WSO2 App Manager.

App Store - Enables the device owners to easily access web applications to self-register, discover apps, subscribe to apps, and evaluate them. It also enables administrators to push install requests of a published app to selected devices. App Store is powered by  WSO2 App Manager.

Policy Management  - Enables the administrators to check the installed applications on the enrolled devices and include white listed applications and blacklisted applications for devices. Policy Management is powered by  WSO2 Connected Device Management Framework.

Ytilizing the above three components in WSO2 EMM provides end -to -end mobile application management.

Application Lifecycle Management.

Process of publishing a mobile application to the app store, and the maintaining the application in the store is managed under the application lifecycle management. When a developed mobile application needs to be published to the app store it needs to be iterated through a few states and then get approved by authorized users.  This process is described using Figure 1. The states of an application is described in Table 1.

State	Description
In Review	Initial state when developers submit their applications to the publishers.
Approved	The application is moved to this stage when an user with permission approves the application after reviewing it.
Rejected	If a user with permissions rejects the application after reviewing, the application is moved to this stage.
Published	After getting the approval by a relevant user, another user with publishing permissions can publish the application. All the published applications will be in this stage.
Unpublished	User with permissions can un-publish an application which is already published. All the unpublished applications will be moved to this stage. These applications will be removed from the store until they are  published again.
Deprecated	If an user deprecates an application, those will be moved to this stage. These applications will be removed from the store.

Table 1: States of the Appp Life Cycle

Table 1 describes the status of the Application life cycle which is supported by WSO2 EMM. The state transition is represented in Figure 1 given below.

As shown in Figure 1, a developer can create mobile applications and submit it to the publisher. You can log into the publisher web app by simply visiting https://<YOUR_DOMAIN>/publisher URL. In order to successfully create a mobile application, you can follow the instructions given in “Creating an Android Application” guide and “Creating an IOS Application” guide accordingly.

After a developer submits the mobile application for review, any user with app approval permission can approve the application or reject the application accordingly. When a user with the related permissions logs in to the publisher, they can see a list of applications in the “In Review” states as shown in Screen Capture 1.

Users can simply approve an application by clicking on the Approve button on the action column or reject an application by clicking on the Reject button on the action column. This will result in the application changing the state to approved or rejected accordingly.

Approved applications will be listed to be published in approved state. These applications will be listed as shown below in Screen Capture 2, when a user with permission logs in to the publisher.

Authorized users can publish the approved applications by clicking on the Publish button in the action column or delete and remove the application by clicking on the Delete button in the action column. After publishing an application, applications can be viewed in the app store. Users can login to the store using https:<Your_Domain>/store URL. Published applications are listed in the app publisher as shown in Screen Capture 3 and published applications are listed  in the app store as shown in Screen Capture 4.

All published applications can be unpublished by users with permission by simply clicking on the Unpublish button in the action column or deprecate the application by clicking on the Deprecate button in the action column. Applications which are deprecated or unpublished will not be visible in the application store. All unpublished applications can be republished when needed by simply clicking the Republish button in the action column of the unpublished application view shown in Screen Capture 5. Deprecated applications cannot be published again, but they can be either deleted or retired by clicking the Delete button or Retire button accordingly.

All the actions and the state changes according to the action are represented in Figure 1. Organizations can maintain their applications and versions according to the life cycle support provided by WSO2 EMM. For more information about application lifecycle management please refer to the “Mobile Application Lifecycle Management” guide.

Following the above -mentioned actions, users can manage the lifecycle of their mobile applications using WSO2 EMM.

Install Application to Enrolled Devices.

Device administrators can send application install requests to enrolled devices using the app store. To successfully send application installation requests, device administrators needs to follow the below steps :

Login to the app store and select the application that needs to be installed to the enrolled devices. Users will have two options of installing a mobile application as shown in Screen Capture 6.

Install

Here the list of devices enrolled will be listed. The user can select the devices that need to install the application from the listed devices. Refer to Screen Capture 7 for an example for the view of the device selection.

Enterprise Install

Here the user has the option to install the application to all devices owned by users with a selected role as shown in Screen Capture 8 or the user has the ability to push the app installation request to all devices enrolled under select users as shown in Screen Capture 9.

From the  two options of app installation given above, an application installation request will be sent to the related device and by accepting the request the application will be installed to the device.

Monitoring the Installed Application on Enrolled Devices.

WSO2 EMM provides the ability of monitoring installed mobile applications on enrolled mobile devices. In each device, in the detail view, there is a tab to view the list of installed applications on the device as in Screen Capture 10. The device owners and administrators can see what kind of application is installed in the device. If there is any  application which might harm the organization's data or break rules and regulations of the organization, they can take actions to prevent it before an incident occurs.

Whitelisting and Blacklisting Applications (Applicable from EMM 2.1.0 )

Whitelisting and blacklisting application is enabled through the WSO2 EMM policy management component where administrators have the ability tp enforce application whitelisting or application blacklisting policies under application restriction policies. In order to configure a policy which holds application blacklisting or whitelisting details, administrators have to create a policy using policy generation wizard in EMM.

Administrators can simply create a policy and enable the applications restrictions and selecting blacklisting or whitelisting from the drop down as shown in Screen Capture 11.

Administrators can provide the list of applications that needs to managed by the policy by utilizing the controllers under the above -mentioned drop down menu as shown in Screen capture 12.

Then administrators have to follow the same method as publishing a policy to devices to activate the whitelisting or blacklisting of applications defined in the policy above. To have more depth in understanding on managing policies using WSO2 EMM refer the “Managing Policies” guide .

How Application Blacklisting Works.

When a policy with blacklisting application list is enforced to a device, applications which are listed on the blacklist will not be available to the device user. When the user tries to utilize an application which is blacklisted,  the application will be terminated and the user will be provided with a warning message from the WSO2 agent.

How Application Whitelisting Works.

When a policy with whitelisting application list is enforced to a device, applications which are not mentioned in the provided list will not be available to the user. When a user tries to utilize an application which is not listed under the whitelist applications, the user will be provided with awarning and the application will be terminated.