Classic 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 back-end 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 IBM MobileFirst Platform Foundation 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 that is called a security test. Each protected resource refers to the security test. All the configuration entities are defined in a single configuration file so that 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 that are 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

Realms and security tests

The realms are defined in the authentication configuration file on the MobileFirst 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 that 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. IBM MobileFirst Platform Foundation 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 that are sent by the server and responses that are 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 IBM MobileFirst Platform Foundation and Web Container authentication models:

• The Java™ Platform, 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 Java Platform, 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.

Integration with web gateways

Web gateways like DataPower® and IBM® Security 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.

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

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 IBM MobileFirst Platform Foundation.