Session-independent mode

Starting with V7.1.0, MobileFirst applications run by default in session-independent mode.

Overview

In previous versions of the product, the authentication context of clients (for example, whether they are logged in to a realm) was wholly dependent on an HTTP session. After logging in, the end user remained logged in only as long as the HTTP session was alive. Whenever the session ended, the user was automatically logged out. In addition, to ensure the continuity of an HTTP session, "sticky" sessions were required when using a load balancer.

The session-independent mode in V7.1.0 decouples the link between authentication context and HTTP sessions by using the attribute store module for saving the authentication context. The interaction between the client and MobileFirst Server no longer has to be session-dependent. IT can auto-scale the network as needed and use a load-balancer without requiring sticky HTTP sessions.

One advantage of this feature is that starting from V7.1.0, if your system is operating in session-independent mode and you choose to scale back or scale up any number of servers, the user experience is unaffected.

Restriction:

By default, new projects that are created in V7.1.0 are session independent. Old projects, even after upgrade remain session dependent. For steps to upgrade older apps to work in session-independent mode in V7.1.0, see Upgrading projects to work in session-independent mode.
Session-independent mode is not supported in configurations of IBM MobileFirst™ Platform Foundation that include any of the following components or environments:
- Blackberry
- Windows Phone Silverlight 8 (native)
- Adobe AIR
- Desktop browser
- Mobile web apps
- JavaME native
- Geolocation
- USSD

Attribute store types for session-independent mode

The attribute store is where the authorization server stores the authentication context of clients (such as the state of authenticators and login modules).

There are three types of attribute store configurations that support session-independent mode: attribute store over the runtime database (default), attribute store over IBM® WebSphere® eXtreme Scale, and attribute store over IBM Data Cache for Bluemix®.

Note: The attribute store type that you select has an impact on the scalability and performance of the IBM MobileFirst Platform Server. In general, when high throughput is required, optimal results can be achieved by using the attribute store over IBM WebSphere eXtreme Scale. To choose the configuration that best fits your throughput and scalability requirements, see the Developer Center website for IBM MobileFirst Platform Foundation.

Attribute store over the runtime database (default)

Starting from V7.1.0, the attribute store in IBM MobileFirst Platform Server is persisted by default to the runtime database (Cloudant® or relational database). Figure 1 illustrates a server cluster that employs this configuration.

Figure 1. Attribute store over runtime database

Shows attribute store over a runtime database

The following settings in the worklight.properties file determine the default behavior:

mfp.attrStore.type is set to database (default)
mfp.session.independent is set to true (default)

Attribute store over IBM WebSphere eXtreme Scale

The attribute store can be cached in eXtreme Scale, with or without a Loader plug-in for persistence to an SQL or Cloudant database. For more information, see Attribute store over IBM WebSphere eXtreme Scale.

Attribute store over IBM Data Cache for Bluemix

The attribute store data for applications that are deployed in IBM Containers can be cached to IBM Data Cache. For more information, see Deploying to the cloud in an IBM Container and IBM Data Cache for Bluemix.

Important:

In a session-independent configuration, a request can be processed by one server in a cluster and the next request by another. This means that if you apply a fix pack or other change to a farm, particularly if the fix pack includes changes to authentication, all servers must be upgraded at the same time. If the fix pack is not applied to the entire farm at once, requests may fail as they move back and forth between servers where the fix pack has been applied and servers where it has not.
The attribute store module uses serialized objects, so the Java™ Virtual Machine (JVM) of any server must be able to read what the JVM of other servers has serialized. Ensure that all members of a cluster use compatible serialization.

Session-dependent mode

V7.1.0 still allows you to run applications in session-dependent mode, where the attribute store is held in the HTTP session. To work in session-dependent mode, set the mfp.attrStore.type property to httpsession. Also, ensure that you have set the mfp.session.independent property to false, or MobileFirst Server will not come up and an error will be reported. See Configuring session dependency.

Upgrading projects to work in session-independent mode

Projects that are upgraded to work with MobileFirst Server V7.1.0 from earlier versions will remain in session-dependent mode by default.

For more information about upgrading old projects so that they work in session-independent mode, see Upgrading projects to work in session-independent mode.

Developing apps to work in IBM MobileFirst Platform Foundation V7.1.0

In previous versions, certain components of your projects could persist data in the HTTP session. This is no longer possible in session-independent mode:
- IBM MobileFirst Platform Foundation security framework: In session-independent mode, the attribute store is used to save the security state, instead of the HTTP session, which was used in previous versions.
- Applicative state and custom security state: If your existing applications store applicative state or custom security state in the HTTP session, you must adapt your code so that the applicative or security state is held elsewhere
For guidelines on refactoring existing apps away from HTTP sessions see the following topics:
When implementing or upgrading a custom authenticator, refer to the custom-authenticator guidelines for session-independent mode.

Realm expiration

It is important to note that realm expiration is not new in V7.1.0. In previous versions, it was limited by the HTTP session lifespan, and starting from V7.1.0, it is not. To enforce a lifetime for a client's logged-in state, you must configure the expiration of security realms. When the realm expires, the login session ends and the client app is forced to log in again if it tries to access a resource that is protected by this realm, or if it requests a token that contains this realm.

Version 7.0.0 introduced the optional expirationInSeconds configuration element, which you could use for each login module to define the expiration of its realm. Its default setting was -1 to indicate that there was no expiration period and that the login would remain valid until the end of the HTTP session.

Starting with V7.1.0, the login period is entirely dependent on the realm expiration, so the default value for expirationInSeconds is now 3600 seconds (one hour) and in session-independent mode, it is no longer possible to set the value to -1. For more information, see Configuring login modules.