This feature enables support for securing the server runtime environment and applications; it includes a basic user registry. This feature supersedes appSecurity-1.0 and does not include servlet-3.0 or support for the LDAP user registry. To secure web applications, add the servlet-3.0 feature. To secure EJB applications, add the ejbLite-3.1 feature. To use LDAP, add the ldapRegistry-3.0 feature. When you add the appSecurity-2.0 feature to your server, you need to configure a user registry, such as the basic user registry or the LDAP user registry.
Enabling this feature
To enable the Application Security 2.0 feature, add the following element declaration into your
server.xml file, inside the
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
<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>
Configure a basic user registry with QuickStart security
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 userName="Bob" userPassword="bobpwd" />
You can use QuickStart security configuration for test purposes.
Specify LTPA keys
When the Application Security feature is enabled, Lightweight Third Party Authentication (LTPA) is enabled by default. You can override the default settings for the
ltpa element by configuring the
ltpa element in the
server.xml file. The following example shows how to configure the
<ltpa keysFileName="yourLTPAKeysFileName.keys" keysPassword="keysPassword" expiration="120" />
You can replace the attribute values in the example with custom values. LTPA configuration can provide Single Sign-on (SSO) to secure applications. For more information, see Single sign-on (SSO).
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.
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
<trustAssociation id="sample" disableLtpaCookie="true" />
Configure REST API management roles
You can configure management 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
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>