Application Security
4.0
3.0
2.0
1.0

This feature enables support for securing the server runtime environment and applications using Security-1.0 as defined in JSR-375.

Enabling this feature

To enable the Application Security 3.0 feature, add the following element declaration into your server.xml file, inside the featureManager element:

<feature>appSecurity-3.0</feature>

Examples

Configure a basic user registry

You can configure Open Liberty to authenticate and authorize users by using a basic user registry. The basic user registry contains user credentials that applications need for security-related tasks. To configure a basic user registry, the Application Security feature must be enabled in the server.xml file. The following example shows the configuration of a basic user registry in the server.xml file:

<basicRegistry id="basic" realm="BasicRealm">
   <user name="Bob" password="bobpwd" />
   <user name="John" password="johnpwd" />
</basicRegistry>

To configure a basic user registry with multiple users, you can create groups for users with unique group names as shown in the following example:

<basicRegistry id="basic" realm="BasicRealm">
  <user name="Bob" password="bobpwd" />
  <user name="John" password="johnpwd" />
  <user name="user1" password="user1pwd"/>
  <user name="user2" password="user2pwd" />

  <group name="myAdmins">
    <member name="Bob" />
    <member name="user1" />
  </group>

  <group name="users">
    <member name="user1" />
    <member name="user2" />
  </group>
</basicRegistry>

User and group names must be unique and cannot contain any trailing or leading spaces. If a user ID or password contains characters other than US-ASCII, make sure that the server.xml file is saved by using UTF-8 character encoding. You can use the securityUtility encode command to encode the password for each user. For more information, see securityUtility encode. You can also specify administrative roles for users and groups to govern access to Open Liberty administrative REST APIs. For more information, see the Admin REST Connector feature.

Configure a basic user registry with QuickStart security

When you want to configure a basic user registry for test purposes, you can use the quickStartSecurity element to automatically configure a registry that grants the administrator role to a user. The administrator role gives the user the authority to manage applications. The following example shows the server.xml file configuration to define the username and password for a user that is granted the administrator role with the quickStartSecurity element:

<quickStartSecurity userName="Bob" userPassword="bobpwd" />

You can use QuickStart security configuration for test purposes. The registry that is configured by this option is not intended for production environments. However, it is useful in test scenarios, particularly for testing secured JMX connections that require administrator access.

Configure LTPA authentication for a subset of requests

You can configure an authentication filter to specify whether certain requests for protected resources are authenticated with LTPA. If the request meets the criteria that are specified in the authentication filter, then the request can authenticate with LTPA to access the protected resource. Conversely, if the request does not meet the criteria that are configured in the LTPA authentication filter, then the user is prompted to provide login credentials. For more information, see Authentication filters.

<ltpa keysFileName="yourLTPAKeysFileName.keys" keysPassword="keysPassword" expiration="120" authFilterRef="myAuthFilter"/>

<authFilter id="myAuthFilter">
         <requestUrl id="myRequestUrl" urlPattern="/SimpleServlet" matchType="contains"/>
</authFilter>

In the example, request URLs that contain the /SimpleServlet pattern are authenticated by using LTPA SSO authentication. If the ltpa element does not specify the authFilterRef attribute, all requests that include an LTPA cookie are processed by LTPA SSO authentication.

Disable LTPA cookies for TAI

LTPA cookies contain secure tokens that are used to verify user credentials and enable SSO. When you don’t want to rely on LTPA tokens for SSO, you can use other methods, such as a Trust Association Interceptor (TAI), for authentication. A TAI is used to validate HTTP requests between a third-party security server and an Open Liberty server to complete authentication. The following example shows how to disable LTPA cookies for TAI by specifying the disableLtpaCookie attribute with a value of true in the server.xml file:

<trustAssociation id="sample" disableLtpaCookie="true" />

Feature configuration elements

Standard API packages provided by this feature

  • javax.security.auth.message

  • javax.security.auth.message.callback

  • javax.security.auth.message.config

  • javax.security.auth.message.module

  • javax.security.enterprise

  • javax.security.enterprise.authentication.mechanism.http

  • javax.security.enterprise.credential

  • javax.security.enterprise.identitystore

Features that this feature enables

Supported Java versions

  • JavaSE-1.8

  • JavaSE-11.0

  • JavaSE-17.0

  • JavaSE-19.0

Features that enable this feature

Developing a feature that depends on this feature

If you are developing a feature that depends on this feature, include the following item in the Subsystem-Content header in your feature manifest file.

com.ibm.websphere.appserver.appSecurity-3.0; type="osgi.subsystem.feature"