Security-Role-Assignment Weblogic Server

Programming WebLogic Security

Securing Web Applications

WebLogic Server supports the Java EE architecture security model for securing Web applications, which includes support for declarative authorization (also referred to in this document as declarative security) and programmatic authorization (also referred to in this document as programmatic security).

This section covers the following topics:

Note:You can use deployment descriptor files and the Administration Console to secure Web applications. This document describes how to use deployment descriptor files. For information on using the Administration Console to secure Web applications, see Securing WebLogic Resources Using Roles and Policies.

WebLogic Server supports the use of the and methods and the use of the element in deployment descriptors to implement programmatic authorization in Web applications.

 


Authentication With Web Browsers

Web browsers can connect to WebLogic Server over either a HyperText Transfer Protocol (HTTP) port or an HTTP with SSL (HTTPS) port. The benefits of using an HTTPS port versus an HTTP port are two-fold. With HTTPS connections:

  • All communication on the network between the Web browser and the server is encrypted. None of the communication, including the user name and password, is in clear text.
  • As a minimum authentication requirement, the server is required to present a digital certificate to the Web browser client to prove its identity.

If the server is configured for two-way SSL authentication, both the server and client are required to present a digital certificate to each other to prove their identity.

User Name and Password Authentication

WebLogic Server performs user name and password authentication when users use a Web browser to connect to the server via the HTTP port. In this scenario, the browser and an instance of WebLogic Server interact in the following manner to authenticate a user (see Figure 3-1):

  1. A user invokes a WebLogic resource in WebLogic Server by entering the URL for that resource in a Web browser. The URL contains the HTTP listen port, for example, .
  2. The Web server in WebLogic Server receives the request.
  3. Note:WebLogic Server provides its own Web server but also supports the use of Apache Server, Microsoft Internet Information Server, and Netscape Enterprise Server as Web servers.
  4. The Web server determines whether the WebLogic resource is protected by a security policy. If the WebLogic resource is protected, the Web server uses the established HTTP connection to request a user name and password from the user.
  5. When the user’s Web browser receives the request from the Web server, it prompts the user for a user name and password.
  6. The Web browser sends the request to the Web server again, along with the user name and password.
  7. The Web server forwards the request to the Web server plug-in. WebLogic Server provides the following plug-ins for Web servers:
    • Apache-WebLogic Server plug-in
    • Netscape Server Application Programming Interface (NSAPI)
    • Internet Information Server Application Programming Interface (ISAPI)
    • The Web server plug-in performs authentication by sending the request, via the HTTP protocol, to WebLogic Server, along with the authentication data (user name and password) received from the user.

  8. Upon successful authentication, WebLogic Server proceeds to determine whether the user is authorized to access the WebLogic resource.
  9. Before invoking a method on the WebLogic resource, the WebLogic Server instance performs a security authorization check. During this check, the server security extracts the user’s credentials from the security context, determines the user’s security role, compares the user’s security role to the security policy for the requested WebLogic resource, and verifies that the user is authorized to invoke the method on the WebLogic resource.
  10. If authorization succeeds, the server fulfills the request.
  11. Figure 3-1 Secure Login for Web Browsers



Digital Certificate Authentication

WebLogic Server uses encryption and digital certificate authentication when Web browser users connect to the server via the HTTPS port. In this scenario, the browser and WebLogic Server instance interact in the following manner to authenticate and authorize a user (see Figure 3-1):

  1. A user invokes a WebLogic resource in WebLogic Server by entering the URL for that resource in a Web browser. The URL contains the SSL listen port, for example, .
  2. The Web server in WebLogic Server receives the request.
  3. Note:WebLogic Server provides its own Web server but also supports the use of Apache Server, Microsoft Internet Information Server, and Netscape Enterprise Server as Web servers.
  4. The Web server checks whether the WebLogic resource is protected by a security policy. If the WebLogic resource is protected, the Web server uses the established HTTPS connection to request a user name and password from the user.
  5. When the user’s Web browser receives the request from WebLogic Server, it prompts the user for a user name and password. (This step is optional.)
  6. The Web browser sends the request again, along with the user name and password. (Only supplied if requested by the server.)
  7. WebLogic Server presents its digital certificate to the Web browser.
  8. The Web browser checks that the server’s name used in the URL (for example, ) matches the name in the digital certificate and that the digital certificate was issued by a trusted third party, that is, a trusted CA
  9. If two-way SSL authentication is in force on the server, the server requests a digital certificate from the client.
  10. Note:Even though WebLogic Server cannot be configured to enforce the full two-way SSL handshake with Web Server proxy plug-ins, proxy plug-ins can be configured to provide the client certificate to the server if it is needed. To do this, configure the proxy plug-in to export the client certificate in the HTTP Header for WebLogic Server. For instructions on how to configure proxy plug-ins to export the client certificate to WebLogic Server, see the configuration information for the specific plug-in in Using Web Server Plug-Ins With WebLogic Server.
  11. The Web server forwards the request to the Web server plug-in. If secure proxy is set (this is the case if the HTTPS protocol is being used), the Web server plug-in also performs authentication by sending the request, via the HTTPS protocol, to the WebLogic resource in WebLogic Server, along with the authentication data (user name and password) received from the user.
  12. Note:When using two-way SSL authentication, you can also configure the server to do identity assertion based on the client’s certificate, where, instead of supplying a user name and password, the server extracts the user name and password from the client’s certificate.
  13. Upon successful authentication, WebLogic Server proceeds to determine whether the user is authorized to access the WebLogic resource.
  14. Before invoking a method on the WebLogic resource, the server performs a security authorization check. During this check, the server extracts the user’s credentials from the security context, determines the user’s security role, compares the user’s security role to the security policy for the requested WebLogic resource, and verifies that the user is authorized to invoke the method on the WebLogic resource.
  15. If authorization succeeds, the server fulfills the request.

For more information, see the following documents:

 


Multiple Web Applications, Cookies, and Authentication

By default, WebLogic Server assigns the same cookie name () 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.

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 parameter and the cookie path with the parameter, defined in the WebLogic-specific deployment descriptor element. For more information, see session-descriptor in Developing Web Applications, Servlets, and JSPs for WebLogic Server.

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

WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. This feature enables Web site designers to prevent session stealing. For more information on this feature, see Using Secure Cookies to Prevent Session Stealing.

Using Secure Cookies to Prevent Session Stealing

A common Web security problem is session stealing. This happens when an attacker manages to get a copy of your session cookie, generally while the cookie is being transmitted over the network. This can only happen when the data is being sent in clear-text; that is, the cookie is not encrypted.

WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this feature, add to the element in :

Setting to , which is the default setting, 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:This feature will work even when cookies are disabled because WebLogic Server will use URL rewriting over secure connections to rewrite secure URLs in order to encode the in the URL along with the .

Thus, WebLogic Server uses two cookies: the cookie and the cookie. By default, the cookie is never secure, but the cookie is always secure. A secure cookie is only sent when an encrypted communication channel is in use. Assuming a standard HTTPS login (HTTPS is an encrypted HTTP connection), your browser gets both cookies.

For subsequent HTTP access, you are considered authenticated if you have a valid cookie, but for HTTPS access, you must have both cookies to be considered authenticated. If you only have the cookie, you must re-authenticate.

With this feature enabled, once you have logged in over HTTPS, the secure cookie is only sent encrypted over the network and therefore can never be stolen in transit. The cookie is still subject to in-transit hijacking. Therefore, a Web site designer can ensure that session stealing is not a problem by making all sensitive data require HTTPS. While the HTTP session cookie is still vulnerable to being stolen and used, all sensitive operations require the, which cannot be stolen, so those operations are protected.

