MobileFirst security overview

An overview of security features within IBM MobileFirst Platform Foundation.

The following sections provide high-level information about the MobileFirst security model.

Goals and structure of MobileFirst security framework

The MobileFirst security framework serves two main goals. It controls access to the protected resources, and it propagates the user (or server) identity to the backend systems through the adapter framework.

It is key to the success of the application that the MobileFirst security framework does not include its own user registry, credentials storage, or access control management. Instead, it delegates all those functions to the existing enterprise security infrastructure. This delegation allows MobileFirst Server to integrate smoothly as a presentation tier into the existing enterprise landscape. Integration with the existing security infrastructure is an important feature of the MobileFirst security framework, and supports custom extensions that allow integration with virtually any security mechanism.

Another feature of the MPF security framework is support of multi-factor authentication. It means that any protected resource can require multiple checks to control access. A typical example of multi-factor authentication is the combination of device, application, and user authentication.

Each type of security check has its own configuration, and a configured check is called a realm. Multiple realms can be grouped in a named entity called a security test. Each protected resource refers to the security test. All the configuration entities are defined in a single configuration file so the definitions can be reused across different protected resources.

An implementation of security checks usually includes a client part and a server part. The two parts interact with each other according to their private protocol. This protocol is usually a sequence of 1) challenges sent by the server and 2) responses that are returned by the client.

The IBM MobileFirst Platform Foundation security framework provides a wire protocol. This protocol allows the combination of challenges and responses of multiple security checks during a single request-and-response round trip. The protocol serves two important purposes: it allows the number of extra round trips between the client and server to be minimized, and it separates the application logic and the security checks implementation.

Protected resources and authentication context

A protected resource can be any of the following items:

• Application

  Any request to the application requires successful authentication in all realms of the security test defined in the application descriptor.

• Adapter procedure

  Procedure invocation requires successful authentication in all realms of the security test defined in the adapter descriptor. The user identity and credentials that are obtained during such authentication can be propagated to the enterprise information system represented by this adapter.

• Event source

  Subscription to push notifications requires successful authentication in all realms of the security test that are defined in the event source definition (in adapter JavaScript).

• Static resource

  Static resources are defined as URL patterns in the authentication configuration file. They allow protection of "static" web applications such as the operations console.

During the session, an application can access different resources. The results of the authentication in different realms are stored in the session authentication context. These results are then shared among all of the protected resources in the scope of the current session.

Realms and security tests

A realm represents a fully configured security check that must be completed before it can allow access to a protected resource. The semantics of the checks are not limited to the authentication, but can implement any logic that can serve as protection for the server-side application resources, for example:

• User authentication

• Device authentication and provisioning

• Application authenticity check

• Remote disable of the ability to connect to MobileFirst Server

• Direct update

• Anti-XSRF check (cross-site request forgery)

The realms are defined in the authentication configuration file on the project.level. A realm consists of two parts: the authenticator and the login module. The authenticator obtains the credentials from the client, and the login module validates those credentials, and builds the user identity.

The realms are grouped into security tests, which are defined in the same authentication configuration files. The security test defines not only the group of realms, but also the order in which they must be checked. For example, it often makes sense not to ask for the user credentials until you make sure the application itself is authentic.

Since some realms are relevant only to mobile or only to web environments, the configuration of a security test can be non-trivial. MPF provides simplified security test configurations for mobile and web environments. It is also possible to create a custom security test from scratch.

MobileFirst protocol and client challenge handlers

Each security check defines its own protocol, which is a sequence of challenges sent by the server and responses sent by the client. On the server side, the component that implements this private protocol is the authenticator. On the client side, the corresponding component is called the challenge handler.

When the client request tries to access a protected resource, MobileFirst Server checks all the appropriate realms. Several realms can decide to send a challenge. Challenges from multiple realms are composed into a single response and sent back to the client.

MobileFirst client infrastructure extracts the individual challenges from the response, and routes them to the appropriate challenge handlers. When a challenge handler finishes the processing, it submits its response to the MobileFirst client infrastructure. As an example, this occurs when the challenge handler obtains the user name and password from a login user interface. When all the responses are received, the MobileFirst client infrastructure resends the original request with all the challenge responses.

