Movatterモバイル変換

Overview of Java EE Security

Java EE, web, and web services applications are made up of components thatcan be deployed into different containers. These components are used to build amultitier enterprise application. Security for components is provided by their containers. A containerprovides two kinds of security: declarative and programmatic security.

Declarative security expresses an application component’s security requirements usingdeployment descriptors. Deployment descriptors are external to an application, and include information that specifies how security roles and access requirements are mapped into environment-specific security roles, users, and policies. For more information about deployment descriptors, readUsing Deployment Descriptors for Declarative Security.
Annotations (also calledmetadata) 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. Annotations save your from having to write declarative information inside XML descriptors. Instead, you just put annotations on the code and the required information gets generated. For more information about annotations, readUsing Annotations.
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. For more information about programmatic security, readUsing Programmatic Security.

A Simple Security Example

The security behavior of a Java EE environment may be better understood byexamining what happens in a simple application with a web client, aJSP user interface, and enterprise bean business logic.

In the following example, which is taken from JSR-244, theJava EE 5 Specification, theweb client relies on the web server to act as its authentication proxyby collecting user authentication data from the client and using it to establishan authenticated session.

Step 1: Initial Request

In the first step of this example, the web client requests themain application URL. This action is shown inFigure 28-1.

Figure 28-1 Initial Request

Diagram of initial request from web client to web server for access to a protected resource

Since the client has not yet authenticated itself to the application environment, theserver responsible for delivering the web portion of the application (hereafter referred toasweb server) detects this and invokes the appropriate authentication mechanism for this resource. Formore information on these mechanisms, readSecurity Implementation Mechanisms.

Step 2: Initial Authentication

The web server returns a form that the web client uses tocollect authentication data (for example, user name and password) from the user. Theweb client forwards the authentication data to the web server, where it isvalidated by the web server, as shown inFigure 28-2.

Figure 28-2 Initial Authentication

Diagram of initial authentication: server sends form to client, which sends authentication data to server for validation

The validation mechanism may be local to a server, or it mayleverage the underlying security services. On the basis of the validation, the web serversets a credential for the user.

Step 3: URL Authorization

The credential is used for future determinations of whether the user is authorizedto access restricted resources it may request. The web server consults the securitypolicy (derived from the deployment descriptor) associated with the web resource to determinethe security roles that are permitted access to the resource. The web containerthen tests the user’s credential against each role to determine if it canmap the user to the role.Figure 28-3 shows this process.

Figure 28-3 URL Authorization

The web server’s evaluation stops with an “is authorized” outcome when the webserver is able to map the user to a role. A “not authorized”outcome is reached if the web server is unable to map the userto any of the permitted roles.

Step 4: Fulfilling the Original Request

If the user is authorized, the web server returns the result ofthe original URL request, as shown inFigure 28-4.

Figure 28-4 Fulfilling the Original Request

Diagram of request fulfillment, showing server returning result to client

In our example, the response URL of a JSP page is returned,enabling the user to post form data that needs to be handled bythe business logic component of the application. ReadChapter 30, Securing Web Applications for more information onprotecting web applications.

Step 5: Invoking Enterprise Bean Business Methods

The JSP page performs the remote method call to the enterprise bean, usingthe user’s credential to establish a secure association between the JSP page andthe enterprise bean (as shown inFigure 28-5). The association is implemented astwo related security contexts, one in the web server and one in theEJB container.

Figure 28-5 Invoking an Enterprise Bean Business Method

Diagram of authorization process between JSP/servlet object and enterprise bean

The EJB container is responsible for enforcing access control on the enterprise beanmethod. It consults the security policy (derived from the deployment descriptor) associated withthe enterprise bean to determine the security roles that are permitted access tothe method. For each role, the EJB container uses the security context associatedwith the call to determine if it can map the caller to therole.

The container’s evaluation stops with an “is authorized” outcome when the container isable to map the caller’s credential to a role. A “not authorized” outcomeis reached if the container is unable to map the caller to anyof the permitted roles. A “not authorized” result causes an exception to bethrown by the container, and propagated back to the calling JSP page.

If the call is authorized, the container dispatches control to the enterprise beanmethod. The result of the bean’s execution of the call is returned tothe JSP, and ultimately to the user by the web server andthe web client.

ReadChapter 29, Securing Java EE Applications for more information on protecting web applications.

Security Functions

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 (non-repudiation)
Protect a system from service interruptions and other breaches that affect quality of service

Ideally, properly implemented security mechanisms will also provide the following functionality:

Easy to administer
Transparent to system users
Interoperable across application and enterprise boundaries

Characteristics of Application Security

Java EE applications consist of components that can contain both protected and unprotectedresources. Often, you need to protect resources to ensure that only authorized usershave access.Authorization provides controlled access to protected resources. Authorization is based onidentification and authentication.Identification is a process that enables recognition of an entity bya system, andauthentication is a process that verifies the identity of auser, device, or other entity in a computer system, usually as a prerequisiteto allowing access to resources in a 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.

These and several other well-defined characteristics of application security that, when properly addressed,help to minimize the security threats faced by an enterprise, include the following:

Authentication: The means by which communicating entities (for example, client and server) prove to one another 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, orAccess 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 (some 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 orData 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 performed some action such that the user cannot reasonably deny having done so. This ensures that transactions can be proven to have happened.
Quality of Service (QoS): The means used to provide better service to selected network traffic over various technologies.
Auditing: The means used 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.