Download FAQ History |  | API Search Feedback

> ## Specifying Security Constraints

> You can protect Web resources by specifying a security constraint. A security constraint determines who is authorized to access a Web resource collection, a list of URL patterns and HTTP methods that describe a set of resources to be protected. Security constraints can be defined in a deployment descriptor, as discussed in Specifying Security Constraints.

> If you try to access a protected Web resource as an unauthenticated user, the Web container will try to authenticate you. The container will only accept the request after you have proven your identity to the container and have been granted permission to access the resource.

> Security constraints only work on the original request URI, not on calls made via a `RequestDispatcher` (which include `<jsp:include>` and `<jsp:forward>`). Inside the application, it is assumed that the application itself has complete access to all resources and would not forward a user request unless it had decided that the requesting user had access also.

> Many applications feature unprotected Web content, which any caller can access without authentication. In the Web tier, unrestricted access is provided simply by not configuring a security constraint for that particular request URI. It is common to have some unprotected resources and some protected resources. In this case, you will have security constraints and a login method defined, but it will not be used to control access to the unprotected resources. The user won't be asked to log on until the first time they enter a protected request URI.

> In the Java Servlet specification, the request URI is the part of a URL after the host name and port. For example, let's say you have an e-commerce site with a browsable catalog you would want anyone to be able to access and a shopping cart area for customers only. You could set up the paths for your Web application so that the pattern `/cart/*` is protected, but nothing else is protected. Assuming the application is installed at context path `/myapp`,

> - `http://localhost:8080/myapp/index.jsp` is not protected
> - `http://localhost:8080/myapp/cart/index.jsp` is protected

> A user will not be prompted to log in until the first time that user accesses a resource in the `cart` subdirectory.

> The following items are defined within `<security-constraint>` tags in an application deployment descriptor:

> - Security constraint--used to define the access privileges to a collection of resources using their URL mapping.
> - Web resource collection--a list of URL patterns and HTTP methods that describe a set of resources to be protected.
> - Authorized security role--the role that is authorized to access the parts of the application set up within this security constraint. Security roles are discussed in Setting up Security Roles.
> - URL patterns--the part of a URL after the host name and port which you want to constrain.
> - HTTP methods--the methods within the files that match the URL pattern which you want to constrain (for example, `POST`, `GET`).
> - Guarantees on how the data will be transported between client and server --the choices include `NONE`, `INTEGRAL`, and `CONFIDENTIAL`. These options are discussed in Specifying a Secure Connection.

> This is an example of a security constraint from the example application `<``INSTALL``>/jwstutorial12/examples/jaxrpc/mutualauth/web.xml`:

>     <security-constraint>
>       <web-resource-collection>
>         <web-resource-name>SecureHello</web-resource-name>
>         <url-pattern>/hello</url-pattern>
>         <http-method>GET</http-method>
>         <http-method>POST</http-method>
>       </web-resource-collection>
>       <auth-constraint>
>         <role-name>admin</role-name>
>       </auth-constraint>
>       <user-data-constraint>
>         <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>       </user-data-constraint>
>     </security-constraint>
>     <login-config>
>       <auth-method>BASIC</auth-method>
>     </login-config>

> ### Specifying a Secure Connection

> If the login authentication method in the `<login-config>` tags is set to `BASIC` or `FORM`, passwords are not protected, meaning that passwords sent between a client and a server on a non-protected session can be viewed and intercepted by third parties.

> To configure HTTP basic or form-based authentication over SSL, specify `CONFIDENTIAL` or `INTEGRAL` within the `<transport-guarantee>` elements. Specify `CONFIDENTIAL` when the application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission. Specify `INTEGRAL` when the application requires that the data be sent between client and server in such a way that it cannot be changed in transit. The following example code from a `web.xml` file shows this setting in context:

>     <!-- SECURITY CONSTRAINT -->
>       <security-constraint>
>         <web-resource-collection>
>           <web-resource-name>WRCollection</web-resource-name>
>           <url-pattern>/index.jsp</url-pattern>
>           <http-method>GET</http-method>
>         </web-resource-collection>
>         <auth-constraint>
>           <role-name>user</role-name>
>         </auth-constraint>
>         <user-data-constraint>
>           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
>         </user-data-constraint>
>       </security-constraint>

> If you specify `CONFIDENTIAL` or `INTEGRAL` as a security constraint, that type of security constraint applies to all requests that match the URL patterns in the Web resource collection, not just to the login dialog.

> If the default configuration of your Web server does not support SSL, you must configure it with an SSL connector to make this work. By default, Tomcat is not configured with an SSL Connector. To set up an SSL connector, see Installing and Configuring SSL Support.

> Note: Good Security Practice: If you are using sessions, once you switch to SSL you should never accept any further requests for that session that are non-SSL. For example, a shopping site might not use SSL until the checkout page, then it may switch to using SSL in order to accept your card number. After switching to SSL, you should stop listening to non-SSL requests for this session. The reason for this practice is that the session ID itself was non-encrypted on the earlier communications, which is not so bad when you're just doing your shopping, but once the credit card information is stored in the session, you don't want a bad guy trying to fake the purchase transaction against your credit card. This practice could be easily implemented using a filter.

Download FAQ History |  | API Search Feedback

All of the material in The Java(TM) Web Services Tutorial is copyright-protected and may not be published in other works without express written permission from Sun Microsystems.