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