You can also specify a cookie name for or using the parameter defined in the deployment descriptor’s element, as follows:

<session-descriptor>
<cookie-name></cookie-name>
</session-descriptor>

In this case, Weblogic Server will not use and , but and to serve the same purpose, as shown in Table 3-1.

User-Specified in Deployment Descriptor

HTTP Session

HTTPS Session

No - uses the default

Yes - specified as

 


Developing Secure Web Applications

WebLogic Server supports three types of authentication for Web browsers:

The following sections cover the different ways to use these types of authentication:

Developing BASIC Authentication Web Applications

With basic authentication, the Web browser pops up a login screen in response to a WebLogic resource request. The login screen prompts the user for a user name and password. Figure 3-2 shows a typical login screen.

Figure 3-2 Authentication Login Screen

To develop a Web application that provides basic authentication, perform these steps:

  1. Create the deployment descriptor. In this file you include the following information (see Listing 3-1):
    1. Define the welcome file. The welcome file name is .
    2. Define a security constraint for each set of Web application resources, that is, URL resources, that you plan to protect. Each set of resources share a common URL. URL resources such as HTML pages, JSPs, and servlets are the most commonly protected, but other types of URL resources are supported. In Listing 3-1, the URL pattern points to the file located in the Web application’s top-level directory; the HTTP methods that are allowed to access the URL resource, POST and GET; and the security role name, .
    3. Note:When specifying security role names, observe the following conventions and restrictions:
      • The proper syntax for a security role name is as defined for an in the Extensible Markup Language (XML) recommendation available on the Web at: http://www.w3.org/TR/REC-xml#NT-Nmtoken.
      • Do not use blank spaces, commas, hyphens, or any characters in this comma-separated list: \t, < >, #, |, &, ~, ?, ( ), { }.
      • Security role names are case sensitive.
      • The BEA suggested convention for security role names is that they be singular.
    4. Use the <login-config> tag to define the type of authentication you want to use and the security realm to which the security constraints will be applied. In Listing 3-1, the BASIC type is specified and the realm is the default realm, which means that the security constraints will apply to the active security realm when the WebLogic Server instance boots.
    5. Define one or more security roles and map them to your security constraints. In our sample, only one security role, , is defined in the security constraint so only one security role name is defined here (see the <security-role> tag in Listing 3-1). However, any number of security roles can be defined.
    6. Listing 3-1 Basic Authentication web.xml File

      <?xml version='1.0' encoding='UTF-8'?>
      <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
          <web-app>
      <welcome-file-list>
      <welcome-file>welcome.jsp</welcome-file>
      </welcome-file-list>
      <security-constraint>
      <web-resource-collection>
      <web-resource-name>Success</web-resource-name>
      <url-pattern>/welcome.jsp</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
      <role-name>webuser</role-name>
      </auth-constraint>
      </security-constraint>
      <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>default</realm-name>
      </login-config>
      <security-role>
      <role-name>webuser</role-name>
      </security-role>
      </web-app>
  2. Create the deployment descriptor. In this file you map security role names to users and groups. Listing 3-2 shows a sample file that maps the security role defined in the <security-role> tag in the file to a group named . Note that principals can be users or groups, so the can be used for either. With this configuration, WebLogic Server will only allow users in to access the protected URL resource—.
  3. Note:Starting in version 9.0, the default role mapping behavior is to create empty role mappings when none are specified in . In version 8.x, if you did not include a file, or included the file but did not include mappings for all security roles, security roles without mappings defaulted to any user or group whose name matched the role name. For information on role mapping behavior and backward compatibility settings, see the section Understanding the Combined Role Mapping Enabled Setting in the Securing WebLogic Resources Using Roles and Policies manual.

    Listing 3-2 BASIC Authentication weblogic.xml File

    <?xml version='1.0' encoding='UTF-8'?>
    <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <security-role-assignment>
    <role-name>webuser</role-name>
    <principal-name>myGroup</principal-name>
    </security-role-assignment>
    </weblogic-web-app>
  4. Create a file that produces the Welcome screen that displays when the user enters a user name and password and is granted access. Listing 3-3 shows a sample file. Figure 3-3 shows the Welcome screen.
  5. Listing 3-3 BASIC Authentication welcome.jsp File

    <html>
    <head>
    <title>Browser Based Authentication Example Welcome Page</title>
    </head>
    <h1> Browser Based Authentication Example Welcome Page </h1>
    <p> Welcome <%= request.getRemoteUser() %>!
    </blockquote>
    </body>
    </html>
Note:In Listing 3-3, notice that the JSP is calling an API () to get the name of the user that logged in. A different API, , could be used instead. To use this API to get the name of the user, use it with the API as follows:
String username = weblogic.security.SubjectUtils.getUsername(
weblogic.security.Security.getCurrentSubject());

Figure 3-3 Welcome Screen



  1. Start WebLogic Server and define the users and groups that will have access to the URL resource. In the file (see Listing 3-2), the <principal-name> tag defines as the group that has access to the . Therefore, use the Administration Console to define the group, define a user, and add that user to the group. For information on adding users and groups, see Users, Groups, and Security Roles in Securing WebLogic Resources Using Roles and Policies.
  2. Deploy the Web application and use the user defined in the previous step to access the protected URL resource.
    1. For deployment instructions, see Deploying Web Applications on page 3-26.
    2. Open a Web browser and enter this URL:
    3. Enter the user name and password. The Welcome screen displays.

Using HttpSessionListener to Account for Browser Caching of Credentials

The browser caches user credentials and frequently re-sends them to the server automatically. This can give the appearance that WebLogic Server sessions are not being destroyed after logout or timeout. Depending on the browser, the credentials can be cached just for the current browser session, or across browser sessions.

You can validate that a WebLogic Server's session was destroyed by creating a class that implements the interface. Implementations of this interface are notified of changes to the list of active sessions in a web application. To receive notification events, the implementation class must be configured in the deployment descriptor for the web application in .

To configure a session listener class:

  1. Open the deployment descriptor of the Web application for which you are creating a session listener class in a text editor. The file is located in the WEB-INF directory of your Web application.
  2. Add an event declaration using the listener element of the web.xml deployment descriptor. The event declaration defines the event listener class that is invoked when the event occurs. For example:
    See Configuring an Event Listener Class for additional information and guidelines.

Write and deploy the session listener class. The example shown in Listing 3-4 uses a simple counter to track the session count.

Listing 3-4 Tracking the Session Count

import javax.servlet.http.HttpSessionListener;
import javax.servlet.http.HttpSessionEvent;
public class MySessionListener implements HttpSessionListener {
private static int sessionCount = 0;

public void sessionCreated(HttpSessionEvent se) {
sessionCount++;
// Write to a log or do some other processing.
}
public void sessionDestroyed(HttpSessionEvent se) {
if(sessionCount > 0)
sessionCount--;
//Write to a log or do some other processing.
}

Understanding BASIC Authentication with Unsecured Resources

For WebLogic Server versions 9.2 and later, client requests that use HTTP BASIC authentication must pass WebLogic Server authentication, even if access control is not enabled on the target resource.

The setting of the Security Configuration MBean flag determines this behavior. (The DomainMBean can return the new Security Configuration MBean for the domain.) It specifies whether or not the system should allow requests with invalid HTTP BASIC authentication credentials to access unsecured resources.

Note:The Security Configuration MBean provides domain-wide security configuration information. The enforce-valid-basic-auth-credentials flag effects the entire domain.

The flag is true by default, and WebLogic Server authentication is performed. If authentication fails, the request is rejected. WebLogic Server must therefore have knowledge of the user and password.

You may want to change the default behavior if you rely on an alternate authentication mechanism. For example, you might use a backend web service to authenticate the client, and WebLogic Server does not need to know about the user. With the default authentication enforcement enabled, the web service can do its own authentication, but only if WebLogic Server authentication first succeeds.

If you explicitly set the flag to false, WebLogic Server does not perform authentication for HTTP BASIC authentication client requests for which access control was not enabled for the target resource.

In the previous example of a backend web service that authenticates the client, the web service can then perform its own authentication without WebLogic Server having knowledge of the user.

Setting the enforce-valid-basic-auth-credentials Flag

To set the e flag, perform the following steps:

