Liberty profile: Authorization

Authorization in the Liberty profile determines whether a user has access to a given 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 you are?"; authorization answers the question: "Do you have permission to do what you are trying to do?"

The following sections describe these concepts in detail:

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 the server.xml file 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 the server.xml file to map the users to the administrator role. For more information about administrative security, See Connecting to the Liberty profile by using JMX.

Authorization for applications

The following diagram describes how authorization works for applications:

Figure 1. Overview of authorization process The authorization service checks the mappings of roles to users in the configuration files of the application and server, then grants or rejects the access request.
  1. Authorization is performed when an entity attempts to access a resource in an application 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 the server.xml file. 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 the server.xml file for mapping roles to users is that your 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 the server.xml file.
  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 you map entities to roles, you 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 you are not prompted to enter credentials.
  • ALL_AUTHENTICATED_USERS: represents any entity that has successfully authenticated to the server.
To map a special subject to a user, update either the ibm-application-bnd.xmi/xml file or the server.xml file. 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 Configuring authorization for applications on the Liberty profile.

Access IDs and authorization

When authorizing 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(). You 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 returned by the user registry implementation. To specify an access ID in the ibm-application-bnd.xml/xmi file or the server.xml file, 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>
Avoid trouble: Specifying access IDs is not encouraged because you must code the unique IDs and realm name within your code, which causes problems when you want to modify your user registry.

Icon that indicates the type of topic Concept topic

Terms and conditions for information centers | Feedback


Timestamp icon Last updated: Monday, 21 April 2014
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-mp&topic=cwlp_authorization
File name: cwlp_authorization.html