InfoCenter Home >
5: Securing applications -- special topics >
5.1: The WebSphere security components >
5.1.3: The WebSphere authorization model

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.

Go to previous article: Authentication model Go to next article: Securing resources and applications

 

 
Go to previous article: Authentication model Go to next article: Securing resources and applications