BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
| WebLogic Server Doc Home | Web Applications | Previous Topic | Next Topic | Contents | Index | View as PDF

Configuring Security in Web Applications

The following sections describe how to configure security in Web Applications:

- Overview of Configuring Security in Web Applications

- Setting Up Authentication for Web Applications

- Multiple Web Applications, Cookies, and Authentication

- Restricting Access to Resources in a Web Application

- Using Users and Roles Programmatically in Servlets

Overview of Configuring Security in Web Applications

You can secure a Web Application by using authentication, by restricting access to certain resources in the Web Application, or by using security calls in your servlet code. Several types of security realms can be used. Security realms are discussed in the document Security Fundamentals. Note that a security realm is shared across multiple virtual hosts.

Setting Up Authentication for Web Applications

To configure authentication for a Web Application, use the <login-config> element of the web.xml deployment descriptor. In this element you define the security realm containing the user credentials, the method of authentication, and the location of resources for authentication. For information on setting up a security realm, see Security Fundamentals.

To set up authentication for Web Applications:

1. Open the web.xml deployment descriptor in a text editor or use the Administration Console. For more information, see Web Application Developer Tools.

2. Specify the authentication method using the <auth-method> element. The available options are:

     BASIC

     Basic authentication uses the Web Browser to display a username/password dialog box. This username and password is authenticated against the realm.

     FORM

     Form-based authentication requires that you return an HTML form containing the username and password. The fields returned from the form elements must be: j_username and j_password, and the action attribute must be j_security_check. Here is an example of the HTML coding for using FORM authentication:

     <form method="POST" action="j_security_check">

     <input type="text" name="j_username">
     <input type="password" name="j_password">

     </form>

     The resource used to generate the HTML form may be an HTML page, a JSP, or a servlet. You define this resource with the <form-login-page> element.

     The HTTP session object is created when the login page is served. Therefore, the session.isNew() method returns FALSE when called from pages served after successful authentication.

     CLIENT-CERT

     Uses client certificates to authenticate the request. For more information, see Configuring the SSL Protocol.

3. If you choose FORM authentication, also define the location of the resource used to generate the HTML page with the <form-login-page> element and the resource that responds to a failed authentication with the <form-error-page> element. For instructions on configuring form authentication see form-login-config Element.

4. Specify a realm for authentication using the <realm-name> element. If you do not specify a particular realm, the realm defined with the Auth Realm Name field on the Web Application—> Configuration—>Other tab of the Administration Console is used. For more information, see form-login-config Element.

5. If you want to define a separate login for a Web Application, see Multiple Web Applications, Cookies, and Authentication. Otherwise, all Web Applications that use the same cookie use a single sign-on for authentication.

Multiple Web Applications, Cookies, and Authentication

By default, WebLogic Server assigns the same cookie name (JSESSIONID) to all Web Applications. When you use any type of authentication, all Web Applications that use the same cookie name use a single sign-on for authentication. Once a user is authenticated, that authentication is valid for requests to any Web Application that uses the same cookie name. The user is not prompted again for authentication. For more information on single sign-on, see Single Sign-on Requirements.

If you want to require separate authentication for a Web Application, you can specify a unique cookie name or cookie path for the Web Application. Specify the cookie name using the CookieName parameter and the cookie path with the CookiePath parameter, defined in the WebLogic-specific deployment descriptor weblogic.xml, in the <session-descriptor> element. For more information, see session-descriptor Element.

If you want to retain the cookie name and still require independent authentication for each Web Application, you can set the cookie path parameter (CookiePath) differently for each Web Application.

As of Service Pack 5, BEA Systems added a new capability to WebLogic Server that allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this new feature, add AuthCookieEnabled="true" to the WebServer element in config.xml:

>     <WebServer Name="myserver" AuthCookieEnabled="true"/>

