Movatterモバイル変換

Working with Realms, Users, Groups, and Roles

You often need to protect resources to ensure that onlyauthorized users haveaccess.Authorization provides controlled access to protected resources. Authorization is based on identification andauthentication.Identification is a process that enables recognition of an entity by asystem, andauthentication is a process that verifies the identity of a user,device, or other entity in a computer system, usually as a prerequisite toallowing access to resources in a system. These concepts are discussed in moredetail inCharacteristics of Application Security.

This section discusses setting up users so that they can be correctly identifiedand either given access to protected resources, or denied access if the useris not authorized to access the protected resources. To authenticate a user, youneed to follow these basic steps:

The Application Developer writes code to prompt the user for their user name and password. The different methods of authentication are discussed inSpecifying an Authentication Mechanism.
The Application Developer communicates how to set up security for the deployed application by use of a deployment descriptor. This step is discussed inSetting Up Security Roles.
The Server Administrator sets up authorized users and groups on the Application Server. This is discussed inManaging Users and Groups on the Application Server.
The Application Deployer maps the application’s security roles to users, groups, and principals defined on the Application Server. This topic is discussed inMapping Roles to Users and Groups.

What Are Realms, Users, Groups, and Roles?

A realm is defined on a web or application server. It contains acollection of users, which may or may not be assigned to a group,that are controlled by the same authentication policy. Managing users on the ApplicationServer is discussed inManaging Users and Groups on the Application Server.

An application will often prompt a user for their user name andpassword before allowing access to a protected resource. After the user has entered theiruser name and password, that information is passed to the server, which eitherauthenticates the user and sends the protected resource, or does not authenticate theuser, in which case access to the protected resource is denied. This typeof user authentication is discussed inSpecifying an Authentication Mechanism.

In some applications, authorized users are assigned to roles. In this situation, therole assigned to the user in the application must be mapped to agroup defined on the Application Server.Figure 28-6 shows this. More information onmapping roles to users and groups can be found inSetting Up Security Roles.

Figure 28-6 Mapping Roles to Users and Groups

Diagram of role mapping, showing creation of users and groups, definition of roles, and mapping of roles to users and groups

The following sections provide more information on realms, users, groups, and roles.

What Is a Realm?

For a web application, arealm is a complete database ofusers andgroups that identify valid users of a web application (or a set ofweb applications) and are controlled by the same authentication policy.

The Java EE server authentication service can govern users in multiple realms. Inthis release of the Application Server, thefile,admin-realm, andcertificate realmscome preconfigured for the Application Server.

In thefile realm, the server stores user credentials locally in a filenamedkeyfile. You can use the Admin Console to manage users in thefile realm.

When using thefile realm, the server authentication service verifies user identity bychecking thefile realm. This realm is used for the authentication of allclients except for web browser clients that use the HTTPS protocol and certificates.

In thecertificate realm, the server stores user credentials in a certificate database.When using thecertificate realm, the server uses certificates with the HTTPS protocolto authenticate web clients. To verify the identity of a user in thecertificate realm, the authentication service verifies an X.509 certificate. For step-by-step instructions for creatingthis type of certificate, seeWorking with Digital Certificates. The common name field of theX.509 certificate is used as the principal name.

Theadmin-realm is also aFileRealm and stores administrator user credentials locally ina file namedadmin-keyfile. You can use the Admin Console to manageusers in this realm in the same way you manage users in thefile realm. For more information, seeManaging Users and Groups on the Application Server.

What Is a User?

Auser is an individual (or application program) identity that has been definedin the Application Server. In a web application, a user can have aset ofroles associated with that identity, which entitles them to access allresources protected by those roles. Users can be associated with a group.

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

What Is a Group?

Agroup is a set of authenticatedusers, classified by common traits, definedin the Application Server.

A Java EE user of thefile realm can belong to anApplication Server group. (A user in thecertificate realm cannot.) An Application Servergroup is a category of users classified by common traits, such as jobtitle or customer profile. For example, most customers of an e-commerce application mightbelong to theCUSTOMER group, but the big spenders would belong to thePREFERRED group. Categorizing users into groups makes it easier to control the accessof large numbers of users.

An Application Servergroup has a different scope from arole. An ApplicationServer group is designated for the entire Application Server, whereas a role isassociated only with a specific application in the Application Server.

What Is a Role?

Arole is an abstract name for the permission to access a particularset of resources in an application. Arole can be compared to akey that can open a lock. Many people might have a copyof the key. The lock doesn’t care who you are, only that youhave the right key.

Some Other Terminology

The following terminology is also used to describe the security requirements of theJava EE platform:

Principal: A principal is an entity that can be authenticated by an authentication protocol in a security service that is deployed in an enterprise. A principal is identified using a principal name and authenticated using authentication data.
Security policy domain (also known assecurity domain orrealm): A security policy domain is a scope over which a common security policy is defined and enforced by the security administrator of the security service.
Security attributes: A set of security attributes is associated with every principal. The security attributes have many uses, for example, access to protected resources and auditing of users. Security attributes can be associated with a principal by an authentication protocol.
Credential: A credential contains or references information (security attributes) used to authenticate a principal for Java EE product services. A principal acquires a credential upon authentication, or from another principal that allows its credential to be used.

Managing Users and Groups on the Application Server

This tutorial provides steps for managing users that will need to be completedto work through the tutorial examples.

Adding Users to the Application Server

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

