Application Security
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

Basic user registry configuration

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>

QuickStart security configuration

When you want to configure a basic user registry, 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. To configure a basic user registry with the quickStartSecurity element, the Application Security feature must be enabled in the server.xml file. 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" />

LTPA configuration

When the Application Security feature is enabled, Lightweight Third Party Authentication (LTPA) is enabled by default. The following example shows the configuration of the ltpa element in the server.xml file:

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

LTPA configuration can provide Single Sign-on (SSO) to secure applications. For more information, see Single sign-on (SSO).

Disable LTPA cookies for TAI

LTPA cookies contain secure tokens that are used to verify user credentials and enable SSO. Trust Association Interceptors (TAI) are 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 disableLtpaCookie with a value of true in the server.xml file:

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

Administrative REST API access role configuration

You can configure roles for your Open Liberty server to grant users and groups that are defined in a user registry access to select administrative REST APIs. The administrator role (administrator-role) provides read and write access to administrative REST APIs. The reader role (reader-role) provides read-only access to administrative REST APIs. Users who are in the reader role can monitor the server but do not have permission to modify it in any way.

In the following example, a user who is named Bob and a group that is named employees are granted the reader role. A user who is named Wanda and a group that is named managers are granted the administrator role:

<reader-role>
    <user>Bob</user>
    <group>employees</group>
</reader-role>

<administrator-role>
    <user>Wanda</user>
    <group>managers</group>
</administrator-role>

If you prefer to use access IDs to identify users or groups, you can use the user-access-id or group-access-id elements, as shown in the following example:

<reader-role>
    <user-access-id>user:BasicRealm/Bob</user-access-id>
    <group-access-id>group:BasicRealm/employees</group-access-id>
</reader-role>

<administrator-role>
    <user-access-id>user:BasicRealm/Wanda</user-access-id>
    <group-access-id>group:BasicRealm/managers</group-access-id>
</administrator-role>

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-15.0

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"