Setting AuthCookieEnabled to true causes the WebLogic Server instance to send a new secure cookie to the browser when authenticating via an HTTPS connection. Once the secure cookie is set, the session is allowed to access other security-constrained HTTPS resources only if the cookie is sent from the browser.

Note: If authenticating via plain HTTP, the secure cookie is not set or required for any HTTPS resources. When accessing a non-protected HTTPS resource, the cookie is not verified (since it will not have been sent from the browser). This allows the browser to access non-protected HTTPs resources without the user logging in.

Single Sign-on Requirements

The following are requirements that must be met in order to use single sign-on authentication with WebLogic Server.

- The cookie must be shared (the Name, Path, and Domain must match).

- You must have uniform deployments in all cluster members.

- Single-sign on is only supported across a cluster when it is front-ended by a proxy and when session stickiness is working.

Restricting Access to Resources in a Web Application

To restrict access to specified resources (servlets, JSPs, or HTML pages) in your Web Application you apply security constraints to those resources.

To configure a security constraint:

1. Open the web.xml and weblogic.xml deployment descriptors in a text editor or use the Administration Console. For more information, see Web Application Developer Tools.

2. Define a role that is mapped to one or more principals in a security realm. You define roles with the security-role Element in the Web Application deployment descriptor. You then map these roles to principals in your realm with the security-role-assignment Element in the WebLogic-specific deployment descriptor, weblogic.xml.

3. Define which resources in the Web Application the security constraint applies to by using the <url-pattern> element that is nested inside the <web-resource-collection> element. The <url-pattern> can refer to a directory, filename, or a <servlet-mapping>.

   Alternatively, apply the security constraint to the entire Web Application, use the following entry:

   <url-pattern>/*</url-pattern>

4. Define the HTTP method(s) (GET or POST) that the security constraint applies to using the <http-method> element that is nested inside the <web-resource-collection> element. Use separate <http-method> elements for each HTTP method.

5. Define whether to use SSL for communication between client and server using the <transport-guarantee> element nested inside of the <user-data-constraint> method.

   Listing 5-1 Sample Security Constraint:

   >     web.xml entries:
   >     <security-constraint>
   >          <web-resource-collection>
   >               <web-resource-name>SecureOrdersEast</web-resource-name>
   >               <description>
   >                  Security constraint for
   >                  resources in the orders/east directory
   >               </description>
   >               <url-pattern>/orders/east/*</url-pattern>
   >               <http-method>POST</http-method>
   >               <http-method>GET</http-method>
   >          </web-resource-collection>
   >          <auth-constraint>
   >               <description>
   >                constraint for east coast sales
   >               </description>
   >               <role-name>east</role-name>
   >               <role-name>manager</role-name>
   >          </auth-constraint>
   >          <user-data-constraint>
   >               <description>SSL not required</description>
   >               <transport-guarantee>NONE</transport-guarantee>
   >          </user-data-constraint>
   >     </security-constraint>

   >     ...

Using Users and Roles Programmatically in Servlets

You can write your servlets to access users and roles programmatically in your servlet code using the method javax.servlet.http.HttpServletRequest.isUserInRole(String role). The string role is mapped to the name supplied in the <role-name> element nested inside the <security-role-ref> element of a <servlet> declaration in the Web Application deployment descriptor. The <role-link> element maps to a <role-name> defined in the <security-role> element of the Web Application deployment descriptor.

The following listing provides an example.

Listing 5-2 Example of Security Role Mapping

>     Servlet code:
>     isUserInRole("manager");

>     web.xml entries:

>     <servlet>
>     . . .
>        <role-name>manager</role-name>
>        <role-link>mgr</role-link>
>     . . .
>     </servlet>

>     <security-role>
>        <role-name>mgr</role-name>
>     </security-role>

>     weblogic.xml entries:

>     <security-role-assignment>
>        <role-name>mgr</role-name>
>        <principal-name>al</principal-name>
>        <principal-name>george</principal-name>
>        <principal-name>ralph</principal-name>
>     </security-role-ref>

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.