Authentication Overview

Most grid applications require users to be authenticated and have an established grid session to allow access to their published services. There are three ways to establish a grid session: log on using a user name and password, log on using a Lawson SSO token or using the public key infrastructure of a grid, and log on using the SSL handshake.

The SSL handshake method is built in to the framework of the grid and is used internally to ensure grid integrity and security. It is possible to provide external grid clients with the necessary key material so that a connection can be made as an authenticated user. Since this is an intrinsic mechanism, no session provider needs to be configured for clients to log on to the grid. This method of connection is used in a bootstrap situation, for example, when the grid is initially installed.

The other two methods are delegated to a pluggable architecture called the session provider. A session provider is a grid application that has been given the special right to define who is allowed to log on and to establish some sort of security context for a user. A session provider offers its services through a grid-provided interface so that other applications can use the services without having to know the implementation details.

A configured session provider is typically needed when you have applications in the grid that require users to be authenticated.

All session providers give a grid administrator a last say in the assignment process through role mapping. Through role mapping, the session provider roles are mapped to grid roles. For more information on role mapping, see Defining role mappings.

The reason for having pluggable authentication architecture is flexibility. The grid framework can never foresee all possible flavors of user storage and credential mechanisms, so it makes sense to decouple that functionality from the grid release cycle. This introduces a dilemma: the application programming interfaces used internally to create a session in the grid must be reachable for every application since a session provider is an ordinary grid application, and as an administrator you would like to have some control over how users are allowed to log in to the grid (or at least you would like to know who is allowed to perform this gatekeeper task). The grid framework solves this by requiring an application that should be allowed to create grid sessions to be registered as a session provider in that particular grid. Only an administrator can grant session provider privileges to an application, thus making this procedure secure. An application that tries to create sessions without being registered as a session provider will fail with an error report.