Start the Application Server if you haven’t already done so. Information on starting the Application Server is available inStarting 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 entering the URLhttp://localhost:4848/asadmin. If you changed the default Admin port during installation, enter the correct port number in place of4848.
To log in to the Admin Console, enter the user name and password of a user in theadmin-realm who belongs to theasadmin group. The name and password entered during installation will work, as will any users added to this realm and group subsequent to installation.
Expand the Configuration node in the Admin Console tree.
Expand the Security node in the Admin Console tree.
Expand the Realms node.
- Select thefile realm to add users you want to enable to access applications running in this realm. (For the example security applications, select thefile realm.)
- Select theadmin-realm to add users you want to enable as system administrators of the Application Server.
- You cannot enter users into thecertificate realm using the Admin Console. You can only add certificates to thecertificate realm. For information on adding (importing) certificates to thecertificate realm, readAdding Users to the Certificate Realm.
Click the Manage Users button.
Click New to add a new user to the realm.
Enter the correct information into the User ID, Password, and Group(s) fields.
- If you are adding a user to thefile 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, readWorking with Realms, Users, Groups, and Roles.
  For the example security applications, enter a user with any name and password you like, but make sure that the user is assigned to the group ofuser.
- If you are adding a user to theadmin-realm, enter the name to identify the user, a password to allow the user access to the Application Server, and enterasadmin in the Group field.
Click OK to add this user to the list of users in the realm.
Click Logout when you have completed this task.

Adding Users to the Certificate Realm

In thecertificate realm, user identity is set up in the ApplicationServer security context and populated with user data obtained from cryptographically-verified client certificates. Forstep-by-step instructions for creating this type of certificate, seeWorking with Digital Certificates.

Setting Up Security Roles

When you design an enterprise bean or web component, you should always thinkabout the kinds of users who will access the component. For example, aweb application for a human resources department might have a different request URLfor someone who has been assigned the role ofDEPT_ADMIN than for someonewho has been assigned the role ofDIRECTOR. TheDEPT_ADMIN role may letyou view employee data, but theDIRECTOR role enables you to modify employeedata, including salary data. Each of these security roles is an abstract logical groupingof users that is defined by the person who assembles the application. Whenan application is deployed, the deployer will map the roles to security identitiesin the operational environment, as shown inFigure 28-6.

For applications, you define security roles in the Java EE deployment descriptor fileapplication.xml, and the corresponding role mappings in the Application Server deployment descriptor filesun-application.xml. For individually deployed web or EJB modules, you define roles in theJava EE deployment descriptor filesweb.xml orejb-jar.xml and the corresponding rolemappings in the Application Server deployment descriptor filessun-web.xml orsun-ejb-jar.xml.

The following is an example of a security constraint from aweb.xmlapplication deployment descriptor file where the role ofDEPT-ADMIN is authorized formethods that review employee data and the role ofDIRECTOR is authorized formethods that change employee data.

<security-constraint>    <web-resource-collection>        <web-resource-name>view dept data</web-resource-name>        <url-pattern>/hr/employee/*</url-pattern>        <http-method>GET</http-method>        <http-method>POST</http-method>    </web-resource-collection>    <auth-constraint>        <role-name>DEPT_ADMIN</role-name>    </auth-constraint>    <user-data-constraint>        <transport-guarantee>CONFIDENTIAL</transport-guarantee>    </user-data-constraint></security-constraint><security-constraint>    <web-resource-collection>        <web-resource-name>change dept data</web-resource-name>        <url-pattern>/hr/employee/*</url-pattern>        <http-method>GET</http-method>        <http-method>PUT</http-method>    </web-resource-collection>    <auth-constraint>        <role-name>DIRECTOR</role-name>    </auth-constraint>    <user-data-constraint>        <transport-guarantee>CONFIDENTIAL</transport-guarantee>    </user-data-constraint></security-constraint>

Theweb.xml application deployment descriptor is described in more detail inDeclaring Security Requirements in a Deployment Descriptor.

After users have provided their login information, and the application has declared whatroles are authorized to access protected parts of an application, the next stepis to map the security role to the name of a user,or principal. This step is discussed in the following section.

Mapping Roles to Users and Groups

When you are developing a Java EE application, you don’t need to knowwhat categories of users have been defined for the realm in which theapplication will be run. In the Java EE platform, the security architecture providesa mechanism for mapping the roles defined in the application to the usersor groups defined in the runtime realm. To map a role namepermitted by the application or module to principals (users) and groups defined onthe server, use thesecurity-role-mapping element in the runtime deployment descriptor (sun-application.xml,sun-web.xml, orsun-ejb-jar.xml) file. The entry needs to declare a mapping between a security roleused in the application and one or more groups or principals defined forthe applicable realm of the Application Server. An example for thesun-web.xml fileis shown below:

<sun-web-app>    <security-role-mapping>        <role-name>DIRECTOR</role-name>        <principal-name>mcneely</principal-name>    </security-role-mapping>    <security-role-mapping>        <role-name>MANAGER</role-name>        <group-name>manager</group-name>    </security-role-mapping></sun-web-app>

The role name can be mapped to either a specific principal (user),a group, or both. The principal or group names referenced must be validprincipals or groups in the current default realm of the Application Server. Therole-name in this example must exactly match therole-name in thesecurity-role elementof the correspondingweb.xml file or the role name defined in the@DeclareRoles or@RolesAllowed annotations.

Sometimes the role names used in the application are the same asthe group names defined on the Application Server. Under these circumstances, you can enablea default principal-to-role mapping on the Application Server using the Admin Console. Fromthe Admin Console, select Configuration, then Security, then check the enable box besideDefault Principal to Role Mapping. If you need more information about using theAdmin Console, seeAdding Users to the Application Server.