Authorization

Authorization in the Liberty profile determines whether a user has access to a certain role within the system.

Authorization specifies access rights to resources. It usually follows authentication that confirms an identity. Whereas authentication answers the question: "Are you who you say we are?"; authorization answers the question: "Do we have permission to do what we are trying to do?"

Authorization for administrative functions

When an entity attempts to access a resource, the authorization service determines whether that entity has the required rights to access the resource. This concept holds true whether an entity is accessing an application or performing administrative functions. The main difference between authorizing access to an application and access to an administrative function lies in how the users are mapped to roles. For authorization of applications, use the application-bnd element in server.xml or the ibm-application-bnd.xml/xmi file to map the users to roles. For authorization of administrative functions, use the administrator-role element in server.xml to map the users to the administrator role. For more information about administrative security, see Access local and JMX REST connectors .

Authorization for applications

1. An authorization is made when an entity attempts to access a resource in an application that is served by the Liberty profile. The web container calls the authorization service to determine whether a user has permission to access a certain resource, given a set of one or more required roles. The required roles are determined by the auth-constraint elements in the deployment descriptor and @ServletSecurity annotations.

2. The authorization service determines what objects the required role is mapped to. This step is accomplished by processing the mappings defined in the ibm-application-bnd.xmi file or the ibm-application-bnd.xml file, and the application-bnd element of server.xml. The mappings from these two sources are merged. If the same role is present in both sources, only the role mapping in the server.xml file is used. The advantage of using server.xml for mapping roles to users is that the application does not need to be packaged into an EAR file and it is easier to update. Alternatively, using the ibm-application-bnd.xmi/xml file makes your application portable to other servers and other full profile servers that do not support server.xml.

3. If the required role is mapped to the EVERYONE special subject, then the authorization service returns immediately to allow anyone access. If the role is mapped to the ALL_AUTHENTICATED_USERS special subject and the user is authenticated, then the authorization service grants access to the user. If none of these conditions are met, then the authorization service determines what users and groups are mapped to the required role. The authorization service grants access to the resource if the user is mapped to the required role or if the user is part of a group that is mapped to the role.

4. The authorization service returns a result back to the web container to indicate whether the user is granted or denied access.

Special subjects

When we map entities to roles, we can map a special subject instead of a specific user or group. A special subject is an extension to the concept of a subject. A special subject can represent a group of users that fall under a specific category.

The following two types of special subjects are available:

• EVERYONE: represents any entity on the system, which means that no security is available because everyone is allowed access and we are not prompted to enter credentials.

• ALL_AUTHENTICATED_USERS: represents any entity that successfully authenticates to the server.

To map a special subject to a user, update either the ibm-application-bnd.xmi/xml file or server.xml, where the application-bnd is under the application element. In this example, the role named AllAuthenticated is mapped to the special subject ALL_AUTHENTICATED_USERS:

    <application-bnd>
           <security-role name="AllAuthenticated">
               <special-subject type="ALL_AUTHENTICATED_USERS" />
           </security-role>
       </application-bnd>

See Configure authorization for applications .

Access IDs and authorization

When we authorize a user or group, the server needs a way to uniquely identify that user or group. The unique ID of the user and group serve this purpose and are used to build the authorization configuration. These IDs are determined by the user registry implementation: the unique user ID is the value of getUniqueUserId(), and the unique group ID is the value of getUniqueGroupId(). We can also choose to explicitly specify an access ID for the user or group in the authorization configuration. These explicit access IDs are used instead of the values that are returned by the user registry implementation. To specify an access ID in the ibm-application-bnd.xml/xmi file or server.xml, where the application-bnd is under the application element, use the access-id attribute for the user or group element.

In this example, an access ID is specified for the user Bob and the group developers:

    <application-bnd>
           <security-role name="Employee">
               <user name="Bob" access-id="user:MyRealm/Bob"/>
               <group name="developers" access-id="group:myRealm/developers"/>
           </security-role>
    </application-bnd>

The access-id attribute is used for the authorization check. If it is not specified, it is determined from the registry configured using the user or group name. However, we must specify the access-id attribute as shown in the example when the users or groups do not belong to the active registry. Such as when using a programmatic login.

Parent topic: Security

Tasks:

Authorizing access to resources

Configure authorization for applications