Authenticating users in Liberty
The Liberty server uses a user registry to authenticate a user and retrieve information about users and groups to perform security-related operations, including authentication and authorization.
About this task
To learn about how authentication works in Liberty, see Authentication.
The authentication tasks that you can configure might vary depending on your requirements. Unless you have used the quickStartSecurity element that can configure only one user, you have to configure the user registry at the least. You do not have to configure the values for JAAS, authentication Cache and SSO tasks unless you want to change the default values. Configure TAI configuration only when you have an implementation of TAI interface to handle authentication.
Subtopics
- Configuring a user registry in Liberty
You can store user and group information for authentication in several types of registries. For example you can use a basic user registry, an LDAP registry, or a Custom User Registry. Optionally, you can configure two or more LDAP registries so that the operations are executed on all the configured registries. For example, when you perform an operation of searching a user, the search is performed on all the configured LDAP registries. For z/OS® systems, you can use a SAF registry. Configuring the MicroProfile JSON Web Token
You can configure a Liberty server to accept a MicroProfile JSON Web Token as an authentication token.- Configuring the authentication cache in Liberty
You can modify how authenticated users are cached in Liberty. - Configuring a JAAS custom login module for Liberty
You can configure a custom Java™ Authentication and Authorization Service (JAAS) login module before or after you have configured the Liberty server login module. - Configuring a Java Authentication SPI for Containers (JASPIC) User Feature
You can develop a JASPIC provider to authenticate inbound web requests by using the com.ibm.wsspi.security.jaspi.ProviderService interface that is provided in the Liberty server. - Configuring LTPA in Liberty
You can configure a Liberty server to use a specific Lightweight Third Party Authentication (LTPA) keys file, user-defined password, and expiration time. - OpenID
OpenID is an open standard where users can authenticate themselves to multiple entities without the need to manage multiple accounts or sets of credentials. Liberty supports OpenID 2.0 and plays a role as a Relying Party in web single-sign-on. - OpenID Connect
OpenID Connect is a simple identity protocol and open standard that is built on the OAuth 2.0 protocol that enables client applications to rely on authentication that is performed by an OpenID Connect Provider to verify the identity of a user. - Configuring an OpenID Relying Party in Liberty
You can configure a Liberty server to function as an OpenID Relying Party to take advantage of web single-sign-on. Configuring JSON Web Token in Liberty
You can configure a Liberty server to build and consume JSON Web Token (JWT) tokens, which you can use to propagate user identity or tokens. To build or consume JWTs, configure the JWT builder or consumer in the server configuration, and then implement one of the provided APIs to programmatically build or consume the tokens.Configuring social login in Liberty
You can configure a Liberty server so that users can authenticate to websites that are hosted on the Liberty server by logging in with their social media accounts. Choose from the predefined social media platform configurations, or define your own configuration for any social media platform that is based on the OAuth 2.0 or OpenID Connect 1.0 standards.- Configuring SPNEGO authentication in Liberty
You can use single sign-on for HTTP requests by using the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) web authentication for WebSphere® Application Server Liberty. SPNEGO single sign-on enables HTTP users to log in to a Microsoft® domain controller only once at their desktop and to achieve single sign-on (SSO) with the Liberty server. - Customizing SSO configuration using LTPA cookies in Liberty
With single sign-on (SSO) configuration support, web users can authenticate once when accessing Liberty resources such as HTML, JavaServer Pages (JSP) files, and servlets, or accessing resources in multiple Liberty servers that share the same Lightweight Third Party Authentication (LTPA) keys. - Configuring RunAs authentication in Liberty
You can delegate authentication to another identity by configuring the RunAs specification for Liberty. - Configuring TAI for Liberty
You can configure Liberty to integrate with a third-party security service by using Trust Association Interceptors (TAI). The TAI can be called before or after single sign-on (SSO). - Configuring a custom form login page
Liberty provides the ability to define a custom form login page for users to submit authentication credentials. - Configuring SAML Web Browser SSO in Liberty
You can configure a Liberty server to function as a SAML web browser Single-Sign-On (SSO) service provider. - Configuring SAML Web Inbound Propagation in Liberty
You can configure a Liberty server to accept a SAML token in an HTTP header as an authentication token. This feature is commonly used for a proxy or RESTful client that uses SAML on behalf of an authenticated user. - Using OpenID Connect
OpenID Connect in the Liberty server is implemented as an OAuth 2.0 extension. In addition to providing OpenID Connect functions, the OpenID Connect provider supports all OAuth 2.0 functions. - Authentication Filters
You can use the authentication filter to determine whether certain HTTP servlet requests are processed by certain providers.
Parent topic: Securing Liberty and its applications
Related concepts:

File name: twlp_sec_authenticating.html