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

5.1.3.2: Role-based authorization scenarios

This article describes the steps taken by WebSphere Application Server to authorize requests. The two scenarios are based on a banking application that includes both an enterprise bean called AccountBean and a servlet called AccountServlet. The following tables define the application's role-to-method mapping and user-to-role mapping:

Role-to-method mapping
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 -
Subject-to-role mapping
Roles
Teller Clerk Supervisor WebTeller
Subjects TellerGroup yes - - yes
Bob yes yes - yes
ClerkGroup - yes - -
Supervisor - - yes -

Authorizing a request to an enterprise bean

When a client attempt to execute a method on the home or remote interface of an enterprise bean, WebSphere Application Server must determine whether the user ID, or principal, of the client is in a role that is authorized to execute the method.

Scenario: A request attempts to execute the getBalance method on the enterprise bean AccountBean. To authorize this request, WebSphere Application Server does the following:

  1. Determines the calling client's principal. If the principal cannot be determined, the request is rejected. Suppose that the user Bob is identified as the calling principal.
  2. Determines the set of roles permitted to invoke the getBalance method. The role-to-method mapping table indicates that both the Teller and the Clerk roles are authorized to execute the getBalance method.
  3. Determines if the calling principal is in at least one of the authorized roles. The user-to-role mapping table indicates that Bob is in the Teller, Clerk, and WebTeller roles, so the authorization requirements are met.
  4. Determines whether the security policy specifies a different identity to use for invoking the method and any subsequent methods it calls.
  5. Invokes the requested method.

Authorizing a request to a Web resource

When a Web browser attempts to execute a method on a Web resource, WebSphere Application Server must determine whether the user ID, or principal, of the client is in a role that is authorized to execute the request on the Web resource.

Scenario: A request attempts to execute the HTTP_GET method for the servlet AccountServlet. To authorize this request, WebSphere Application Server does the following:

  1. Challenge the user for authentication information. Suppose that the user ID and password for Bob are successfully authenticated.
  2. Determine the set of roles permitted to invoke the HTTP_GET method. The role-to-method mapping table indicates that the WebTeller role is authorized to execute the HTTP_GET method.
  3. Determine if the calling principal is in at least one of the authorized roles. The user-to-role mapping table indicates that Bob is in the Teller, Clerk, and WebTeller roles, so the authorization requirements are met.
  4. Invoke the requested method.

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

 

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