  1. Add the element to within the element.
  2. Start or restart all of the servers in the domain.

Using WLST to Check the Value of enforce-valid-basic-auth-credentials

The Administration Console does not display or log the setting. However, you can use WLST to check the value in a running server. Remember that is a domain-wide setting.

The WLST session shown in Listing 3-5 demonstrates how to check the value of the flag in a sample running server.

Listing 3-5 Checking the Value of enforce-valid-basic-auth-credentials

wls:/offline> connect('weblogic','weblogic','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'examplesServer' that belongs to domain '
wl_server'.
wls:/wl_server/serverConfig> cd('SecurityConfiguration')
wls:/wl_server/serverConfig/SecurityConfiguration> ls()
wls:/wl_server/serverConfig/SecurityConfiguration> cd('wl_server')
wls:/wl_server/serverConfig/SecurityConfiguration/wl_server> ls()
-r-- AnonymousAdminLookupEnabled false
-r-- CompatibilityConnectionFiltersEnabled false
-r-- ConnectionFilter null
-r-- ConnectionFilterRules null
-r-- ConnectionLoggerEnabled false
-r-- ConsoleFullDelegationEnabled false
-r-- CredentialEncrypted ******
-r-- CrossDomainSecurityEnabled false
-r-- DowngradeUntrustedPrincipals false
-r-- EnforceStrictURLPattern true

Developing FORM Authentication Web Applications

When using FORM authentication with Web applications, you provide a custom login screen that the Web browser displays in response to a Web application resource request and an error screen that displays if the login fails. The login screen can be generated using an HTML page, JSP, or servlet. The benefit of form-based login is that you have complete control over these screens so that you can design them to meet the requirements of your application or enterprise policy/guideline.

The login screen prompts the user for a user name and password. Figure 3-4 shows a typical login screen generated using a JSP and Listing 3-6 shows the source code.

Figure 3-4 Form-Based Login Screen (login.jsp)

Listing 3-6 Form-Based Login Screen Source Code (login.jsp)

<html>
<head>)
<title>Security WebApp login page</title>
</head>
<body bgcolor="#cccccc">
<blockquote>
<img src=BEA_Button_Final_web.gif align=right>
<h2>Please enter your user name and password:</h2>
<p>
<form method="POST" action="j_security_check">
<table border=1>
<tr>
<td>Username:</td>
<td><input type="text" name="j_username"></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="j_password"></td>
</tr>
<tr>
<td colspan=2 align=right><input type=submit
value="Submit"></td>
</tr>
</table>
</form>
</blockquote>
</body>
</html>

Figure 3-5 shows a typical login error screen generated using HTML and Listing 3-7 shows the source code.

Figure 3-5 Login Error Screen

Listing 3-7 Login Error Screen Source Code

<html>
<head>
<title>Login failed</title>
</head>
<body bgcolor=#ffffff>
<blockquote>
<img src=/security/BEA_Button_Final_web.gif align=right>
<h2>Sorry, your user name and password were not recognized.</h2>
<p><b>
<a href="/security/welcome.jsp">Return to welcome page</a> or
<a href="/security/logout.jsp">logout</a>
</b>
</blockquote>
</body>
</html>

To develop a Web application that provides FORM authentication, perform these steps:

  1. Create the deployment descriptor. In this file you include the following information (see Listing 3-8):
    1. Define the welcome file. The welcome file name is .
    2. Define a security constraint for each set of URL resources that you plan to protect. Each set of URL resources share a common URL. URL resources such as HTML pages, JSPs, and servlets are the most commonly protected, but other types of URL resources are supported. In Listing 3-8, the URL pattern points to /admin/edit.jsp, thus protecting the file located in the Web application’s sub-directory, defines the HTTP method that is allowed to access the URL resource, , and defines the security role name, .
    3. Note:Do not use hyphens in security role names. Security role names with hyphens cannot be modified in the Administration Console. Also, the BEA suggested convention for security role names is that they be singular.
    4. Define the type of authentication you want to use and the security realm to which the security constraints will be applied. In this case, the type is specified and no realm is specified, so the realm is the default realm, which means that the security constraints will apply to the security realm that is activated when a WebLogic Server instance boots.
    5. Define one or more security roles and map them to your security constraints. In our sample, only one security role, , is defined in the security constraint so only one security role name is defined here. However, any number of security roles can be defined.
    6. Listing 3-8 FORM Authentication web.xml File

      <?xml version='1.0' encoding='UTF-8'?>
      <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
      <welcome-file-list>
      <welcome-file>welcome.jsp</welcome-file>
      </welcome-file-list>
      <security-constraint>
      <web-resource-collection>
      <web-resource-name>AdminPages</web-resource-name>
      <description>
      These pages are only accessible by authorized
      administrators.
      </description>
      <url-pattern>/admin/edit.jsp</url-pattern>
      <http-method>GET</http-method>
      </web-resource-collection>
      <auth-constraint>
      <description>
      These are the roles who have access.
      </description>
      <role-name>
      admin
      </role-name>
      </auth-constraint>
      <user-data-constraint>
      <description>
      This is how the user data must be transmitted.
      </description>
      <transport-guarantee>NONE</transport-guarantee>
      </user-data-constraint>
      </security-constraint>
      <login-config>
      <auth-method>FORM</auth-method>
      <form-login-config>
      <form-login-page>/login.jsp</form-login-page>
      <form-error-page>/fail_login.html</form-error-page>
      </form-login-config>
      </login-config>
      <security-role>
      <description>
      An administrator
      </description>
      <role-name>
      admin
      </role-name>
      </security-role>
      </web-app>
  2. Create the deployment descriptor. In this file you map security role names to users and groups. Listing 3-9 shows a sample file that maps the security role defined in the <security-role> tag in the file to the group . With this configuration, WebLogic Server will only allow users in the group to access the protected WebLogic resource. However, you can use the Administration Console to modify the Web application’s security role so that other groups can be allowed to access the protected WebLogic resource.
  3. Listing 3-9 FORM Authentication weblogic.xml File

    <?xml version='1.0' encoding='UTF-8'?>
    <weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <security-role-assignment>
    <role-name>admin</role-name>
    <principal-name>supportGroup</principal-name>
    </security-role-assignment>
    </weblogic-web-app>
  4. Create a Web application file that produces the welcome screen when the user requests the protected Web application resource by entering the URL. Listing 3-10 shows a sample file. Figure 3-3 shows the Welcome screen.
  5. Listing 3-10 Form Authentication welcome.jsp File

