Home TOC

Search Feedback

Authorization

Authorization mechanisms limit interactions with resources to collections of users or systems for the purpose of enforcing integrity, confidentiality, or availability constraints. Such mechanisms allow only authentic caller identities to access components. Mechanisms provided by the J2SE platform can be used to control access to code based on identity properties, such as the location and signer of the calling code. In the J2EE distributed component programming model, additional authorization mechanisms are required to limit access to called components based on who is using the calling code. As mentioned in the section on authentication, caller identity can be established by selecting from the set of authentication contexts available to the calling code. Alternatively, the caller may propagate the identity of its caller, select an arbitrary identity, or make the call anonymously.

In all cases, a credential is made available to the called component. The credential contains information describing the caller through its identity attributes. In the case of anonymous callers, a special credential is used. These attributes uniquely identify the caller in the context of the authority that issued the credential. Depending on the type of credential, it may also contain other attributes which define shared authorization properties (for example, group memberships) that distinguish collections of related credentials. The identity attributes and shared authorization attributes appearing in the credential are referred to together as the caller's security attributes. In the J2SE platform, the identity attributes of the code used by the caller may also be included in the caller's security attributes. Access to the called component is determined by comparing the caller's security attributes with those required to access the called component.

In the J2EE architecture, a container serves as an authorization boundary between callers and the components it hosts. The authorization boundary exists inside the container's authentication boundary, so that authorization is considered in the context of successful authentication. For inbound calls, the container compares security attributes from the caller's credential with the access control rules for the target component. If the rules are satisfied, the call is allowed. Otherwise, the call is rejected.

There are two fundamental approaches to defining access control rules: capabilities and permissions. The capabilities approach focuses on what a caller can do. The permissions approach focuses on who can do something. The J2EE application programming model focuses on permissions. In the J2EE architecture, the Deployer maps the permission model of the application to the capabilities of users in the operational environment.

Declaring Roles

When you design an enterprise bean, you should keep in mind what types of users will access the bean. For example, an Account enterprise bean might be accessed by customers, bank tellers, and branch managers. Each of these user categories is called a role.

A J2EE group also represents a category of users, but it has a different scope than a role. A J2EE group is designated for the entire J2EE server, whereas a role covers only a specific application in a J2EE server.

To create a role for an application, you declare it for the EJB JAR or web component WAR files that are contained in the application. For example, to create a role for an enterprise bean, follow this procedure in the deploytool:

1. In the tree view, select the enterprise bean's EJB JAR file.
2. In the Roles tabbed pane, click Add.
3. In the table, enter values for the Name and Description fields.

Declaring Method Permissions

After you've defined the roles, you can define the method permissions of an enterprise bean. Method permissions indicate which roles are allowed to invoke which methods.

You use deploytool to specify method permissions by mapping roles to methods:

1. Select the enterprise bean in the tree view.
2. Select the Security tabbed pane.
3. In the Method Permissions table, select a role's checkbox if that role should be allowed to invoke a method.

Declaring Role References

A security role is an application-specific logical grouping of users, classified by common traits such as customer profile or job title. When an application is deployed, roles are mapped to security identities, such as principals or groups, in the operational environment.

A security role reference references a security role name. This security role reference is linked to the security role name that is defined for an assembled application.

To add a security role reference, you use deploytool:

1. Select the enterprise bean in the tree view.
2. Select the Security tabbed pane.
3. Click the Add button.
4. Enter the name of the security role reference in the Coded Name column.
5. Click Edit Roles if the security role name to which you want to map is not listed in the Role Name column.
6. Select the security role name that maps to the coded name from the drop-down menu in the Role Name column.
7. Indicate which role has access to which methods by selecting the appropriate checkboxes in the Method permissions panel.

Mapping Roles to J2EE Users and Groups

When you are developing an enterprise bean, you should know the roles of your users, but you probably won't know exactly who the users will be. That's perfectly all right, because after your bean has been deployed, the administrator of the J2EE server will map the roles to the J2EE users (or groups) of the default realm. In the Account bean example, the administrator might assign the user Sally to the Manager role, and the users Bob, Ted, and Clara to the Teller role.

Using deploytool, the administrator maps roles to J2EE users and groups by following these steps:

1. In the tree view, select the J2EE application.
2. In the Security tabbed pane, select the appropriate role from the Role Name list.
3. Click Add.
4. In the Users dialog box, select the users and groups that should belong to the role. (The users and groups were created with the command-line realmtool.)

By default, the Role Name table assigns the ANYONE role to a method. The guest user, which is anonymous and unauthenticated, belongs to the ANYONE role. Therefore, if you do not map the roles, any user may invoke the methods of an enterprise bean.

Linking Role References to Roles

TBD.

Configuring J2SE Security Policy Files

The J2EE server policy file is named server.policy. It resides in the $J2EE_HOME/lib/security directory. The J2EE application client policy file, client.policy, resides in the same directory.

For more information on setting up security policy files to grant required permissions, see Security in JDK 1.2.

Determining the Caller Identity

TBD.

Making Portable Access Decisions Programmatically from Components

TBD. This section will describe how to use the isCallerInRole method from components. This section is related to a previous section that described linking role references. We may want to talk about portable ways to do finer-grained scoping of programmatic enforcement of access control policy. This is done by selecting the right role/privilege to test for. By embedding the name of the privilege to test for in the component state, and possibly even going so far as to test that the caller is a one or more of a set of specific principals whose names are capture in the state of the component.

Home TOC

Search Feedback