Configuring authorization for applications in Liberty

Configuring authorization for your 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.

1. Enable the appSecurity Liberty feature in the server.xml file.
   For example:

       <featureManager>
           <feature>appSecurity</feature>
       </featureManager>

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

   See Authenticating users in Liberty.

3. Ensure that the deployment descriptor for your application includes security constraints and other security related information.
   Note: You 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.
   You can configure the authorization table in the following ways:

   • If you have an EAR file, you can add the authorization configuration definition to the ibm-application-bnd.xml or ibm-application-bnd.xmi file.
   • If you have standalone WAR files, you can add the authorization table definitions to the server.xml file under the respective application element. You can use the WebSphere® Application Server Developer Tools for Eclipse to do this.

   Notes:

   • If you 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 your EAR file does not already contain an ibm-application-bnd.xm* file, it is not a straightforward task to create one and you might prefer to add the authorization configuration to the server.xml file.
   • If the authorization configuration for the EAR file is defined in an ibm-application-bnd.xm* file and also in the server.xml file, then the two tables are merged. If there are any conflicts, the information from the server.xml file is used.
   • If you modify your user registry, be sure to review the authorization table for necessary changes. For example, if you are specifying an access-id element and change the realm name of the registry, you must also change the realm name in the access-id element.
   • If you specify the application-bnd element in the server.xml file, your application must not be in the dropins folder. If you leave it in the dropins folder, then you must disable application monitoring by setting the following in your server.xml file:

     <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 you are not prompted to enter credentials. When a role is mapped to the ALL_AUTHENTICATED_USERS special subject, then any user who is authenticated by the application server can access the protected resource.

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

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

5. Optional: Configure an authorization decision when there is no application bind information.
   When the role mapping binding information for a protected application is not provided, the default authorization engine takes the role name that is protecting the resource as the group name associated with that role. So for example, if the role name is manager, then a user who belongs to a manager group has access to that resource. This applies only when no application bind information, in the server.xml or the application binding file, is specified for the application: For example, adding this binding disables the security role to group binding:

   
   <application type="war" id="myapp" name="myapp" 	location="${server.config.dir}/apps/myapp.war">
         <application-bnd>
   	     <security-role name="anyAppRoleName"/>
         </application-bnd>
   </application>

   Note: For an authorization to be successful with a group name in the user registry, the role name must match the full or unique name of the group in the registry that is configured and not the short name. For example, if short name of the group is swGroup but the full or unique name in the user registry is CN=swGroup,o=company,c=us, you need to specify CN=swGroup,o=company,c=us as the role name for the authorization to succeed.