Configure authorization for applications in Liberty

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.

Liberty first extracts user and group mapping information from a user registry. It 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.

When using System Authorization Facility (SAF) authorization, roles are mapped to EJBROLE resource profiles using the SAF role mapper. The server queries SAF to determine whether the user has the required READ access to the EJBROLE resource profile.

  1. Enable a version of the Liberty Application Security feature in the server.xml file. For example: 

          <featureManager>
        <feature>appSecurity-4.0</feature>
    </featureManager>

    Note: If we are using the SAF authorization provider, include the zosSecurity-1.0 feature and define a safAuthorization configuration element in the server.xml file. For example: 

       <featureManager>
     <feature>appSecurity-4.0</feature>
     <feature>zosSecurity-1.0</feature>
 </featureManager> 

 <safAuthorization id="saf" />

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

    See Authenticating users in Liberty.

    If we are using the SAF authorization provider, use the SAF registry and the server must be authorized to use SAF authorized services.

    See Activating and configuring the SAF registry on z/OS.

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

    Note: 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 stand-alone WAR files, we can add the authorization table definitions to the server.xml file under the respective application element. We can use the WebSphere Application Server Developer Tools for Eclipse.

    Notes:

    • 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 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 any conflicts occur, the information from the server.xml file is used.

    • If we modify your 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 the server.xml file, the application must not be in the dropins folder. If we leave it in the dropins folder, then we must disable application monitoring by setting the following element in the server.xml file:

    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 is authenticated by the application server can access the protected resource. The following example shows code that configures 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 if they provide valid credentials for authentication.

    Note: When we enable SAF authorization, we cannot use the ALL_AUTHENTICATED_USERS and EVERYONE special subjects. If we are using SAF authorization, roles are mapped to EJBROLE resource profiles using the SAF role mapper. The SAF role mapper pattern can be configured using the safRoleMapper element in the server.xml file.

    See Control how roles are mapped to SAF Profiles. By default, the role is mapped to a resource profile using the pattern profile_prefix.resource.role, where

    • profile_prefix is defined by the profilePrefix attribute on the safCredentials configuration element. By default, the value of profilePrefix isBBGZDFLT.
    • resource is the resource name; for example, the application name.
    • role is the role name.

    To access the protected resource, the user must have READ access to the EJBROLE resource profile. For example, for user ID gjones to access a protected resource under the role admin for the application myapp, the user gjones must have READ access to the resource profile BBGZDFLT.myapp.admin in the EJBROLE class in the SAF product.

    Note: EJBROLE resource profiles are case-sensitive. The following example code shows sample RACF commands for authorizing a user: 

      rdef EJBROLE BBGZDFLT.myapp.admin uacc(none)
permit BBGZDFLT.myapp.admin class(EJBROLE) access(read) id(gjones)

  5. Optional: Configure an authorization decision when no application bind information exists. When no role mapping binding information is provided for an application, 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 principle 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 succeed with a group name in the user registry, the role name must match the full or unique name of the group in the registry 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, we need to specify CN=swGroup,o=company,c=us as the role name for the authorization to succeed.