    <html>
    <head>
    <title>Security login example</title>
    </head>
    <%
    String bgcolor;
    if ((bgcolor=(String)application.getAttribute("Background")) ==
    null)
    {
    bgcolor="#cccccc";
    }
    %>
    <body bgcolor=<%="\""+bgcolor+"\""%>>
    <blockquote>
    <img src=BEA_Button_Final_web.gif align=right>
    <h1> Security Login Example </h1>
    <p> Welcome <%= request.getRemoteUser() %>!
    <p> If you are an administrator, you can configure the background
    color of the Web Application.
    <br> <b><a href="admin/edit.jsp">Configure background</a></b>.
    <% if (request.getRemoteUser() != null) { %>
    <p> Click here to <a href="logout.jsp">logout</a>.
    <% } %>
    </blockquote>
    </body>
    </html>
Note:In Listing 3-3, notice that the JSP is calling an API () to get the name of the user that logged in. A different API, , could be used instead. To use this API to get the name of the user, use it with the API as follows:
String username = weblogic.security.SubjectUtils.getUsername(
weblogic.security.Security.getCurrentSubject());
  1. Start WebLogic Server and define the users and groups that will have access to the URL resource. In the file (see Listing 3-9), the <role-name> tag defines as the group that has access to the , file and defines the user as a member of that group. Therefore, use the Administration Console to define the group, and define user and add to the group. You can also define other users and add them to the group and they will also have access to the protected WebLogic resource. For information on adding users and groups, see Users, Groups, and Security Roles in Securing WebLogic Resources Using Roles and Policies.
  2. Deploy the Web application and use the user(s) defined in the previous step to access the protected Web application resource.
    1. For deployment instructions, see Deploying Web Applications on page 3-26.
    2. Open a Web browser and enter this URL:
    3. Enter the user name and password. The Welcome screen displays.

Using Identity Assertion for Web Application Authentication

You use identity assertion in Web applications to verify client identities for authentication purposes. When using identity assertion, the following requirements must be met:

  1. The authentication type must be set to CLIENT-CERT.
  2. An Identity Assertion provider must be configured in the server. If the Web browser or Java client requests a WebLogic Server resource protected by a security policy, WebLogic Server requires that the Web browser or Java client have an identity. The WebLogic Identity Assertion provider maps the token from a Web browser or Java client to a user in a WebLogic Server security realm. For information on how to configure an Identity Assertion provider, see Configuring Identity Assertion Providers in Securing WebLogic Server.
  3. The user corresponding to the token’s value must be defined in the server’s security realm; otherwise the client will not be allowed to access a protected WebLogic resource. For information on configuring users on the server, see Users, Groups, and Security Roles in Securing WebLogic Resources Using Roles and Policies.

Using Two-Way SSL for Web Application Authentication

You use two-way SSL in Web applications to verify that clients are whom they claim to be. When using two-way SSL, the following requirements must be met:

  1. The authentication type must be set to CLIENT-CERT.
  2. The server must be configured for two-way SSL. For information on using SSL and digital certificates, see Using SSL Authentication in Java Clients.. For information on configuring SSL on the server, see Configuring SSL in Securing WebLogic Server.
  3. The client must use HTTPS to access the Web application on the server.
  4. An Identity Assertion provider must be configured in the server. If the Web browser or Java client requests a WebLogic Server resource protected by a security policy, WebLogic Server requires that the Web browser or Java client have an identity. The WebLogic Identity Assertion provider allows you to enable a user name mapper in the server that maps the digital certificate of a Web browser or Java client to a user in a WebLogic Server security realm. For information on how to configure security providers, see Configuring Security Providers in Managing WebLogic Security.
  5. The user corresponding to the Subject's Distinguished Name (SubjectDN) attribute in the client’s digital certificate must be defined in the server’s security realm; otherwise the client will not be allowed to access a protected WebLogic resource. For information on configuring users on the server, see Users, Groups, and Security Roles in Securing WebLogic Resources Using Roles and Policies.
Note:When you use SSL authentication, it is not necessary to use and files to specify server configuration because you use the Administration Console to specify the server’s SSL configuration.

Providing a Fallback Mechanism for Authentication Methods

The Servlet 2.4 specification allows you to define the authentication method (BASIC, FORM, etc.) to be used in a Web application. WebLogic Server provides an security module that allows you to define multiple authentication methods (as a comma separated list), so the container can provide a fall-back mechanism. Authentication will be attempted in the order the values are defined in the list.

For example, you can define the following list in the element of your file:

<login-config>
<auth-method>CLIENT-CERT,BASIC</auth-method>
</login-config>

Then the container will first try to authenticate by looking at the CLIENT-CERT value. If that should fail, the container will challenge the user-agent for BASIC authentication.

If either FORM or BASIC are configured, then they must exist at the end of the list since they require a round-trip communication with the user. However, both FORM and BASIC cannot exist together in the list of values.

Configuration

The authentication security can be configured in two ways:

  • Define a comma separated list of values in the element of your file.
  • Define the values as a comma separated list on the and in the element of your use the REALM value, then the Web application will pick up the authentication methods from the security realm.

WebLogic Java Management Extensions (JMX) enables you to access the to create and manage the securtity resources. For more information, see “Overview of WebLogic Server Subsystem MBeans” in Programming WebLogic JMX Management Interfaces Guide.

Developing Swing-Based Authentication Web Applications

Web browsers can also be used to run graphical user interfaces (GUIs) that were developed using Java Foundation Classes (JFC) Swing components; the Swing component kit is integrated into the Java 2 platform, Standard Edition (J2SE).

For information on how to create a graphical user interface (GUI) for applications and applets using the Swing components, see the Creating a GUI with JFC/Swing tutorial (also known as The Swing Tutorial) produced by Sun Microsystems, Inc. You can access this tutorial on the Web at http://java.sun.com/docs/books/tutorial/uiswing/.

After you have developed your Swing-based GUI, refer to Developing FORM Authentication Web Applications and use the Swing-based screens to perform the steps required to develop a Web application that provides FORM authentication.

Note:When developing a Swing-based GUI, do not rely on the Java Virtual Machine-wide user for child threads of the swing event thread. This is not Java EE compliant and does not work in thin clients, or in IIOP in general. Instead, take either of the following approaches:
  • Make sure an is created before any Swing artifacts.
  • Or, use the Java Authentication and Authorization Service (JAAS) to log in and then use the method inside the Swing event thread and its children.

Deploying Web Applications

To deploy a Web application on a server running in development mode, perform the following steps:

Note:For more information about deploying Web applications in either development of production mode, see Deploying Applications and Modules in Deploying Applications to WebLogic Server.
  1. Set up a directory structure for the Web application’s files. Figure 3-6 shows the directory structure for the Web application named . The top-level directory must be assigned the name of the Web application and the sub-directory must be named .
  2. Figure 3-6 Basicauth Web Application Directory Structure



  3. To deploy the Web application in exploded directory format, that is, not in the Java archive (jar) format, simply move your directory to the directory on your server. For example, you would deploy the Web application in the following location:
  4. If the WebLogic Server instance is running, the application should auto-deploy. Use the Administration Console to verify that the application deployed.

    If the WebLogic Server instance is not running, the Web application should auto-deploy when you start the server.

