Universal Access authentication

The universal-access package exports the Authentication module, which can be used to log in and out of the application and to inspect the details of the current user. The login service is passed a username and password, and optionally a callback function that is called when the authentication request is completed.

Authentication services

The Authentication API supports the following modes:

  • JAAS Authentication (Default)
  • Simple Authentication (Development mode)
  • Single Sign-on (SSO) Authentication
  • Custom authentication

JAAS authentication

By default, the login process uses the standard JAAS login module.

The JAAS login module is exposed through the Social Program Management Universal Access API at the /j_security_check end point, and authenticates the user against the SPM database of users. For more information about JAAS login in SPM, see Authentication Architecture.

Simple authentication (Development Mode)

During development, you can use a simple authentication that does not require an SPM server. This simple authentication bypasses proper authentication (JAAS or SSO) and instead accepts the username dev without any password. The login process runs and allows access to the 'user account' password protected pages.

This simple authentication is sufficient to do most client development work and avoids the need to configure your client application to communicate with an SPM server.

SSO authentication

The application supports single sign-on (SSO), which is a typical use case for many enterprises that serve multiple applications with a single username and password for their clients.

For more information about configuring your application to use SSO, see Configuring SAML SSO on WebSphere Application Server.

Automatically logging in to your SSO

The default SSOVerifier component wraps the whole application and checks for SSO status when the application is loaded for the first time. The SSOVerifier component verifies whether the user is already logged in with SSO and can be logged directly into the application. If the user is not yet authenticated, then they must authenticate as a public citizen so that they can access the system configuration.

The SSOVerifier does the entire precheck within the component, by making all the required calls to determine with the IdP whether the current user is authenticated. SSOVerifier is helped to make these calls by using functions exposed by SSOAuthentication.

If you need custom verification, you must create your own verifier component to replace the current SSOVerifier component. Then, add your custom verifier component to the call stack in your entry JavaScript file, for example App.js.

Custom authentication

You can implement your own custom authentication to suit your specific environment.

User account types

The Universal Access client supports three different user account types, Public, Generated, and Citizen. For more on user accounts and security, see User account types. If you want to customize the log in and sign up process that is provided with the Universal Access starter pack, the Authentication module provides log-in functions to support each of these three user account types.


Authentication.loginAsPublicCitizen

Authentication.loginWithGeneratedUser

Authentication.login

Tracking the logged in user

The Universal Access Responsive Web Application uses 'session storage' in the browser to store some basic details of the currently logged-in user after they are authenticated with the server. This session storage is typically used to inform the client application what views to present. For example, if no user is logged in, then the login and sign-up page buttons are displayed on the home page.

The Authentication module provides functions that query the current logged-in user and their account details, according to the session storage in the browser.

Authentication.getLoggedInUser

Authentication.getUserAccount

Logged in on the client or the server

Citizens can seem to be logged in on the client when they are not logged in on the server. This situation does not compromise the security of the application. The SPM server APIs use session tokens that are stored in cookies to determine whether the current user is authenticated. The cookies are transmitted with each API call, and only a valid token results in a successful response.

For example, if a user's session times out on the server, the next API request to the server results in a 401 unauthorized response, even if the user seems to be logged in to the client application. This behavior ensures that no matter what the client application says about the currently logged-in user, the server responds only to valid session tokens.

For more information, see Configuring user session timeout.