MobileFirst Server extracts those responses from the request and passes them to the appropriate authenticators. If an authenticator is satisfied, it reports a success, and MobileFirst Server calls the login module. If the login module succeeds in validating all of the credentials, the realm is considered successfully authenticated. If all the realms of the security test are successfully authenticated, MobileFirst Server allows the request processing to proceed.

If a realm check fails, its authenticator sends another (or the same) challenge to the client, and the whole process repeats.

Combining multiple challenges and responses into a single response and request maximizes security efficiency by reducing the number of extra round trips. For example, the checks for device authentication, application authenticity, and direct update can be done in a single round trip.

The fact the MobileFirst client infrastructure automatically resends the original request with the challenge responses allows separation between the application logic and security aspects. Though any application request can result in a security challenge, the application logic must not include any special processing for that case. The challenge handlers are not related to the application context and can focus on the security-related logic.

Integration with container security

MobileFirst Server is technically a web application hosted by an application server (such as WebSphere Application Server). Thus, it is often desirable to reuse authentication capabilities of the application server for MobileFirst Server, and vice versa. Since this task can be non-trivial, it is important to understand the differences between MPF and Web Container authentication models:

• The Enterprise Edition (Java EE) , Enterprise Edition model allows only one authentication scheme for a web application. Multiple resource collections are defined by URL patterns, with authentication constraints defined by a white list of role names.

• The MobileFirst model, by contrast, allows protection of each resource by multiple authentication checks, and the resources are not necessarily identified by the URL pattern. In some cases, authentication can be triggered dynamically during the request processing.

As a result, the authentication integration between MobileFirst Server and the Enterprise Edition (Java EE) , Enterprise Edition container is implemented as a custom IBM MobileFirst Platform Foundation realm. This realm can interact with the container and obtain and set its authenticated principal.

MobileFirst Server includes a set of login modules and authenticators for WAS full profile and WAS Liberty profile that implement this integration with LTPA tokens. The integration works as follows:

• If the caller principal (an entity that can be authenticated) of the servlet request is already set, the container authentication was successful, and the same principal is set as the MobileFirst user identity. This case assumes that the MobileFirst WAR file has appropriate login configuration and resource collection definitions. Including this information can be tricky because the web.xml file for MobileFirst project is generated automatically, and those definitions would be overwritten in every build.

• If the incoming request contains a Lightweight Third Party Authentication (LTPA) token, the login module validates it, and creates the MobileFirst user identity.

• If the request does not contain an LTPA token, the authenticator requests the user name and password from the client. The login module validates them and creates the MobileFirst user identity. In addition, it creates the LTPA token, and sends it back to the client as a cookie.

In this case, the authentication capabilities of WebSphere Application Server are reused by MobileFirst realms in the form of Java utilities that implement validation and building of an LTPA token.

Integration with web gateways

Web gateways like DataPower and IBM Security Access Manager (formerly Tivoli Access Manager) provide user authentication so that only authenticated requests can reach the internal applications. The internal applications can obtain the result of the authentication that is done by the gateway from a special header, for example, an LTPA token.

When MobileFirst Server is protected by a web gateway, it means that the client requests first encounter the gateway. The gateway sends back a login form and validates the credentials, and if the validation is successful, submits the request to the MobileFirst Server. This sequence implies the following requirements on the MobileFirst security elements:

• The client-side challenge handler must be able to present the gateway's login form, submit the credentials, and recognize the login failure and success.

• The authentication configuration must include the realm that can obtain and validate the token provided by the gateway.

• The security test configuration must take into account that the user authentication is always done first. For example, there is no point in using the device single sign-on (SSO) feature because the user credentials are requested by the gateway.

Further information on security, as it is implemented in IBM MobileFirst Platform Foundation, is provided in the following overview of security features. There are links to the relevant sections of the documentation, which pertain to them.

Integration with IBM Security Access Manager

IBM Security Access Manager can be integrated with MPF to provide the following protections using risk-based access decisions to protect MobileFirst applications and adapters as listed here:

• User authentication

• SSO

• Identity attributes

• Fine-grained authorization

SSO can be achieved to the mobile client and in adapter server connections. The context-based access policies can be defined to provide identity assurance and strong authentication with a one time password (OTP) for adapter-based transactions in IBM MobileFirst Platform Foundation and application authentication.

For more information about IBM Security Access Manager, see IBM Security Access Manager for MPF.

Parent topic: MobileFirst security framework