  5. If you have not done so already, use the Administration Console to configure the users and groups that will have access to the Web application. To determine the users and groups that are allowed access to the protected WebLogic resource, examine the file. For example, the file for the sample (see Listing 3-2) defines as the only group to have access to the file.

For more information on deploying secure Web applications, see Deploying Applications and Modules in Deploying Applications to WebLogic Server.

 


Using Declarative Security With Web Applications

There are three ways to implement declarative security:

Which of these three methods is used is defined by the JACC flags and the security model. (Security models are described in Options for Securing EJB and Web Application Resources in Securing WebLogic Resources Using Roles and Policies.)

To implement declarative security in Web applications, you can use deployment descriptors ( and ) to define security requirements. The deployment descriptors map the application’s logical security requirements to its runtime definitions. And at runtime, the servlet container uses the security definitions to enforce the requirements. For a discussion of using deployment descriptors, see Developing Secure Web Applications.

For information about how to use deployment descriptors and the element to configure security in Web applications declaratively, see externally-defined.

For information about how to use the Administration Console to configure security in Web applications, see Securing WebLogic Resources Using Roles and Policies.

 


Web Application Security-Related Deployment Descriptors

The following topics describe the deployment descriptor elements that are used in the and l files to define security requirements in Web applications:

web.xml Deployment Descriptors

The following security-related deployment descriptor elements are supported by WebLogic Server:

auth-constraint

The optional element defines which groups or principals have access to the collection of Web resources defined in this security constraint.

The following table describes the elements you can define within an element.

Element

Required/
Optional

Description

Optional

A text description of this security constraint.

Optional

Defines which security roles can access resources defined in this . Security role names are mapped to principals using the elementSee security-role-ref.

Used Within

The element is used within the element.

Example

See Listing 3-11 for an example of how to use the element in a file.

security-constraint

The element is used in the file to define the access privileges to a collection of resources defined by the element.

The following table describes the elements you can define within a security-constraint element.

Element

Required/
Optional

Description

Required

Defines the components of the Web Application to which this security constraint is applied. For more information, see web-resource-collection.

Optional

Defines which groups or principals have access to the collection of web resources defined in this security constraint.For more information, see auth-constraint.

Optional

Defines defines how data communicated between the client and the server should be protected. For more information, see user-data-constraint

Example

Listing 3-11 shows how to use the element to defined security for the SecureOrdersEast resource in a file.

Listing 3-11 Security Constraint Example

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></url-pattern>
          <http-method></http-method>
          <http-method></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>
...

security-role

The element contains the definition of a security role. The definition consists of an optional description of the security role, and the security role name.

The following table describes the elements you can define within a element.

Element

Required/
Optional

Description

Optional

A text description of this security role.

Required

The role name. The name you use here must have a corresponding entry in the WebLogic-specific deployment descriptor, which maps roles to principals in the security realm. For more information, see security-role-assignment.

Example

See Listing 3-14 for an example of how to use the element in a file.

security-role-ref

The element links a security role name defined by to an alternative role name that is hard-coded in the servlet logic. This extra layer of abstraction allows the servlet to be configured at deployment without changing servlet code.

The following table describes the elements you can define within a element.

Element

Required/
Optional

Description

Optional

Text description of the role.

Required

Defines the name of the security role or principal that is used in the servlet code.

Required

Defines the name of the security role that is defined in a element later in the deployment descriptor.

Example

See Listing 3-17 for an example of how to use the element in a file.

user-data-constraint

The element defines how data communicated between the client and the server should be protected.

The following table describes the elements you can define within a element.

Element

Required/
Optional

Description

Optional

A text description.

Required

Specifies data security requirements for communications between the client and the server.

Range of values:

The application does not require any transport guarantees.

The application requires that the data be sent between the client and server in such a way that it cannot be changed in transit.

The application requires that data be transmitted so as to prevent other entities from observing the contents of the transmission.

WebLogic Server establishes a Secure Sockets Layer (SSL) connection when the user is authenticated using the or transport guarantee.

Used Within

The element is used within the element.

Example

See Listing 3-11 for an example of how to use the element in a file.

web-resource-collection

The element identifies a subset of the resources and methods on those resources within a Web application to which a security constraint applies. If no methods are specified, the security constraint applies to all methods.

The following table describes the elements you can define within a element.

Element

Required/
Optional

Description

Required

The name of this web resource collection.

Optional

Text description of the Web resource.

Required

The mapping, or location, of the Web resource collection.

URL patterns must use the syntax defined in section 11.2 of JSR-000154, Java Servlet Specification Version 2.4.

The pattern applies the security constraint to the entire Web application.

Optional

The methods to which the security constraint applies when clients attempt to access the Web resource collection. If no methods are specified, then the security constraint applies to all methods.

Used Within

The element is used within the element.

Example

See Listing 3-11 for an example of how to use the element in a file.

weblogic.xml Deployment Descriptors

The following security-related deployment descriptor elements are supported by WebLogic Server:

This document provides a complete reference for the elements in the WebLogic Server-specific deployment descriptor weblogic.xml. If your Web application does not contain a weblogic.xml deployment descriptor, WebLogic Server automatically selects the default values of the deployment descriptor elements. To see the schema for , go to http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd.

The following sections describe the complex deployment descriptor elements that can be defined in the weblogic.xml deployment descriptor under the root element :

The description element is a text description of the Web application.

The element indicates the version of WebLogic Server on which this Web application (as defined in the root element ) is intended to be deployed. This element is informational only and is not used by WebLogic Server.

The element declares a mapping between a Web application security role and one or more principals in WebLogic Server, as shown in the following example.

You can also use it to mark a given role as an externally defined role, as shown in the following example:

Notes: In the element, either or must be defined. Both cannot be omitted.

The following table describes the elements you can define within a element.

Note: If you do not define a security-role-assignment element and its subelements, the Web application container implicitly maps the role name as a principal name and logs a warning. The EJB container does not deploy the module if mappings are not defined.

Consider the following usage scenarios for the role name is "role_xyz"

