Java Servlet Specification
|
   
|
| C H A P T E R 12 |
|
Security |
Web applications are created by application developers who give, sell, or otherwise transfer the application to a deployer for installation into a runtime environment. Application developers need to communicate to deployers how the security is to be set up for the deployed application. This is accomplished declaratively by use of the deployment descriptors mechanism.
This chapter describes deployment representations for security requirements. The requirements for runtime representations are not specified, just as the requirements for web application directory layouts and deployment descriptors are not specified. It is recommended, however, that containers implement the elements set out here as part of their runtime representations.
This Java Card Platform version of the specification imposes that web resources to which a security constraint applies be only designated with URL patterns to which servlets have been mapped. Therefore, security constraints cannot directly apply to static content. Security constraints can only apply indirectly to static content through a servlet such as an explicitly declared “default” servlet that is used to serve static content in response to requests from web clients when no other servlet applies. This indirect mapping is assumed for any mention in this chapter of security constraints applying to static content.
A web application contains resources that can be accessed by many users. These resources often traverse unprotected, open networks such as the Internet. In such an environment, a substantial number of web applications will have security requirements.
Although the quality assurances and implementation details may vary, servlet containers have mechanisms and infrastructure for meeting these requirements that share some of the following characteristics:
Declarative security refers to the means of expressing an application’s security structure, including roles, access control, and authentication requirements in a form external to the application. The deployment descriptor is the primary vehicle for declarative security in web applications.
The deployer maps the application’s logical security requirements to a representation of the security policy that is specific to the runtime environment. At runtime, the servlet container uses the security policy representation to enforce authentication and authorization.
The security model applies to the static content part of the web application and to servlets and filters within the application that are requested by the client. The security model does not apply when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include.
Programmatic security is used by security aware applications when declarative security alone is not sufficient to express the security model of the application. Programmatic security consists of the following methods of the HttpServletRequest interface:
The getRemoteUser method returns the user name the client used for authentication. The isUserInRole method determines if a remote user is in a specified security role. These APIs allow servlets to make business logic decisions based on the information obtained.
If no user has been authenticated, the getRemoteUser method returns null and the isUserInRole method always returns false.
The isUserInRole method expects a String user role-name parameter. A security-role-ref element should be declared in the deployment descriptor with a role-name sub-element containing the role name to be passed to the method. A security-role element should contain a role-link sub-element whose value is the name of the security role that the user may be mapped into. The container uses the mapping of security-role-ref to security-role when determining the return value of the call.
For example, to map the security role reference “FOO” to the security role with role-name manager, the syntax would be:
In this case, if the servlet called by a user belonging to the manager security role made the API call isUserInRole(“FOO”), the result would be true.
If no security-role-ref element matching a security-role element has been declared, the container must default to checking the role-name element argument against the list of security-role elements for the web application. The isUserInRole method references the list to determine whether the caller is mapped to a security role. The developer must note that the use of this default mechanism may limit the flexibility in changing role names in the application without having to recompile the servlet making the call.
A security role is a logical grouping of users defined by the application developer or assembler. When the application is deployed, roles are mapped by a deployer to principals in the runtime environment.
A servlet container enforces declarative or programmatic security for the principal associated with an incoming request based on the security attributes of the principal.
Refer to the Runtime Environment Specification, Java Card Platform, Version 3.0.1, Connected Edition for the actual declarative and programmatic security enforcement rules on the Java Card Platform.
A web client can authenticate a user to a web server using one of the following mechanisms:
The Runtime Environment Specification, Java Card Platform, Version 3.0.1, Connected Edition introduces an additional authentication mechanism, which is required on the Java Card Platform. Refer to the Runtime Environment Specification, Java Card Platform, Version 3.0.1, Connected Edition for details on this additional authentication mechanism specific to the Java Card Platform.
HTTP Basic Authentication, which is based on a user name and password, is the authentication mechanism defined in the HTTP/1.0 specification. A web server requests a web client to authenticate the user. As part of the request, the web server passes the realm (a string) in which the user is to be authenticated. The realm string of Basic Authentication does not have to reflect any particular security policy domain (confusingly also referred to as a realm). The web client obtains the user name and the password from the user and transmits them to the web server. The web server then authenticates the user in the specified realm.
Basic Authentication is not a secure authentication protocol. User passwords are sent in simple base64 encoding, and the target server is not authenticated. Additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS) or security at the network level (such as the IPSEC protocol or VPN strategies) is applied in some deployment scenarios.
Like HTTP Basic Authentication, HTTP Digest Authentication authenticates a user based on a user name and a password. However, with Digest Authentication the authentication is performed by transmitting the password in an encrypted form, which is much more secure than the simple base64 encoding used by Basic Authentication.
The look and feel of the “login screen” cannot be varied using the web browser’s built-in authentication mechanisms. This specification introduces a required form-based authentication mechanism that allows a developer to control the look and feel of the login screens.
The web application deployment descriptor contains entries for a login form and error page. The login form must contain fields for entering a user name and a password. These fields must be named j_username and j_password, respectively.
When a user attempts to access a protected web resource, the container checks the user’s authentication. If the user is authenticated and possesses authority to access the resource, the requested web resource is activated and a reference to it is returned. If the user is not authenticated, all of the following steps occur:
1. The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container.
2. The user is asked to fill out the form, including the user name and password fields.
3. The client posts the form back to the server.
4. The container attempts to authenticate the user using the information from the form.
5. If authentication fails, the error page is returned using either a forward or a redirect, and the status code of the response is set to 200.
6. If authentication succeeds, the authenticated user’s principal is checked to see if it is in an authorized role for accessing the resource.
7. If the user is authorized, the client is redirected to the resource using the stored URL path.
The error page sent to a user that is not authenticated contains information about the failure.
Form-Based Authentication has the same lack of security as Basic Authentication since the user password is transmitted as plain text and the target server is not authenticated. Again additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS) or security at the network level (such as the IPSEC protocol or VPN strategies) is applied in some deployment scenarios.
Form-based login and URL-based session tracking can be problematic to implement. Form-based login should be used only when sessions are being maintained by cookies or by SSL session information.
For the authentication to proceed appropriately, the action of the login form must always be j_security_check. This restriction is made so that the login form will work no matter which resource it is for, and to avoid requiring the server to specify the action field of the outbound form.
The following example shows how the form should be coded into the HTML page:
<form method=”POST” action=”j_security_check”> <input type=”text” name=”j_username”> <input type=”password” name=”j_password”> </form> |
If the form-based login is invoked because of an HTTP request, the original request parameters must be preserved by the container for use if, on successful authentication, it redirects the call to the requested resource.
If the user is authenticated using form login and has created an HTTP session, the timeout or invalidation of that session leads to the user being logged out in the sense that subsequent requests must cause the user to be re-authenticated. The scope of the logout is the same as that of the authentication. For example, if the container supports single sign-on, the user would need to reauthenticate with any of the web applications hosted on the web container.
As the underlying security identities (such as users) to which roles are mapped in a runtime environment are environment specific rather than application specific, it is desirable to:
1. Make login mechanisms and policies a property of the environment the web application is deployed in.
2. Be able to use the same authentication information to represent a principal to all applications deployed in the same container, and
3. Require re-authentication of users only when a security policy domain boundary has been crossed.
Therefore, a servlet container is required to track authentication information at the container level (rather than at the web application level). This allows users authenticated for one web application to access other resources managed by the container permitted to the same security identity.
Security constraints are a declarative way of defining the protection of web content. A security constraint associates authorization and user data constraints, together or separately, with HTTP operations on web resources. A security constraint, which is represented by security-constraint in deployment descriptor, consists of the following elements:
The HTTP operations and web resources to which a security constraint applies (meaning the constrained requests) are identified by one or more web resource collections. A web resource collection consists of the following elements:
An authorization constraint establishes a requirement for authentication and names the authorization roles permitted to perform the constrained requests. A user must be a member of at least one of the named roles to be permitted to perform the constrained requests. The special role name “*” is a shorthand for all role names defined in the deployment descriptor. An authorization constraint that names no roles indicates that access to the constrained requests must not be permitted under any circumstances. An authorization constraint consists of the following element:
A user data constraint establishes a requirement that the constrained requests be received over a protected transport layer connection. The strength of the required protection is defined by the value of the transport guarantee. A transport guarantee of INTEGRAL is used to establish a requirement for content integrity and a transport guarantee of CONFIDENTIAL is used to establish a requirement for confidentiality. The transport guarantee of NONE indicates that the container must accept the constrained requests when received on any connection including an unprotected one.
A user data constraint consists of the following element:
If no authorization constraint applies to a request, the container must accept the request without requiring user authentication. If no user data constraint applies to a request, the container must accept the request when received over any connection including an unprotected one.
CODE EXAMPLE 12-1 illustrates the declaration of constraints and their translation into a table of applicable constraints. Suppose that a deployment descriptor contained the following security constraints.
The translation of this hypothetical deployment descriptor would yield the constraints defined in TABLE 12-1.
When a servlet container receives a request, it shall use the algorithm described in Section 11.1, Use of URL Paths to select the constraints (if any) defined on the url-pattern that is the best match to the request URI. If no constraints are selected, the container shall accept the request. Otherwise, the container shall determine if the HTTP method of the request is constrained at the selected pattern. If it is not, the request shall be accepted. Otherwise, the request must satisfy the constraints that apply to the http-method at the url-pattern. Both of the following rules must be satisfied for the request to be accepted and dispatched to the associated servlet:
By default, authentication is not needed to access resources. Authentication is needed for requests for a web resource collection only when specified by the deployment descriptor.
Being logged in to a web application corresponds precisely to there being a valid non-null value in getRemoteUser method, as described in Section 12.3, Programmatic Security and in the Javadoc tool files. A null value in that method indicates that a user is logged out.
Containers may create HTTP session objects to track login state. If a developer creates a session while a user is not authenticated, and the container then authenticates the user, the session visible to developer code after login must be the same session object that was created prior to login occurring so that there is no loss of session information.
| Java Servlet Specification
|
5-30-09 |
|
Copyright © 2009 Sun Microsystems, Inc. All rights reserved.
