Download PDF Home History |  | API Search Feedback FAQ

> ## 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 Application Server. 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 Application Server, the `file`, `admin-realm`, and `certificate` realms come preconfigured for the Application Server.

> In the `file` realm, the server stores user credentials locally in a file named `keyfile`. You can use the Admin Console to manage users in the `file` realm.

> 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.

> In the `certificate` realm, the server stores user credentials in a certificate database. When using the `certificate` realm, the server uses certificates with the HTTPS protocol to authenticate Web 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.

> The `admin-realm` is also a `FileRealm` and stores administrator user credentials locally in a file named `admin-keyfile`. You can use the Admin Console to manage users in this realm in the same way you manage users in the file realm. For more information, see Managing Users.

> ### Managing Users

> To add authorized users to the Application Server, follow these steps:

> 1. 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.
> 2. 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`.
> 3. Enter the user name and password of a user in the `admin-realm` who belongs to the `asadmin` group. The name and password entered during installation will work, as will any users added to this realm and group subsequent to installation.
> 4. Expand the Configuration node in the Admin Console tree.
> 5. Expand the Security node in the Admin Console tree.
> 6. Expand the Realms node.
> - Select the `file` realm to add users you want to enable to access applications running in this realm.
> - Select the `admin-realm` to add users you want to enable as system administrators of the Application Server.
> 7. Click the Manage Users button.
> 8. Click New to add a new user to the realm.
> 9. Enter the correct information into the User ID, Password, and Group(s) fields.
> - If you are adding a user to the `file` realm, enter the name to identify the user, a password to allow the user access to the realm, and a group to which this user belongs. For more information on these properties, read Realms, Users, Groups, and Roles.
> - If you are adding a user to the `admin-realm`, enter the name to identify the user, a password to allow the user access to the Application Server, and enter `asadmin` in the Group field.
> 10. Click OK to add this user to the list of users in the realm.
> 11. 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 Web application, see Setting Security Requirements Using deploytool.

> 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`:

> 1. Select an application.
> 2. In the Roles tabbed pane, click Add to add a row to the table.
> 3. In the Name column, enter the security role name--for example, `bankCustomer`.
> 4. Click the folded-paper icon to add a description of the security role--for example, Customer-of-Bank.
> 5. Click OK.

> Before you can map the role to users or groups (see Mapping Roles to Users and Groups), you must first create those users or groups (see Managing Users).

> ### 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.

> Figure 32-1 Role Mapping

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

> 1. 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.
> 2. Create or open the Web application in `deploytool`. Creating an application using `deploytool` is discussed in Packaging Web Modules.
> 3. 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 Constraints to add a security constraint to this application.
> 4. Click Add Collections to add a Web resource collection to this application.
> 5. Click Edit Roles to select which roles are authorized to access restricted parts of this application.
> 6. Click Edit Roles in the Authorized Roles for Security Constraint dialog box.
> 7. 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.
> 8. Add both roles to the list of authorized roles by selecting each in turn and clicking Add.
> 9. Click OK to close this dialog.
> 10. Click OK to exit the Authorized Roles dialog box.
> 11. Select the General tabbed pane.
> 12. Select Sun-specific Settings.
> 13. To map the users defined for the Application Server to roles defined for this application, select User to Role Mapping from the View list.
> 14. 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.
> 15. 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 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 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.
> 16. Click Close.

Download PDF Home History |  | API Search Feedback FAQ

All of the material in The J2EE(TM) 1.4 Tutorial is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.