    • If you map"role_xyz to user "joe" in weblogic.xml, role_xyz becomes a local role.
    • If you specify role_xyz as an externally defined role, it becomes global (it refers to the role defined at the realm level).
    • If you do not define a security-role-assignment element, role_xyz becomes a local role, and the Web application container creates an implicit mapping to it and logs a warning.

 


run-as-role-assignment

The run-as-role-assignment element maps a run-as role name (a subelement of the servlet element) in web.xml to a valid user name in the system. The value can be overridden for a given servlet by the run-as-principal-name element in the servlet-descriptor. If the run-as-role-assignment is absent for a given role name, the Web application container uses the first principal-name defined in the security-role-assignment. The following example illustrates how to use the run-as-role-assignment element.

The following table describes the elements you can define within a element.

Element

Required
Optional

Description

Required

Specifies the name of a security role.

Required

Specifies the name of a principal.

 


reference-descriptorGroup

The a weblogic.xml deployment descriptor refers to the reference-descriptorGroup, which is part of the weblogic-j2ee-xsd file.The following sub-elements of reference-descriptorGroup are used by the

Element Name

Default Value

Value

The element is used to map the JNDI name of a server resource to an EJB resource reference in WebLogic Server. See resource-description.

The element maps a , declared in the deployment descriptor, to the JNDI name of the server resource it represents. See resource-env-description.

ejb-reference-description

See ejb-reference-description.

See service-reference-description.

weblogic.xml deployment descriptor.

resource-description

The element is used to map the JNDI name of a server resource to an EJB resource reference in WebLogic Server.

The following table describes the elements you can define within a element

Element

Required/
Optional

Description

Required

Specifies the name of a resource reference.

Required

Specifies a JNDI name for the resource.

.

resource-env-description

The element maps a , declared in the deployment descriptor, to the JNDI name of the server resource it represents.

The following table describes the elements you can define within a element

Element

Required/
Optional

Description

Required

Specifies the name of a resource environment reference.

Required

Specifies a JNDI name for the resource environment reference.

.

ejb-reference-description

The following table describes the elements you can define within a element

Element

Required/
Optional

Description

Required

Specifies the name of an EJB reference used in your Web application.

Required

Specifies a JNDI name for the reference.

.

service-reference-description

The following table describes the elements you can define within a element

Element

Required/
Optional

Description

<call-property>

The <call-property> element has the following sub-elements:

<port-info>

The <port-info> element has the following sub-elements:

 


session-descriptor

The elements that define parameters for servlet sessions.

Element Name

Default Value

Value

3600

Sets the time, in seconds, that WebLogic Server waits before timing out a session. The default value is 3600 seconds.

On busy sites, you can tune your application by adjusting the timeout of sessions. While you want to give a browser client every opportunity to finish a session, you do not want to tie up the server needlessly if the user has left the site or otherwise abandoned the session.

This element can be overridden by the element (defined in minutes) in .

Sets the time, in seconds, that WebLogic Server waits between doing house-cleaning checks for timed-out and invalid sessions, and deleting the old sessions and freeing up memory. Use this element to tune WebLogic Server for best performance on high traffic sites.

The default value is 60 seconds.

false

Enables Web applications to share HTTP sessions when the value is set to at the application level.

This element is ignored if turned on at the Web application level.

debug-enabled

false

Enables the debugging feature for HTTP sessions.

The default value is false.

52

Sets the size of the session ID.

The minimum value is 8 bytes and the maximum value is Integer.MAX_VALUE.

If you are writing a WAP application, you must use URL rewriting because the WAP protocol does not support cookies. Also, some WAP devices have a 128-character limit on URL length (including attributes), which limits the amount of data that can be transmitted using URL re-writing. To allow more space for attributes, use this attribute to limit the size of the session ID that is randomly generated by WebLogic Server.

You can also limit the length to a fixed 52 characters, and disallow special characters, by setting the WAPEnabled attribute. For more information, see URL Rewriting and Wireless Access Protocol in Developing Web Applications for WebLogic Server.

tracking-enabled

true

Enables session tracking between HTTP requests.

cache-size

1028

Sets the cache size for JDBC and file-persistent sessions.

max-in-memory-sessions

-1

Sets the maximum limit for memory/replicated sessions.

Without the ability to configure bound in-memory servlet session use, as new sessions are continually created, the server eventually throws out of memory. To protect against this, WebLogic Server provides a configurable bound on the number of sessions created. When this number is exceeded, the weblogic.servlet.SessionCreationException occurs for each attempt to create a new session. This feature applies to both replicated and non-replicated in-memory sessions.

To configure bound in-memory servlet session use, you set the limitation in the max-in-memory-sessions element.

The default is -1 (unlimited).

Use of session cookies is enabled by default and is recommended, but you can disable them by setting this property to . You might turn this option off to test.

Defines the session tracking cookie name. Defaults to if not set. You may set this to a more specific name for your application.

null

Defines the session tracking cookie path.

If not set, this attribute defaults to (slash), where the browser sends cookies to all URLs served by WebLogic Server. You may set the path to a narrower mapping, to limit the request URLs to which the browser sends cookies.

null

Specifies the domain for which the cookie is valid. For example, setting to returns cookies to any server in the domain.

The domain name must have at least two components. Setting a name to or is not valid.

If not set, this attribute defaults to the server that issued the cookie.

For more information, see in the Servlet specification from Sun Microsystems.

null

Specifies the comment that identifies the session tracking cookie in the cookie file.

Tells the browser to only send the cookie back over an HTTPS connection. This ensures that the cookie ID is secure and should only be used on Websites that use HTTPS. Session Cookies over HTTP no longer work if this feature is enabled.

You should disable the element if you intend to use this feature.

-1

Sets the life span of the session cookie, in seconds, after which it expires on the client.

The default value is -1 (unlimited)

For more information about cookies, see Using Sessions and Session Persistence.

Sets the persistent store method to one of the following options:

  • —Disables persistent session storage.

  • —Same as , but session data is replicated across the clustered servers.

  • replicated_if_clustered—If the Web application is deployed on a clustered server, the in-effect will be replicated. Otherwise, is the default.

  • sync-replication-across-cluster—The replication will occur synchronously across the cluster.

  • async-replication-across-cluster—The replication will occur asynchronously across the cluster.

  • —Uses file-based persistence (See also , above).

