Security in Java EE 6
The course is part of this learning path
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.
- Understand the fundamentals of security in Java EE
- Learn the following concepts and features:
- Securing GlassFish server
- Working with users, groups, and roles
- Securing your web applications
- Securing enterprise beans
- Digital certificates
- Security architecture
- Security threats
- And much more...
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
Hello there, in this section, we'll talk about security in Java EE. So, let's start. Every enterprise that has either sensitive resources that can be accessed by many users or resources that traverse unprotected open networks, such as the Internet, needs to be protected. Enterprise tier and Web tier applications are made up of components that are deployed into various containers. These components are combined to build a multitier enterprise application. Security for components is provided by their containers. A container provides two kinds of security, declarative and programmatic. Declarative security expresses an application components security requirements by using either deployment descriptors or annotations. A deployment descriptor is an XML file that is external to the application, and that expresses an application security structure, including security roles, access control, and authentication requirements. Annotations also called Metadata are used to specify information about security within a class file.
When the application is deployed, this information can either be used by or overridden by the application deployment descriptor. Annotation save you from having to write declarative information inside XML descriptors. Instead, you simply put annotations on the code and the required information gets generated. Programmatic security is embedded in an application, and is used to make security decisions. Programmatic security is useful when declarative security alone is not sufficient to express the security model of an application. Let's take a look at a simple application security walkthrough. The security behavior of a Java EE environment may be better understood by examining what happens in a simple application with a Web client, a User Interface, and an Enterprise Bean Business Logic. The following example taken from the Java EE 7 specification, illustrates how a Web Client relies on a Web Server to serve as its authentication proxy by gathering user authentication information from the client and using it to create an authenticated session. Step 1, Initial Request.
In the first step of this example, the Web Client requests the main application URL. Since the client has not yet authenticated itself to the application environment, the server responsible for delivering the Web portion of the application, hereafter referred to as the Web Server, detects this and invokes the appropriate authentication mechanism for this resource. Step 2, Initial Authentication. The Web Server returns a form that the Web Client uses to collect authentication data, such as username and password from the user. The Web Client forwards the authentication data to the Web Server where it's validated by the Web Server as shown in this figure. The validation mechanism may be local to a server or may leverage the underlying security services. On the basis of validation, the Web Server sets a credential for the user. Step 3, URL Authentication. The credential is used for future determinations of whether the user is authorized to access restricted resources it may request.
The Web Server consults the security policy associated with the Web resource to determine the security roles that are permitted access to the resource. The security policy is derived from annotations or from the deployment descriptor. The Web Container then tests the user's credential against each role to determine whether it can map the user to this role. The figure shows this process. The Web Servers evaluation stops within is authorized outcome when web server is able to map the user to a role. A not authorized outcome is reached if the web server is unable to map the user to any of the permitted roles. Step 4, URL Authentication. If the user is authorized, a Web page is returned, enabling the user to post form data that needs to be handled by the Business Logic Component of the application. Step 5, Invoking Enterprise Bean Business Methods.
The Web page performs the remote method call to the Enterprise Bean using the user's credential to establish a secure association between the Web page and the Enterprise Bean as shown in this figure. The association is implemented as two related security contexts, one in the Web Server and one in the EJB Container. The EJB Container is responsible for enforcing access control on the Enterprise Bean method. The container consults the security policy associated with the Enterprise Bean to determine the security roles that are permitted access to the method. The security policy is derived from annotations or from the deployment descriptor. For each role, the EJB container determines whether it can map the caller to the role by using the security context associated with the call. The container's evaluation stops within is authorized outcome when the container is able to map the caller's credential to a role. The not authorized outcome is reached if the container is unable to map the caller to any of the permitted roles.
A not authorized result causes an exception to be thrown by the container, and propagated back to the calling Web page. If the call is authorized, the container dispatches control to the Enterprise Bean method. The result of the Bean's execution of the call is returned to the Web page, and ultimately to the user by the Web Server and the Web Client. Let's talk a little bit about the features of the security mechanism. A properly implemented security mechanism will provide the following functionality: prevent unauthorized access to application functions and business or personal data, hold system users accountable for operations they perform, protect a system from service interruptions and other breaches that affect quality of service. Ideally, properly implemented security mechanisms will also be: easy to administer, transparent to system users, interoperable across application and enterprise boundaries. Java EE applications consist of components that can contain both protected and unprotected resources.
Often, you need to protect resources to ensure that only authorized users have access. Authorization provides controlled access to protected resources. Authorization is based on identification and authentication. Identification is a process that enables recognition of an entity by a system. And authentication is a process that verifies the identity of a user device or other entity in a computer system, usually as a prerequisite to allowing access to a resource in the system. Authorization and authentication are not required for an entity to access unprotected resources. Accessing a resource without authentication is referred to as unauthenticated or anonymous access. The characteristics of application security that when properly addressed, help to minimize the security threats faced by an enterprise include these. Authentication: the means by which communicating entities, such as client and server, prove to each other that they are acting on behalf of specific identities that are authorized for access.
This ensures that users are who they say they are. Authorization or access control: The means by which interactions with resources are limited to collections of users or programs for the purpose of enforcing integrity, confidentiality, or availability constraints. This ensures that users have permission to perform operations or access data. Data integrity: the means used to prove that information has not been modified by a third party, an entity other than the source of the information. For example, a recipient of data sent over an open network must be able to detect and discard messages that were modified after they were sent. This ensures that only authorized users can modify data. Confidentiality or data privacy: The means used to ensure that information is made available only to users who are authorized to access it. This ensures that only authorized users can view sensitive data.
Non-repudiation: the means used to prove that a user who performed some action cannot reasonably deny having done so. This ensures that transactions can be proved to have happened. Quality of Service: the means used to provide better service to selected network traffic over various technologies. Auditing: the means to capture a tamper resistant record of security related events for the purpose of being able to evaluate the effectiveness of security policies and mechanisms. To enable this, the system maintains a record of transactions and security information. So, that's it, hope to see you in our next lesson. Have a nice day.
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.