Mobile device authentication

You can require mobile devices to authenticate themselves. Device identity is used in several places within IBM MobileFirst™ Platform Foundation. You can use provisioning, which is the process of obtaining a security certificate. There are three modes of the provisioning process.

Unique device ID

The unique device ID is used by IBM MobileFirst Platform Foundation for device ID-related features, such as security, device SSO, reports, and push notifications.

On iOS

To calculate the unique device ID, a globally unique ID (GUID) is used that is generated during device authentication process.
The unique device ID can be unique either to the application or to all applications from the same vendor.
The unique device ID is stored in the device keychain.

On Android

To calculate the unique device ID, device properties are used, such as the WiFi Mac address. This mechanism guarantees the uniqueness of the device ID, and make the process more secure by generating the device ID at the start of each application.
The unique device ID can be unique either to the application or to all applications from the same vendor.
The unique device ID is stored in the application keystore, which is a file in the application sandbox folder.

On BlackBerry

To calculate the unique device ID, the ID that is provided by the operating system is used.
The unique device ID is global to the device.

On Windows Phone Silverlight 8

The publisher host ID is used as a unique device ID. The host ID is unique per device and per publisher, which means that no two publishers will receive the same value for the same device.

On Windows 8 Universal

The MAC address is used as a unique device ID.

Note: The availability of the unique device ID depends on the operating system of the device, and on the application vendor. A vendor who provides multiple applications that can be installed on the same device might then choose whether to require provisioning for each individual application or for a group of applications. If several applications are from the same vendor, they can have the same unique device ID. If these applications are from different vendors, they have different unique device IDs.

To access the unique device ID on the device and on the MobileFirst back-end server, some security controls are performed. The device ID is not a secret data and can be passed to the server in one of the two following ways:

As is, for a non-secure device authentication.
Accompanied with credentials, for a secure device authentication. In that case, the device ID is digitally signed with a X509 certificate. This certificate results of the provisioning process that takes place the first time the application runs on the device.

The unique device ID is sent along with various event types to MobileFirst Operational Analytics (see Operational analytics). For more information on these event types, see Event types.

The unique device ID is also stored in the raw data reports (deprecated) that are generated by IBM MobileFirst Platform Foundation. There are no special access controls available on these reports, as the unique device ID is not considered sensitive data. For more information about raw data reports, see Using raw data reports.

For more information about mobile device provisioning, see the Device provisioning conceptss tutorial on the Getting Started page of the Developer Center.

Scope of mobile device authentication

In addition to requiring users to authenticate before they access certain resources, you can also require mobile devices to authenticate before apps installed on them can access the MobileFirst Server.

Device and application authentication is a process that allows making claims of type "this is application A installed on device D".

Device and application authentication is relevant only for applications that are installed on mobile devices.

Mobile device provisioning

When a MobileFirst application first runs on a mobile device, it creates a pair of PKI-based keys. It then uses the keys to sign the public characteristics of the device and application, and sends them to the MobileFirst Server for authentication purposes.

A key pair alone is not sufficient to sign these public characteristics because any app can create a key pair. In order for a key pair to be trusted, it must be signed by an external trusted authority to create a certificate. The process of obtaining such a certificate is called provisioning.

When a certificate is obtained, the app can then store the key pair in the device keystore, access to which is protected by the operating system.

The provisioning process has three modes:

No provisioning: In this mode, the provisioning process does not happen. This mode is usually suitable during the development cycle, to temporarily disable the provisioning for the application. Technically, the client application does not trigger the provisioning process, and the server does not verify the client certificate.
Auto-provisioning: In this mode, the MobileFirst Server automatically issues a certificate for the device and application data that is provided by the client application. Use this option only when the MobileFirst application authenticity features are enabled.
Custom provisioning: In this mode, the MobileFirst Server is augmented with custom logic that controls the device and application provisioning process. This logic can involve integration with an external system, such as a mobile device manager (MDM). The external system can issue the client certificate based on an activation code that is obtained from the app, or can instruct the MobileFirst Server to do so.

Note: Auto-provisioning and custom provisioning are supported only on Android, iOS, Windows 8 Universal, and Windows Phone Silverlight 8.

Device auto-provisioning

Device auto-provisioning has three aspects:

Provisioning granularity: the scope of the provisioned entity.
Pre required login: the realms that a client must be authenticated with before it can get permission to perform provisioning.
CA Certificate: the parent certificate, which issues device certificates for the provisioning process.

The default behavior is as follows:

Provisioning granularity: a single application.
Pre required login: a login is required to the authentication realm, if any, defined for the current security test.
CA Certificate: a MobileFirst CA Certificate, which is embedded into the platform.

Whether it is obtained by an auto-provisioning or custom provisioning process, the certificate is stored by the client app on the device, and used for signing the payload sent to the MobileFirst Server. The MobileFirst Server validates the client certificate, regardless of how it is obtained.

The server sends a request for ID, which the client responds to with a certificate-signed payload. If the client does not have the certificate, then a request is sent to the MobileFirst Server automatically to get a certificate, and after that is done, the client automatically sends the signed payload.

After the server sends the ok response, the original request is sent automatically.

Granularity of provisioning

The key pair that is used to sign the device and app properties can represent a single application, a group of applications, or an entire device. Windows 8 Universal and Windows Phone Silverlight 8 support only single application level granularity. For example:

Single application: A companys provisioning process requires separate activation for each application that is installed on the device. In this case, the application is the provisionable entity, and each application must generate its own key pair.
Group of applications: A company develops different groups of applications to employees in different geographical regions. If the activation is required per region, the key pair would represent the group of applications that belong to that region. All applications from the same group use the same key pair for their signatures.
Entire device: In this case, the key pair represents the whole device. All the applications from the same vendor that are installed on that device use the same key pair.