  • cookie—All session data is stored in a cookie in the user's browser.

Sets the name of the cookie used for cookie-based persistence. The cookie carries the session state, which should not be shared between Web applications.

For more information, see Using Cookie-Based Session Persistence.

Specifies the storage directory used for file-based persistence

Ensure that you have enough disk space to store the number of valid sessions multiplied by the size of each session. You can find the size of a session by looking at the files created in the . Note that the size of each session can vary as the size of serialized session data changes.

You can make file-persistent sessions clusterable by making this directory a shared directory among different servers.

You must create this directory manually.

Specifies the name of a JDBC connection pool to be used for persistence storage.

Specifies the database table name used to store JDBC-based persistent sessions. This applies only when is set to jdbc.

The element is used when you choose a database table name other than the default.

jdbc-column-name-max-inactive-interval

Serves as an alternative name for the wl_max_inactive_interval column name. This jdbc-column-name-max-inactive-interval element applies only to JDBC-based persistence. It is required for certain databases that do not support long column names.

120

Note: This is a deprecated item for this release.

Sets the time, in seconds, that WebLogic Server waits before timing out a JDBC connection, where x is the number of seconds between.

true

Enables URL rewriting, which encodes the session ID into the URL and provides session tracking if cookies are disabled in the browser.

http-proxy-caching-of-cookies

true

When set to , WebLogic Server adds the following header with the following response:

"Cache-control: no-cache=set-cookie"

This indicates that the proxy caches do not cache the cookies.

The latest servlet specification requires containers to encode the session ID in path parameters. Certain Web servers do not work well with path parameters. In such cases, the encode-session-id-in-query-params element should be set to true. (The default is .)

Used in ServletSessionRuntimeMBean. The getMainAttribute() of the ServletSessionRuntimeMBean returns the session attribute value using this string as a key.

Example: user-name

This element is useful for tagging session runtime information for different sessions.

 


jsp-descriptor

The element specifies a list of configuration parameters for the JSP compiler. The following table describes the elements you can define within a element..

Element

Required/
Optional

Description

Sets the interval, in seconds, at which WebLogic Server checks to see if JSP files have changed and need recompiling. Dependencies are also checked and recursively reloaded if changed.

If set to 0, pages are checked on every request. This default is preset for a development environment. If set to , page checking and recompiling is disabled.

In a production environment where changes to a JSP are rare, change the value of pageCheckSeconds to 60 or greater, according to your tuning requirements, or to -1 to disable page checking and recompiling.

precompile

When set to true, WebLogic Server automatically precompiles all modified JSPs when the Web application is deployed or re-deployed or when starting WebLogic Server.

precompile-continue

false

When set to true, WebLogic Server continues precompiling all modified JSPs even if some of those JSPs fail during compilation. Only takes effect when precompile is set to true.

Saves the Java files that are generated as an intermediary step in the JSP compilation process. Unless this parameter is set to , the intermediate Java files are deleted after they are compiled.

When set to , debugging information is printed out to the browser, the command prompt, and WebLogic Server log file.

internally generated directory

The name of a directory where WebLogic Server saves the generated Java and compiled class files for a JSP.

print-nulls

null

When set to false, this parameter ensures that expressions with "null" results are printed as " ".

backward-compatible

true

When set to true, backward compatibility is enabled.

Default encoding of your platform

Specifies the default character set used in the JSP page. Use standard Java character set names.

If not set, this attribute defaults to the encoding for your platform.

A JSP page directive (included in the JSP code) overrides this setting. For example:

Specifies the package prefix into which all JSP pages are compiled.

exact-mapping

When true, upon the first request for a JSP the newly created JspStub is mapped to the exact request. If exactMapping is set to false, the Web application container generates non-exact url mapping for JSPs. exactMapping allows path info for JSP pages.

default-file-name

true

The default file name in which WebLogic Server saves the generated Java and compiled class files for a JSP.

rtexprvalue-jsp-param-name

Allows runtime expression values in the name attribute of the tag. It is set to by default.

 


auth-filter

The auth-filter element specifies an authentication filter HttpServlet class.

Note: This is a deprecated element for the current release. Instead, use servlet authentication filters.

 


container-descriptor

The element specifies a list of parameters that affect the behavior of the Web application.

check-auth-on-forward

Add the element when you want to require authentication of forwarded requests from a servlet or JSP. Omit the tag if you do not want to require re-authentication. For example:

Note: As a best practice, BEA does not recommend that you enable the check-auth-on-forward property.

filter-dispatched-requests-enabled

The element controls whether or not filters are applied to dispatched requests. The default value is false.

Note: Because 2.4 servlets are backward compatible with 2.3 servlets (per the 2.4 specification), when 2.3 descriptor elements are detected by WebLogic Server, the element defaults to true.

redirect-with-absolute-url

The element controls whether the method redirects using a relative or absolute URL. Set this element to if you are using a proxy HTTP server and do not want the URL converted to a non-relative link.

The default behavior is to convert the URL to a non-relative link.

user readable data used in a redirect.

index-directory-enabled

The <index-directory-enabled> element controls whether or not to automatically generate an HTML directory listing if no suitable index file is found.

The default value is (does not generate a directory). Values are or .

index-directory-sort-by

The <index-directory-sort-by> element defines the order in which the directory listing generated by weblogic.servlet.FileServlet is sorted. Valid sort-by values are NAME, LAST_MODIFIED, and SIZE. The default sort-by value is NAME.

servlet-reload-check-secs

The <servlet-reload-check-secs> element defines whether a WebLogic Server will check to see if a servlet has been modified, and if it has been modified, reloads it. The -1 value tells the server never to check the servlets, 0 tells the server to always check the servlets, and the default is to check each 1 second.

A value specified in the console will always take precedence over a manually specified value.

resource-reload-check-secs

The <resource-reload-check-secs> element is used to perform metadata caching for cached resources that are found in the resource path in the Web application scope. This parameter identifies how often WebLogic Server checks whether a resource has been modified and if so, it reloads it.

The value -1 means never reload.

The value 0 means always reload.

The default is 1 second.

Values specified for this parameter using the Admin Console are given precedence.

single-threaded-servlet-pool-size

The <single-threaded-servlet-pool-size> element defines the size of the pool used for SingleThreadMode instance pools. The default value is 5.

Note: SingleThreadMode instance pools are deprecated in this release.

session-monitoring-enabled

The <session-monitoring-enabled> element, if set to true, allows runtime MBeans to be created for sessions. When set to false, the default value, runtime MBeans are not created. A value specified in the console takes precedence over a value set manually.

save-sessions-enabled

The <save-sessions-enabled> element controls whether session data is cleaned up during redeploy or undeploy. It affects memory and replicated sessions. Setting the value to true means session data is saved. Setting to false means session data will be destroyed when the Web application is redeployed or undeployed. The default is false.

prefer-web-inf-classes

The <prefer-web-inf-classes> element, if set to true, will cause classes located in the WEB-INF directory of a Web application to be loaded in preference to classes loaded in the application or system classloader. The default value is false. A value specified in the console will take precedence over a value set manually.

default-mime-type

The <default-mime-type> element default value is null. This element allows the user to specify the default mime type for a content-type for which the extension is not mapped.

client-cert-proxy-enabled

The <client-cert-proxy-enabled> element default value is true. When set to true, WebLogic Server passes identity certificates from the clients to the backend servers. Also, WebLogic Server is notified whether to honor or discard the incoming WL-Proxy-Client-Cert header.

A proxy-server plugin encodes each identity certification in the WL-Proxy-Client-Cert header and passes it to the backend WebLogic Server instances. Each WebLogic Server instance takes the certificate information from the header, ensured it came from a secure source, and uses that information to authenticate the user. For the background WebLogic Server instances, this parameter must be set to true (either at the cluster/server level or at the Web application level).

If you set this element to true, use a weblogic.security.net.ConnectionFilter to ensure that each WebLogic Server instance accepts connections only from the machine on which the proxy-server plugin is running. If you specify true without using a connection filter, a potential security vulnerability is created because the WL-Proxy-Client-Cert header can be spoofed.

relogin-enabled

The <relogin-enabled> element is a backward compatibility parameter. If a user has logged in already and tries to access a resource for which s/he does not have privileges, a FORBIDDEN (403) response occurs.

allow-all-roles

In the security-constraints elements defined in web.xml descriptor of a Web application, the auth-constraint element indicates the user roles that should be permitted access to this resource collection. Here role-name = "*" is a compact syntax for indicating all roles in the Web application. In past releases, role-name = "*" was treated as all users/roles defined within the realm.

This allow-all-roles element is a backward compatibility switch to restore old behavior. The default behavior is to allow all roles defined in the Web application. The value specified in weblogic-xml takes precedence over the value defined in the WebAppContainerMBean.

native-io-enabled

To use native I/O while serving static files with weblogic.servlet.FileServlet, which is implicitly registered as the default servlet, set native-io-enabled to true. (The default value is false.) native-io-enabled element applies only on Windows.

minimum-native-file-size

The minimum-native-file-size element applies only when native-io-enabled is set to true. It sets the minimum file size for using native I/O. If the file being served is larger than this value, native I/O is used. If you do not set this value, the default value used is 4K.

disable-implicit-servlet-mapping

When the disable-implicit-servlet-mappings flag is set to true, the Web application container does not create implicit mappings for internal servlets (*.jsp, *.class, and so on); only for the default servlet mapping. A typical use case for turning off implicit servlet mappings would be when configuring HttpClusterServlet or HttpProxyServlet.

The default value is false.

optimistic-serialization

When optimistic-serialization is turned on, WebLogic Server does not serialize-deserialize context and request attributes upon getAttribute(name) when the request is dispatched across servlet contexts.

This means that you must make sure that the attributes common to Web applications are scoped to a common parent classloader (application scoped) or you must place them in the system classpath if the two Web applications do not belong to the same application.

When optimistic-serialization is turned off (default value), WebLogic Server serialize-deserializes context and request attributes upon getAttribute(name) to avoid the possibility of ClassCastExceptions.

The optimistic-serialization value can also be specified at domain level in the WebAppContainerMBean, which applies for all Web applications. The value in weblogic.xml, if specified, overrides the domain level value.

The default value is false.

monitoring-attribute-name

HTTP Sessions are identified with a monitoring ID. By default, the monitoring ID for a given HTTP session is a random string (not the same as a session ID for security reasons). This monitoring ID can be configured by setting the element in session-descriptor of the deployment descriptor and then setting a session attribute the defined . The of the session attribute value will then be used as a monitoring ID.

The element is useful for tagging session runtime information for different sessions. For example, you can set it to "username", if you have a "username" attribute that is unique.

The method returns an array of session attribute values with this name. If it is not set, it returns an array of randomly generated Strings.

 


charset-params

The <charset-params> element is used to define code set behavior for non-unicode operations. For example:

input-charset

Use the element to define which character set is used to read and data. For example:

For more information, see Determining the Encoding of an HTTP Request.

The following table describes the elements you can define within a element

Element

Required/
Optional

Description

Required

A path which, if included in the URL of a request, signals WebLogic Server to use the Java character set specified by .

Required

Specifies the Java characters set to use.

.

charset-mapping

Use the element to map an IANA character set name to a Java character set name. For example:

For more information, see Mapping IANA Character Sets to Java Character Sets.

The following table describes the elements you can define within a element

Element

Required/
Optional

Description

Required

Specifies the IANA character set name that is to be mapped to the Java character set specified by the element.

Required

Specifies the Java characters set to use.

.

 


virtual-directory-mapping

Use the virtual-directory-mapping element to specify document roots other than the default document root of the Web application for certain kinds of requests, such as image requests. All images for a set of Web applications can be stored in a single location, and need not be copied to the document root of each Web application that uses them. For an incoming request, if a virtual directory has been specified servlet container will search for the requested resource first in the virtual directory and then in the Web application's original document root. This defines the precedence if the same document exists in both places.

Example:

The following table describes the elements you can define within the virtual-directory-mapping element.

Element

Required/
Optional

Description

Required

Specifies a physical location on the disk.

<url-pattern>

Required

Contains the URL pattern of the mapping. Must follow the rules specified in Section 11.2 of the Servlet API Specification.

The WebLogic Server implementation of virtual directory mapping requires that you have a directory that matches the url-pattern of the mapping. The image example requires that you create a directory named images at c:/usr/gifs/images. This allows the servlet container to find images for multiple Web applications in the images directory.

 


url-match-map

Use this element to specify a class for URL pattern matching. The WebLogic Server default URL match mapping class is weblogic.servlet.utils.URLMatchMap, which is based on J2EE standards. Another implementation included in WebLogic Server is SimpleApacheURLMatchMap, which you can plug in using the url-match-map element.

Rule for SimpleApacheURLMatchMap:

If you map *.jws to JWSServlet then

http://foo.com/bar.jws/baz will be resolved to JWSServlet with pathInfo = baz.

Configure the URLMatchMap to be used in weblogic.xml as in the following example:

 


security-permission

The security-permission element specifies a single security permission based on the Security policy file syntax. Refer to the following URL for Sun's implementation of the security permission specification:

http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax

Disregard the optional codebase and signedBy clauses.

For example:

where:

permission java.net.SocketPermission is the permission class name.

"*" represents the target name.

resolve indicates the action.

 


context-root

The context-root element defines the context root of this stand-alone Web application. If the Web application is part of an EAR, not stand-alone, specify the context root in the EAR's META-INF/application.xml file. A context-root setting in application.xml takes precedence over context-root setting in weblogic.xml.

Note that this weblogic.xml element only acts on deployments using the two-phase deployment model.

The order of precedence for context root determination for a Web application is as follows:

