Working With Realms Users Groups and Roles

Start course
2h 6m

This course takes an in-depth look at security in Java Enterprise Edition. We'll cover a wide range of topics as listed below. Finally, we'll round off the course by taking a look at some example exam questions similar to those you can expect to find on the Oracle Certified Java EE exams.

Learning Objectives

  • Understand the fundamentals of security in Java EE
  • Learn the following concepts and features:
    • Securing GlassFish server
    • Working with users, groups, and roles
    • SSL
    • Securing your web applications
    • Securing enterprise beans
    • Digital certificates
    • Security architecture
    • Security threats
    • And much more...

Intended Audience

This course is intended for anyone who already has basic knowledge of Java and now wants to learn about Java Enterprise Edition.


Basic knowledge of Java programming


Now let's dive deep into realms, users, groups, and roles concept. In an application, you need to protect resources to ensure that only authorized users have access. In this lesson, we will learn setting up users so that they can be correctly identified and either given access to protected resources or denied access if they are not authorized to access the protected resources. For example, a clerk, a manager and a director must have different authority in an enterprise application, and you need to specify it correctly. To authenticate a user, you need to follow these basic steps. The application developer writes code to prompt for a username and password. 

Of course, there are other authentication types like digest authentication, client authentication and mutual authentication. The application developer communicates how to set up security for the deployed application by use of a metadata annotation or deployment descriptor. The server administrator sets up authorized users and groups on the GlassFish server. The application deployer maps the application security roles to users, groups, and principals defined on the GlassFish server. So, what are realms, users, groups, and roles? A realm is a security policy domain defined for a web or application server. A realm contains a collection of users who may or may not be assigned to a group. Generally, you need to supply a username and password to get access for an application. 

After you have entered the username and password, that information is passed to the server, which either authenticates you and sends the protected resource or does not authenticate you, in which case access to the protected resource is denied. In some applications, authorized users are assigned to roles. In this situation, the role assigned to the user in the application must be mapped to a principal or group defined on the application server. You can create users and groups in application server. A user can be a member of a group, and you can define roles in an application. At the end, you need to map roles to users or groups. What is a realm?

The protected resources on a server can be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database containing a collection of users and groups. A realm is a complete database of users and groups identified as valid users of one or more applications and controlled by the same authentication policy. The Java EE server authentication service can govern users into multiple realms. The file, admin realm, and certificate realms come pre-configured for the GlassFish Server.

In the file realm, the server stores user credentials locally in a file named key file. You can use Administration 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 HTTPS and certificates. In the certificate realm, the server stores user credentials in a certificate database. When using the certificate realm, the server uses certificates with HTTP to authenticate web clients. To verify the identity of a user in the certificate realm, the authentication service verifies an X.509 certificate. The Common Name Field of the Certificate is used as the principal name. The admin realm is also a file realm and stores administrator user credentials locally in a file named admin-key file. You can use the administration console to manage users in this realm in the same way you manage users in the file realm.

What is a user? A user is an individual or application program identity that has been defined in the GlassFish server. In a web application, a user can have associated with that identity, a set of roles that entitled the user to access all resources protected by those roles. Users can be associated with a group. What is a group? A group is a set of authenticated users classified by common traits defined in the GlassFish server. A Java EE user of the file realm can belong to a group on the GlassFish server. A group on the GlassFish server 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 exclusive group. Categorizing users into groups make it easier to control the access of large numbers of users. A group on the GlassFish server has a different scope from a role. A group is designated for the entire GlassFish server, whereas a role is associated only with a specific application in the GlassFish server.

What is a role? A role is 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. There are some other definitions that are also used to describe the security requirements of the Java EE platform. Principal, an entity that can be authenticated by an authentication protocol in a security service that is deployed in an enterprise. A principal is identified by using a principal name and authenticated by using authentication data. Security policy domain, also known as security domain or realm. 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 attributes 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 the principal by an authentication protocol. Credential, an object that contains or references security attributes used to authenticate a principal for Java EE 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 GlassFish server. Let's talk about users and groups on the GlassFish server. First, we need to start GlassFish server. We can start it via Eclipse IDE. I am opening Eclipse IDE. Here, I open Project View and go to Servers tab. Here, I select GlassFish and press 'Start' button. The server opened. Now I open a web browser and type, local host:4848. A bit later, an administration page is opened. There's a menu in the left side, expand Configuration, server config, Security, Realms. As you see, there are admin realm, certificate, and file realms. We can add users and groups to admin realm and file realm here, but we can't add users to certificate. We use Java key tool to add users to certificate realm. 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 manager than for someone who has been assigned the role of director. The manager role may let you view employee data, but the director role enables you to modify employee data, including salary data. Each of these security roles is an abstract logical grouping of users that is defined by the person who assembles the application. For Java EE components, you define security roles using the declare roles and roles allowed metadata annotations. The following is an example of an application in which the role of manager is authorized for methods that review employee payroll data and the role of director is authorized for methods that can change employee payroll data. The enterprise bean would be annotated as shown in the example code.

Here, we declare total roles that we need using DeclareRoles annotation, and then we use RolesAllowed annotation before the methods that we want to assign. As you see, manager role is allowed to review employee info and director role is allowed to update employee info. When using Servlet, you can define roles using HttpConstraint annotation within the ServletSecurity annotation like this. After users have provided their login information and the application has declared what roles are authorized to access protected parts of an application, the next step is to map the security role to the name of a user or principal. Mapping roles to users and groups. When you're developing a Java EE 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 Java EE platform, the security architecture provides a mechanism for mapping the roles defined in the application to the users or groups defined in the runtime realm.

The role names used in the application are often the same as the group names defined on the GlassFish server. Under these circumstances, you can enable a default principal to role mapping on the GlassFish server by using the administration console. To do this, make sure GlassFish server's started and running, connect to Administration console, expand Configurations node, expand server-config. Here, select Security. There is a checkbox near the title "default principal to role mapping enabled". You can enable it by ticking the checkbox. If the role names used in an application are not the same as the group names defined on the server, use the runtime deployment descriptor to specify the mapping.

The following example demonstrates how to do this mapping in the glassfish-web.xml file, which is the file used for web applications. A role can be mapped to specific principals, specific groups, or both. The principal or group names must be valid principals or groups in the current default realm or in the realm specified in the login config element. In this example, the role of manager used in the application is mapped to a principal named Duke that exists on the application server. Mapping a role to a specific principal is useful when the person occupying that role may change. 

For this application, you would need to modify only the runtime deployment descriptor rather than search and replace throughout the application for references to this principal. Also in this example, the role of admin is mapped to a group of users assigned the group name of director. This is useful because the group of people authorized to access director level administrative data has to be maintained only on the GlassFish Server. The application developer does not need to know who these people are, but only needs to define the group of people who will be given access to the information. The role name must match the role name in the security role element of the corresponding deployment descriptor or the role name defined in a DeclareRoles annotation.


About the Author
Learning Paths

OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.

Covered Topics