InfoCenter Home >
5: Securing applications -- special topics >
5.1: The WebSphere security components >
5.1.3: The WebSphere authorization model
Authorization information is used to
determine if a caller has the necessary privilege to request a
service. Authorization information can be stored in many ways. For
example, with each resource, you can store a list of users and what
they are permitted to do. Such a list is called an access-control
list. Another way to store the information is to associate with each
user a list of resources and the corresponding privilege held by the
user. This is called a capability list.
WebSphere Application Server uses the Java 2 Enterprise Edition
(J2EE) authorization model. In this model, authorization information
is organized as follows:
- During the assembly of an application, permission to execute methods is granted to one
or more roles. A role is a set of permissions; for example, in a banking
application, roles can include Teller, Supervisor, Clerk, and other industry-related
positions. The Teller role is associated with permissions to run methods related to
managing the money in an account, for example, the withdraw and deposit methods. The
Teller role is not granted permission to close accounts; that permission is given to the
Supervisor role. The application assembler defines a list of method permissions for each
role; this list is stored in the deployment descriptor for the application.
|
AccountBean methods |
AccountServlet methods |
getBalance |
setBalance |
deposit |
withdraw |
closeAccount |
HTTP_GET |
HTTP_DELETE |
Roles |
Teller |
yes |
- |
yes |
yes |
- |
- |
- |
Clerk |
yes |
- |
- |
- |
- |
- |
- |
Supervisor |
- |
yes |
- |
- |
yes |
- |
yes |
WebTeller |
- |
- |
- |
- |
- |
yes |
- |
Role-to-method mapping
There are two special subjects that are not defined by J2EE but are worth mentioning,
AllAuthenticatedUsers and Everyone, and a special role, DenyAllRole. A special subject
is Websphere-defined entity that is independent of the user registry. It is used to
generically represent a class of users or groups in the registry.
- AllAuthenticatedUsers is a special subject that permits all authenticated users
to access protected methods. As long as the user can authenticate successfully, the user
is permitted access to the protected resource.
- Everyone is a special subject that permits unrestricted access to a protected resource.
Users do not have to authenticate to get access; this special subject allows access to
protected methods as if the resources are unprotected.
- DenyAllRole is a special role that is assigned by default to a partially
protected resource. For instance, if an enterprise bean has four methods and only three
are explicitly protected, the fourth method is associated with the DenyAllRole. This role
denies everyone access to the methods it is associated with. The DenyAllRole is never
mapped to any users or groups; it is always empty.
- During the deployment of an application, real users or groups of users are assigned to
the roles. The application deployer does not need to understand the individual methods. By
assigning roles to methods, the application assembler simplifies the job of the
application deployer; instead of working with a set of methods, the deployer works with
the roles, which represent semantic groupings of the methods. When a user is assigned to a
role, the user gets all the method permissions that are granted to that role. Users can be
assigned to more that one role; the permissions granted to the user are the union of the
permissions granted to each role. Additionally, if the authentication mechanism supports
the grouping of users, these groups can be assigned to roles. Assigning a group to a role
has the same effect as assigning each individual user to the role.
A "best
practice" during deployment is to assign groups, rather than individual users, to
roles for the following reasons:
- It improves performance during the authorization check. There are typically far fewer
groups than users.
- For AEs, it can greatly improve application server startup time.
- It provides greater flexibility, by using group membership to control resource access.
- Users can be added to and deleted from groups outside of the WebSphere environment. This
is preferred to adding and removing them to WebSphere roles; the enterprise application
must be stopped and restarted for such changes to take effect, and this can be very
disruptive in a production environment.
|
Roles |
Teller |
Clerk |
Supervisor |
WebTeller |
Subjects |
TellerGroup |
yes |
- |
- |
yes |
Bob |
yes |
yes |
- |
yes |
ClerkGroup |
- |
yes |
- |
- |
Supervisor |
- |
- |
yes |
- |
Subject-to-role mapping
- At execution time, WebSphere Application Server authorizes incoming requests based on
the user's identification information and the mapping of the user to roles. If the user
belongs to any role that has permission to execute a method, the request is authorized. If
the user does not belong to any role that has permission, the request is denied.
The J2EE approach represents a declarative approach to authorization, but it also
recognizes that not all situations can be dealt with declaratively. For those situations,
methods are provided for determining user and role information programmatically. For
Enterprise JavaBeans, the following two methods are supported by WebSphere Application
Server:
- getCallerPrincipal: This method retrieves the user's identification information.
- isCallerInRole: This method checks the user's identification information against a
specific role.
For servlets, the following methods are supported by WebSphere Application Server:
- getRemoteUser
- isUserInRole
- getUserPrincipal
These methods correspond in purpose to the enterprise-bean methods.
|
|