User certificate authentication on the client

The User Certificate Authentication feature requires little configuration on the client side. The MobileFirst client run time takes care of most of the heavy lifting on the behalf. There are however, a few things we need to be aware of to ensure successful and secure communication with the server.

Establishing trust

Because the User Certificate Authentication feature requires communication over HTTPS, the first thing we must ensure is that the client device trusts the server's credentials sent on the SSL handshake.

Each mobile platform comes with a predefined set of trusted certificate authorities (CAs) that are deemed trustworthy by the platform. Trust is are established if the server uses a server certificate that is signed by one of these trusted CAs.

However, if the server uses a CA that is unknown to the device, we must do some extra work on the client side to establish appropriate trust. To establish trust, install the trust anchor certificate on the client device. The trust anchor is either the root CA, or the root certificate if you are using a self-signed certificate. See Configure SSL using untrusted certificates.

Dependent user realm

The first time a user attempts to connect to the server, IBM MobileFirst Platform Foundation tries to enroll the user into the PKI and provision the device with the user certificate. To enroll the user, IBM MobileFirst Platform Foundation requires the help of a dependent user authentication realm. This behavior is all configured on the server. But we must ensure that the application has the appropriate challenge handlers required to handle the challenges that come from the server. The dependent realm challenge handlers do not require any additional configuration. See appropriate section of this user documentation or getting started modules for instructions on how to write the respective challenge handlers for the dependent user realm.

Group support

User certificates are issued by default to a user on a specific application and device. Group support allows a certificate to be issued to the user on a specific device and to a group of applications. The same user certificate can be shared among a group of applications installed on the device, allowing the user to only authenticate through a dependent realm once, and not for every application.

In this case, the user enrollment process that requires the user to log in to a dependent realm happens the first time that the user attempts to log in to the server on a particular device. After the device is provisioned with the necessary certificate, all subsequent authentications to the server from any of the MobileFirst applications that are designated by we use the same certificate to authenticate to the server.

To configure the sharing of user certificates among a group of applications, see Configure user certificate authentication for a group of applications.

Clearing certificates on the chain

Certificates on the client are managed by the MobileFirst client run time. They are installed and removed from the device as needed. However, there might be situations when you want the ability to clear the certificates installed on the device. For this reason, a JavaScript API is provided. The API allows the application to remove the certificates at more convenient times, like during test and development, or when the device is transferred to a new user.

The following API removes the certificate on the device for the specific application in use:

WL.UserAuth.deleteCertificate();

On iOS only, if we would like to delete the certificate that is associated with a specific group of applications, use the following API:

WL.UserAuth.deleteCertificate("yourGroupNameHere");

Security considerations

This new feature introduces a powerful and ITU-T X.509 standards-based way to authenticate users. It also introduces a password-less login mechanism. The identity is established by the MobileFirst client run time as part of the application that presents the certificate as part of the server-side connection. Although this behavior greatly simplifies the user experience, the following precautions must be taken by the enterprise. These precautions ensure that there is adequate protection on the device to ensure cases where the user loses the device or when the device is stolen.

1. Single user is required. The device is owned and used only by a single user and not accessible to others.

2. Device must be maintained under a device passcode lock or PIN to ensure that only the designated user can access the device and applications.

• Configure user certificate authentication for a group of applications
  We can configure the User Certificate Authentication feature to issue a certificate to a user on a device for a group or family of applications that are protected by the user certificate authentication realm. This configuration allows a user to authenticate once and be automatically authenticated to a set of applications on the device (single sign-on). This single sign-on option among a family of applications can be achieved with the Simple Data Sharing feature, which allows the User Certificate Authentication feature to provision a device with a user certificate that applies to, and is used by, all applications in the same specified MobileFirst family.

Parent topic: User certificate authentication