Configure authorization for applications on the Liberty profile

Configure authorization for the application is to verify whether a user or group belongs to a specified role, and whether this role has the privilege to access a resource.

The Liberty profile server extracts user and group mapping information from a user registry, then checks the authorization configuration for the application to determine whether a user or group is assigned to one of the required roles. Then the server reads the deployment descriptor of the application, to determine whether the user or group has the privilege to access the resource.

1. Enable the appSecurity-2.0 Liberty feature in server.xml.

   For example:

       <featureManager>
           <feature>appSecurity-2.0</feature>
       </featureManager>

2. Configure a user registry for authentication on the Liberty profile server.

   See Authenticate users .

3. Ensure that the deployment descriptor for the application includes security constraints and other security related information.

   We can also use a tool such as Rational Application Developer to create the deployment descriptor.

4. Configure the authorization information such as the user and group to role mapping.

   We can configure the authorization table in the following ways:

   • If we have an EAR file, we can add the authorization configuration definition to the ibm-application-bnd.xml or ibm-application-bnd.xmi file.

   • If we have standalone WAR files, we can add the authorization table definitions to server.xml under the respective application element. We can use the WebSphere Application Server Developer Tools for Eclipse to do this.

   • If we have an EAR file, the authorization configuration might already exist. In EAR files that are written to the current specification, this information is stored in an ibm-application-bnd.xml file; in older EAR files, this information is stored in an ibm-application-bnd.xmi file.

   • If the EAR file does not already contain an ibm-application-bnd.xm* file, it is not a straightforward task to create one and we might prefer to add the authorization configuration to server.xml.

   • If the authorization configuration for the EAR file is defined in an ibm-application-bnd.xm* file and also in server.xml, then the two tables are merged. If there are any conflicts, the information from server.xml is used.

   • If we modify the user registry, be sure to review the authorization table for necessary changes. For example, if we are specifying an access-id element and change the realm name of the registry, we must also change the realm name in the access-id element.

   • If we specify the application-bnd element in server.xml, the application must not be in the dropins folder. If you leave it in the dropins folder, then we must disable application monitoring by setting the following in server.xml:
     <applicationMonitor dropinsEnabled="false" />

   A role can be mapped to a user, a group, or a special subject. The two types of special subject are EVERYONE and ALL_AUTHENTICATED_USERS. When a role is mapped to the EVERYONE special subject, there is no security because everyone is allowed access and we are not prompted to enter credentials. When a role is mapped to the ALL_AUTHENTICATED_USERS special subject, then any user who has been authenticated by the application server can access the protected resource.

   Here is example code for configuring the user and group to role mapping in server.xml:

   <application type="war" id="myapp" name="myapp" location="${server.config.dir}/apps/myapp.war">
    <application-bnd>
     <security-role name="user">
      <group name="students" />
     </security-role>
     <security-role name="admin">
      <user name="gjones" />
               <group name="administrators" />
     </security-role>
     <security-role name="AllAuthenticated">
      <special-subject type="ALL_AUTHENTICATED_USERS" />
     </security-role>
    </application-bnd>
   </application>

   In this example, the admin role is mapped to the user ID gjones and all users in the group administrators. The AllAuthenticatedRole is mapped to the special subject ALL_AUTHENTICATED_USERS, meaning that any user has access as long as they provide valid credentials for authentication.

Parent topic: Authorizing access to resources

Concepts:

Authorization

Role-based authorization

Tasks:

Authenticate users

Configure a basic user registry