![]() |
![]() |
e-docs > WebLogic Server > Assembling and Configuring Web Applications > Configuring Security in Web Applications |
Assembling and Configuring Web Applications
|
Configuring Security in Web Applications
The following sections describe how to configure security in Web Applications:
To see overview, upgrade, and new information about WebLogic Server security, see Security.
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.
On application deployment, WebLogic Server reads role information from the weblogic.xml file. This information is used to populate the Authorization provider configured for the security realm. Once the role information is in the Authorization provider, changes made through the WebLogic Server Administration Console are not persisted to the weblogic.xml file. Before you redeploy the application (which will happen when you redeploy it through the console, modify it on disk, or restart WebLogic Server), you need to enable the Ignore security data in deployment descriptors attribute on the Security Realm --> General tab. Otherwise, the old data in the weblogic.xml file will overwrite any changes made through the WebLogic Server Administration Console.
To set up authentication for Web Applications:
<input type="password" name="j_password">
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.
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 jsp-descriptor.
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 3, 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.
Restricting Access to Resources in a Web Application
To restrict access to specified resources (servlets, JSPs, or HTML pages) in your Web Application, apply security constraints to those resources.
To configure a security constraint:
Alternatively, to apply the security constraint to the entire Web Application, use the following entry:
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>
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |