Realms, Users, Groups, and Roles

A J2EE user is similar to an operating system user. Typically, both types of users represent people. However, these two types of users are not the same. The J2EE server authentication service has no knowledge of the user name and password you provide when you log on to the operating system. The J2EE server authentication service is not connected to the security mechanism of the operating system. The two security services manage users that belong to different realms.

The J2EE server's authentication service includes and interacts with the following components:

Realm: A collection of users and groups that are controlled by the same authentication policy.

User: An individual (or application program) identity that has been defined in the Sun Java System Application Server Platform Edition 8.0. Users can be associated with a group.

Group: A set of authenticated users, classified by common traits, defined in the Application Server.

Role: An abstract name for the permission to access a particular set of resources in an application. A role can be compared to a key that can open a lock. Many people might have a copy of the key. The lock doesn't care who you are, only that you have the right key.

The J2EE server authentication service can govern users in multiple realms. In this release of the Sun Java System Application Server Platform Edition 8.0, the file and certificate realms come preconfigured for the Application Server.

When using the file realm, the server authentication service verifies user identity by checking the file realm. This realm is used for the authentication of all clients except for Web browser clients that use the HTTPS protocol and certificates.

A J2EE user of the file realm can belong to a J2EE group. (A user in the certificate realm cannot.) A J2EE group is a category of users classified by common traits, such as job title or customer profile. For example, most customers of an e-commerce application might belong to the CUSTOMER group, but the big spenders would belong to the PREFERRED group. Categorizing users into groups makes it easier to control the access of large numbers of users. The section EJB-Tier Security explains how to control user access to enterprise beans.

When the authentication service is using the certificate realm, certificates are used with the HTTPS protocol to authenticate Web browser clients. To verify the identity of a user in the certificate realm, the authentication service verifies an X.509 certificate. For step-by-step instructions for creating this type of certificate, see Understanding Digital Certificates. The common name field of the X.509 certificate is used as the principal name.

Managing Users

Start the Application Server if you haven't already done so. Information on starting the Application Server is available in Starting and Stopping the Application Server.

Start the Admin Console if you haven't already done so. You can start the Admin Console by starting a Web browser and browsing to http://localhost:4848/asadmin. If you changed the default Admin port during installation, enter the correct port number in place of 4848.

Enter the user name and password provided during installation.

Expand the Security node in the Admin Console tree.

Expand the Realms node.

Select the file realm.

Click the Manage Users button.

Click New to add a new user to the file realm.

Enter the correct information into the User ID, Password, and Group(s) fields. Click OK to add this user to the list of users in the file realm.

Click Logout when you have completed this task.

Setting Up Security Roles

When you design an enterprise bean or Web component, you should always think about the kinds of users who will access the component. For example, a Web application for a human resources department might have a different request URL for someone who has been assigned the role of admin than for someone who has been assigned the role of director. The admin role may let you view some employee data, but the director role enables you to view salary information. Each of these security roles is an abstract logical grouping of users that is defined by the person who assembles the application. When an application is deployed, the deployer will map the roles to security identities in the operational environment, as shown in Figure 32-1.

A J2EE group also represents a category of users, but it has a different scope from a role. A J2EE group is designated for the entire Application Server, whereas a role is associated only with a specific application in the Application Server.

To create a role for a J2EE application, declare it for the application EAR file. For example, you could use the following procedure to create a role using deploytool:

Select an application.

In the Roles tabbed pane, click Add to add a row to the table.

In the Name column, enter the security role name--for example, bankCustomer.

Click the folded-paper icon to add a description of the security role--for example, Customer-of-Bank.

Click OK.

Mapping Roles to Users and Groups

When you are developing a J2EE application, you don't need to know what categories of users have been defined for the realm in which the application will be run. In the J2EE platform, the security architecture provides a mechanism for automatically mapping the roles defined in the application to the users or groups defined in the runtime realm. After your application has been deployed, the administrator of the Application Server will map the roles of the application to the users or groups of the file realm, as shown in Figure 32-1.

Use deploytool to map roles defined for an application to J2EE users, groups, or both:

Add authorized users and groups to the file realm using the Admin Console as discussed in Managing Users. You must define the users and groups for the Application Server before you can map them to application security roles.

Create or open the Web application in deploytool. Creating an application using deploytool is discussed in Packaging Web Modules.

Select the Web application in the deploytool tree. Select the Security tabbed pane. We use the Security tabbed pane to add a security constraint to the Web application. If you would like more information on security constraints, read Protecting Web Resources. Click Add Constraint to add a security constraint to this application.

Click Add Collections to add a Web resource collection to this application.

Click Edit Roles to select which roles are authorized to access restricted parts of this application.

Click Edit Roles in the Authorized Roles for Security Constraint dialog box.

Click Add to add a new role. Click in the cell that is created under Name. For this example, add the roles of CUSTOMER and MANAGER. Click OK to exit this dialog box.

Add both roles to the list of authorized roles by selecting each in turn and clicking Add.

Click OK to exit the Authorized Roles dialog box.

Select the General tabbed pane.

Select Sun-specific Settings.

To map the users defined for the Application Server to roles defined for this application, select User to Role Mapping from the View list.

Select a role name--for example, MANAGER--in the Roles pane. These are the role names you defined in the Authorized Roles for Security Constraint dialog box.

Click the Edit button under either Users or Groups. (If you do not see the users or groups that you defined for the Application Server, you may need to log on to the Admin Server before continuing.) Use this dialog box to select a specific user or group to map to the MANAGER role. Then click Add. If you selected a user, the name of the user will display in the Users Name pane when the MANAGER role is selected in the Role Name pane. If you selected a group, the name of the group will display in the Groups Name pane when the MANAGER role is selected. When you defined users using the Admin Console, you provided them with a name, password, and group. Any users assigned to the group selected in this step will have access to the restricted Web application.