Authentication
For an application to be secure, it must be able to determine who its users are. Authentication is the process of confirming a user’s identity.
Open Liberty authenticates users by collecting credentials from them, such as a username and password, and checking these credentials against a configured user registry. Authentication is completed in different ways, depending on the details of an application and the resources that are available to it. For microservice-based applications, authentication must be lightweight and configurable, since any user request might need to authenticate to multiple services. In many cases, a user’s credentials are placed in a token that can be passed from the server to different services to authenticate requests for protected resources.
For example, a user of a streaming music service might want to listen to a song, learn about the artist, and get recommendations for similar artists. Each of these tasks requires access to a different service, but authenticating to each service separately expends time and resources. Open Liberty supports a number of different mechanisms for single sign-on (SSO) authentication so that a user or service authenticates only one time to access the various resources in an application. For example, the Social Media Login feature enables users of an application that is running on Open Liberty to authenticate with social media credentials. After authentication, an application can either construct a JSON Web Token (JWT) or obtain one from the social media service or associated SSO identity provider. Open Liberty provides the JSON Web Token feature to construct JWTs for an application on the server. This JWT can then authenticate the user to other services that the application communicates with.
The following diagram shows the authentication process when a user requests access to protected resources from an application that is running on an Open Liberty server:
In the previous diagram, the following events occur:
A user requests access to protected resources in an application from a browser.
Open Liberty redirects the browser to an SSO identity provider. The SSO identity provider might be a social media service or a web authentication service, such as SPNEGO, depending on the application security configuration.
The user provides security credentials, such as a username and password, to the SSO identity provider.
The SSO identity provider authenticates the user by sending data about the user’s identity and security group membership back to the application. Open Liberty uses this information to determine the user’s security roles for the application and its associated resources.
Open Liberty uses this authentication data to construct a JWT. This JWT contains information about the user’s identity and security roles that is used to authenticate the user and authorize access to protected resources from other services.
The application communicates with other services, such as APIs, to complete the user’s request. These services use the JWT to authenticate the user’s identity and authorize access to resources that are permitted for the user’s security role.
The application sends the resources that the user requested.
JAAS authentication
Open Liberty relies on the Java Authentication and Authorization Service (JAAS) framework, a Jakarta EE standard, to authenticate users. JAAS specifies named login contexts, which are made up of different login modules, to authenticate a user. Open Liberty contains a number of built-in login contexts and login modules. You can also configure login modules and login contexts to customize authentication details. During authentication, the JAAS login modules authenticate the user’s credentials and load user and group information. Depending on the kind of credentials that are provided, the user and group information might be fetched from a user registry or an SSO token. For more information, see the JAAS authentication tutorial.
User registries
A user registry is a data source that contains security information about a set of users. When a user requests a protected resource in an application, the user’s credentials are checked against the information in one or more user registries. Open Liberty provides an easy-to-use basic user registry for developers to use in test environments. Typically, applications in production are configured to use an external user registry, such as a Lightweight Directory Access Protocol (LDAP) user registry.
If your application needs to reference a user registry other than a basic or LDAP user registry, you can configure a custom user registry by implementing the UserRegistry API. This API enables support for virtually any type of account repository.
Open Liberty supports multiple user registries and federates them into a single logical view. Information from LDAP, basic, and custom user registries can be federated into a common user registry to manage application security.
For more information, see User registries for application security.
Single sign-on
With single sign-on (SSO), users can authenticate at one location and access multiple servers or services without being repeatedly prompted to log in. SSO is especially important for microservice-based applications, where a single user request might require authentication to several different microservices.
When a user authenticates to one Open Liberty server, an SSO token is created for that user and is put in a cookie. The cookie is then sent to the HTTP client, for example, a browser. If the same user makes a request to access another application that is on a different server, but in the same SSO configuration, the cookie is sent along with the request. If the receiving server can validate the token, the user is authenticated without being prompted for another login. If the server cannot validate the token, for example, because of an LTPA key mismatch, the user is prompted to enter their credential information again.
Open Liberty supports various solutions for SSO authentication, including the following options:
The authentication cache
Because the creation of a subject might affect performance, Open Liberty provides an authentication cache to store a subject after a user authentication is successful. This cache is available by default when the Application Security (Jakarta Security) feature is enabled in your server.xml file. You can customize the details of the authentication cache by specifying the authCache element.
You can also configure a distributed authentication cache that is shared among a group of Open Liberty servers that use the same set of users and groups by using JCache.
For more information, see Configure the authentication cache.
The logged-out cookie cache
If a single sign-on (SSO) cookie for a logged-out user is persisted and presented to the server again, it is validated based on the expiration time and the LTPA encryption keys. However, you can configure the server to track logged-out SSO cookies so that if they are presented again, the user must authenticate again. You can track logged-out SSO cookies on a single server or across multiple servers that share SSO data and configuration. For more information, see Track logged-out SSO cookies.