  1. Check application.xml for context root; if found, use as Web application's context root.
  2. If context root is not set in application.xml, and the Web application is being deployed as part of an EAR, check whether context root is defined in weblogic.xml. If found, use as Web application's context root. If the Web application is deployed standalone, application.xml does not come into play and the determination for context-root starts at weblogic.xml and defaults to URI if it is not defined there.
  3. If context root is not defined in weblogic.xml or application.xmll, then infer the context path from the URI, giving it the name of the value defined in the URI minus the WAR suffix. For instance, a URI MyWebApp.war would be named MyWebApp.

Note: The context-root element cannot be set for individual Web applications in EAR libraries. It can only bet set for Web application libraries.

 


wl-dispatch-policy

Use the wl-dispatch-policy element to assign the Web application to a configured execute queue by identifying the execute queue name. This Web application-level parameter can be overridden at the individual servlet or jsp level by using the per-servlet-dispatch-policy element.

 


servlet-descriptor

Use the servlet-descriptor element to aggregate the servlet-specific elements.

The following table describes the elements you can define within the servlet-descriptor element.

Element

Required/
Optional

Description

Required

Specifies the servlet name as defined in the servlet element of the web.xml deployment descriptor file.

Optional

Contains the name of a principal against the run-as-role-name defined in the web.xml deployment descriptor.

Optional

Equivalent to run-as-principal-name for the init method for servlets. The identity specified here should be a valid user name in the system. If is not specified, the container uses the run-as-principal-name element.

Optional

Equivalent to run-as-principal-name for the destroy method for servlets. The identity specified here should be a valid user name in the system. If is not specified, the container uses the run-as-principal-name element.

Optional

This is a deprecated element. Used to assign a given servlet to a configured execute-queue by identifying the execute queue name. This setting overrides the Web application-level dispatch policy defined by wl-dispatch-policy.

 


work-manager

The element is a sub-element of the element. You can define the following elements within the element.

Element

Required
Optional

Description

name

Required

Specifies the name of the Work Manager.

response-time-request-class / fair-share-request-class / context-request-class / request-class-name

Optional

You can choose between the following four elements:

response-time-request-class—Defines the response time request class for the application. Response time is defined with attribute goal-ms in milliseconds. The increment is ((goal - T) Cr)/R, where T is the average thread use time, R the arrival rate, and Cr a coefficient to prioritize response time goals over fair shares.

fair-share-request-class—Defines the fair share request class. Fair share is defined with attribute percentage of default share. Therefore, the default is 100. The increment is Cf/(P R T), where P is the percentage, R the arrival rate, T the average thread use time, and Cf a coefficient for fair shares to prioritize them lower than response time goals.

context-request-class—Defines the context class. Context is defined with multiple cases mapping contextual information, like current user or its role, cookie, or work area fields to named service classes.

request-class-name—Defines the request class name.

min-threads-constraint, min-threads-constraint-name

Optional

You can choose between the following two elements:

min-threads-constraint—Used to guarantee a number of threads the server allocates to requests of the constrained work set to avoid deadlocks. The default is zero. A min-threads value of one is useful, for example, for a replication update request, which is called synchronously from a peer.

min-threads-constraint-name—Defines a name for the min-threads-constraint element.

max-threads-constraint, max-threads-constraint-name

Optional

You can choose between the following two elements:

max-threads-constraint—Limits the number of concurrent threads executing requests from the constrained work set. The default is unlimited. For example, consider a constraint defined with maximum threads of 10 and shared by 3 entry points. The scheduling logic ensures that not more than 10 threads are executing requests from the three entry points combined.

max-threads-constraint-name—Defines a name for the max-threads-constraint element.

capacity, capacity-name

Optional

You can choose between the following two elements:

capacity—Constraints can be defined and applied to sets of entry points, called constrained work sets. The server starts rejecting requests only when the capacity is reached. The default is zero. Note that the capacity includes all requests, queued or executing, from the constrained work set. This constraint is primarily intended for subsystems like JMS, which do their own flow control. This constraint is independent of the global queue threshold.

capacity-name—Defines a name for the capacity element.

 


logging

The element is a sub-element of the element. You can define the following elements within the element.

Element

Required
Optional

Description

log-filename

Required

Specifies the name of the log file. The full address of the filename is required.

logging-enabled

Optional

Indicates whether or not the log writer is set for either the ManagedConnectionFactory or ManagedConnection. If this element is set to true, output generated from either the ManagedConnectionFactory or ManagedConnection will be sent to the file specified by the log-filename element.

Failure to specify this value will result in WebLogic Server using its defined default value.

Value Range: true | false

Default Value: false

rotation-type

Optional

Sets the file rotation type.

Values are bySize, byName, none

  • bySize—When the log file reaches the size that you specify in file-size-limit, the server renames the file as FileName.n.

  • byName—At each time interval that you specify in file-time-span, the server renames the file as FileName.n. After the server renames a file, subsequent messages accumulate in a new file with the name that you specified in log-filename.

One thought on “Security-Role-Assignment Weblogic Server

Leave a Reply

Your email address will not be published. Required fields are marked *