Securing Enterprise Beans

Start course
Overview
Difficulty
Intermediate
Duration
2h 6m
Students
5
Description

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.

Prerequisites

Basic knowledge of Java programming

Transcript

Securing enterprise beans. Enterprise beans are Java EE components that implement EJB technology. Enterprise beans run in the EJB container, a runtime environment within the Glassfish Server. There is a demonstration here showing server and client interaction. Here, Java EE Server is a Glass Fish Server. Enterprise bean included in EJB container. Although transparent to the application developer, the EJB container provides system level services such as transactions and security to its enterprise beans, which form the core of transactional Java EE applications. Enterprise bean methods can be secured in either of the following ways: Declarative security, programmatic security. Declarative security, expresses an application components security requirements using either deployment descriptors or annotations.

The presence of an annotation in the business method of an enterprise bean class that specifies method permissions is all that is needed for method protection and authentication in some situations. Because of some limitations to the simplified method of securing enterprise beans, you would want to continue to use the deployment descriptor to specify security information in some instances. An authentication mechanism must be configured on the server for the simple solution to work. Basic authentication is the Glass Fish Server's default authentication method. To make the deployer's task easier, the application developer can define security roles. We have already talked about it earlier. A security role is a grouping of permissions that a given type of application users must have in order to successfully use the application. For example, in a payroll application, some users will want to view their own payroll information like employees. Some will need to view others payroll information like managers, and some will need to be able to change others payroll information like directors.

The application developer would determine the potential users of the application and which methods would be accessible to which users. The application developer would then decorate classes or methods of the enterprise bean with annotations that specify the types of users authorized to access those methods. Declarative security enables the application developer to specify which users are authorized to access which methods of the enterprise beans, and to authenticate these users with basic or username password authentication. Frequently, the person who is developing an enterprise application is not the same person who is responsible for deploying the application. An application developer who uses declarative security to define method permissions and authentication mechanisms is passing along to the developer a security view of the enterprise beans contained in the EJB jar. When a security view is passed on to the developer, he or she uses this information to define method permissions for security roles. If you don't define security view, the deployer will have to determine what each business method does to determine which users are authorized to call each method.

Method permissions can be specified on the class, the business methods of the class, or both. Method permissions can be specified on method of the bean class to override the method permissions value specified on the entire bean class. The following annotations are used to specify method permissions: DeclareRoles, RolesAllowed, PermitAll, DenyAll. DeclareRoles specifies all the roles that the application will use, including roles not specifically named in a roles allowed annotation. The set of security roles the application uses is the total of the security roles defined in the DeclareRoles and RolesAllowed annotations. 

This example demonstrates the use of DeclareRoles annotation. You can define more than one role in a statement like this. RolesAllowed specifies the security roles permitted to access methods in an application. This annotation can be specified on a class or on one or more methods. When specified at the class level, the annotation applies to all methods in the class. When specified on  a method, the annotation applies to that method only and overrides any value specified at the class level. When used in conjunction with the @DeclareRoles annotation, the combined set of security roles is used by the application. This example code demonstrates the use of the roles allowed annotation. Here, users having administrator role are allowed to use that method of the class.

PermitAll; specifies that all security roles are permitted to execute the specified method or methods. The users is not checked against the database to ensure that he or she is authorized to access this application. This annotation can be specified on a class or on one or more methods. Specifying this annotation on the class means that it applies to all methods of the class. Specifying it at the method level means that it applies to only that method. This example demonstrates the  use of the PermitAll annotation. o of the PermitAll annotation. Here all users or roles are allowed to use that method. DenyAll; specifies that no security roles are permitted to execute the specified method or methods. This means that these methods are excluded from execution in the Java EE container. This example demonstrates the use of DenyAll annotation. For this example, no one can reach the related method. The last thing I want to say about declarative security with annotations is the case of inheritance.

Let's look at that example. There is a super class and an inherited class from it. When you create an object of MyBean class, first method of that object is allowed to manage a role, the second method of that object is allowed to admin role, and there is no role specification for third method. I need to say that class annotations aren't inherited. Only if you don't override a method, the annotation remains valid for that method. As for second method, if there were forth method in super class and we override it in the subclass without any annotation, the derived method of the subclass would have no role. Programmatic security. For an enterprise bean, code embedded in a business method that is used to access  a caller's identity programmatically and that uses this information to make security decisions. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application. Programmatic security is generally used to make decisions actively at program execution.

The Javax.ejb.ejb context interface provides two methods that allow the bean provider to access security information about the enterprise beans caller. getCallerPrinciple, is CallerInRole. getCallerPrinciple, which allows the enterprise bean methods to obtain the current caller principal's name. The methods might for example, use the name as a key to information in database. This example shows the usage of the getCallerPrinciple method. In this example, the enterprise bean obtains the principal name of the current caller and uses it as the primary key to locate an employee record entity. We use session context to getCallerPrincipal. This example assumes that the application has been deployed such that the current callerprincipal contains the primary key used for the identification of employees and has used that value to find employee record. isCallerInRole, which the enterprise bean code can use to allow the bean provider or application developer to code the security checks that cannot be easily defined using method permissions.

Such a check might impose a role-based limit on a request or it might depend on information stored in the database. The enterprise bean code can use the isCallerInRole method to test whether the current caller has been assigned to a given security role. Security roles are defined by the bean provider or the application assembler and are assigned by the deployer to principal's or principal groups that exist in the operational environment. This code sample illustrates the use of the IsCallerInRole method. In this example, if current user doesn't have the role manager, it will be thrown an exception. Propagating a security identity. You can specify whether a caller security identity should be used for the execution of specified methods of an enterprise bean, or whether a specific run as identity should be used. In this schema, an application client is making a call to an enterprise bean method in one EJB container.

This enterprise bean method in turn makes a call to an enterprise bean method in another container. The security identity during the first call is the identity of the caller. The security identity during the second call can be any of those options. By default, the identity of the caller of the intermediate component is propagated to the target enterprise bean. This technique is used when the target container trusts the intermediate container. A specific identity is propagated to the target enterprise bean. This technique is used when the target container expects access using a specific identity. To propagate an identity to the target enterprise bean, can figure a runas identity for the bean. Establishing a runas identity for an enterprise bean does not affect the identities of its callers, which are the identities tested for permission to access the methods of the enterprise bean.

The runas identity establishes the identity that the enterprise bean will use when it makes calls. The runas identity applies to the enterprise bean as a whole, including all the methods of the enterprise beans business interface, local and remote interfaces, component interface, and web service endpoint interfaces. The message listener methods of a message driven bean, the time out method of an enterprise bean, and all internal methods of the bean that might be called in turn. You can configure an enterprise beans runas or a propagated security identity by using the runas annotation, which defines the role of the application during execution in a Java EE container. The annotation can be specified on a class, allowing developers to execute an application under a particular role. The role must map to the user or group information in the container security realm. The run as annotation specifies the name of a security role as its parameter. There is a sample code for usage of runas annotation.

You will have to map the runas role name to a given principal defined on the Glass Fish Server, if the given roles are associated with more than one user principal. We have already seen how to map roles and principals in Glass Fish Server. Deploying secure enterprise beans. The deployer is responsible for ensuring that an assembled application is secure after it has been deployed in the target operational environment. If security view has been provided to the developer through the use of security annotations and/or  a deployment descriptor, the security view is mapped to the mechanisms and policies used by the security domain in the target operational environment, which in this case is the Glass Fish Server. If no security view is provided, the developer must set up the appropriate security policy for the enterprise bean application. Deployment information is specific to a web or application server.

 

About the Author
Students
433
Courses
47
Learning Paths
2

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