| Oracle® Fusion Middleware Security Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) Part Number E14251-08 |
|
|
View PDF |
| Oracle® Fusion Middleware Security Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) Part Number E14251-08 |
|
|
View PDF |
This chapter discusses best practices, tips, and techniques for securing your portal deployment. While other chapters in this guide specifically deal with securing access to portal resources by adding entitlements, managing security providers, and setting up delegated administration, this chapter discusses additional steps you can take to secure your portal in a production environment, such as using firewalls, securing database connections, securing WSRP producers, and blocking access through non-HTTP protocols, such as RMI, EJB, and JNDI.
Tip:
WebLogic Server supplies RDBMS authentication providers including the SQL Authenticator, Read-only SQL Authenticator, and Custom RDBMS Authenticator. WebLogic Server also supplies authentication providers for external LDAP servers including Open LDAP, Sun iPlanet, Microsoft Active Directory, and Novell NDS LDAP servers, as well as its embedded LDAP server.
This chapter discusses the following security topics:
Section 3.3, "Securing the WebLogic Portal Administration Console"
Section 3.12, "Implementing Authentication Programmatically"
A simple security measure is to ensure that sensitive data, such as passwords or credit card numbers, are never stored in clear text.
Use a firewall to secure your portal software. A number of firewall options are available, from IP protocol filtering to content filtering. Each of these can provide a good starting point for securing your portal software.
You can obtain the best protection by using a two firewall solution. Place a firewall in front of WebLogic Server (or a certified WebLogic-supported server) and use a WebLogic-supported server plug-in. The plug-in communicates the portal software through another firewall. These firewalls can be configured to filter out all traffic except HTTP and HTTPS. In addition, the plug-in and WebLogic-supported server can be configured to perform two-way SSL between the plug-in and WebLogic-supported server.
Depending on the firewall it may be possible in some situations (non-encrypted) to filter the content of the packets that pass between the plug-in and the web server.
The drawback to this method is that both firewalls are filtering the same protocol; therefore, if an attacker can pass though the first firewall then they could pass though the second firewall as well. To mitigate this possible security hole, a certified secure version of a supported WebLogic web server can be used.
For more information on firewalls, see "Supported Web Servers, Browsers, and Firewalls" in "Oracle Fusion Middleware Supported System Configurations."
One of the simplest measures you can take is to secure the WebLogic Portal Administration console.
Table 3-1 Securing the Administration Console
| Security Action | Description |
|---|---|
|
Change the default user name and password. |
It is recommended that you use a different user name and password for portal administration than the ones used for administration of WebLogic Server. |
|
Do not deploy in production. |
If you do not have a reason to publicly deploy the Administration Console in your production environment, undeploy it or protect it behind your firewall. |
|
Use a WebLogic virtual host and network channel to restrict authorized access only from within a specific network. |
Configure the network channel to only listen on HTTPS and only on an internal network IP address. Configure the virtual host to use the network channel. Target the Administration Console only to the virtual host so that it is only be visible to users with access to the internal network IP address. See the WebLogic Server documents, "Virtual Hosts" and "Configure Custom Network Channels", in Oracle Fusion Middleware Oracle WebLogic Server Administration Console Online Help. |
In some extreme cases it may be beneficial to secure database communications. While not all drivers support such a mechanism a number of providers do provide encrypted communication to the database. This extra encryption does come with a heavy price in performance but is an option for the most security sensitive customers.
It is important to review the delegated administration and visitor entitlement policies before deploying a portal to a production environment. Delegated administration provides a mechanism for propagating WebLogic Portal Administration Console privileges within a hierarchy of roles. Visitor entitlements allow you to define who can access the resources in a portal application and what they can do with those resources.
Table 3-2 Reviewing Policies and Visitor Entitlements
| Security Action | Description |
|---|---|
|
Review the delegated administration policies. |
Be sure the delegated administration policies are configured the way you want them. It is recommended that you change the default group. For detailed information, see Chapter 7, "Configuring Delegated Administration.". |
|
Review visitor entitlements. |
Be sure to define entitlements for each portlet in the Library. Entitlements are a complicated subject and it is important to read the documentation and understand their configuration before deploying your portal. For detailed information, see Chapter 8, "Configuring Visitor Entitlements.". |
This section lists best practices for securing WebLogic Portal applications that use WSRP. For detailed information on WSRP security, see the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal.
Table 3-3 Securing WSRP Applications
| Security Action | Description |
|---|---|
|
For producer applications, protect the WSDL path, and all paths corresponding to the WSDL ports. |
The producer's WSDL should declare ports for HTTPS (SSL) service entry points only. For more information on WSDL, see the chapter "Federated Portal Architecture" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
Configure the producer and consumer to always require a security token. |
By default, a token is sent only when a user is authenticated. See the chapter "Establishing WSRP Security with SAML" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal for detailed information. |
|
When logging out on a consumer, always do the following:
|
These steps ensure all producer sessions are also terminated. |
|
Selectively offer portlets, books, and pages as remote. |
By default, all portlets deployed in a WebLogic Portal producer application are available to consumers as remote portlets. You can, however, specify which portlets are actually available to consumers by setting the Offer As Remote property in the Oracle Enterprise Pack for Eclipse Properties view for the portlet. Apply this same action to remoteable books and pages. For more information, see the chapter "Offering Books, Pages, and Portlets to Consumers" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
Use consumer entitlements. |
Consumer entitlement allows producers to decide which portlets to offer to consumers based on registration properties. For detailed information, see the chapter "Consumer Entitlement" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
When publishing portlets, books, or pages to a UDDI registry, use credential aliases instead of user name/passwords. |
For detailed information on publishing to UDDI registries, see the chapter "Publishing to UDDI Registries" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal |
|
Avoid using User Name Token (UNT). If you must, use UNT with password digest enabled. |
Username Token, or UNT, is an alternative to SAML and provides the same basic single sign-on capability as SAML provides. Username Token lets you map the local user on the consumer to a user on the producer. For detailed information, see the chapter "Configuring Username Token Security" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
Require signatures when using SAML. |
When configuring the Asserting Party properties on the producer, enable the Signatures Required property. This action requires all assertions to be signed. For more information, see the chapter "Establishing WSRP Security with SAML" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
Manage the keystore carefully. |
Generate your own keys in the keystore, and delete the default keys from the keystore. For detailed information, see the chapter "Establishing WSRP Security with SAML" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
Disable the WSRP SOAP monitor. |
You can monitor activity between producers and consumers by using the message monitor servlet installed with Oracle Enterprise Pack for Eclipse. For information on the monitor, see the chapter "Other Topics and Best Practices" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
|
Use a custom resource connection filter that retrieves only valid and known resources. |
By default, an unprotected resource can be retrieved from any known producer server. For more information, see the WebLogic Server section "Using Connection Filters" in Oracle Fusion Middleware Securing Oracle WebLogic Server. |
|
Disable the WSRP producer |
See "Disabling a WSRP Producer" in the Oracle Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal. |
Firewall the server so that all non-HTTP protocols are blocked. These include such protocols as JNDI, EJB, RMI, and T3.
This section includes tips on securing the content management system.
Table 3-4 Securing the Content Management System
| Security Action | Description |
|---|---|
|
Place entitlements on all content nodes that could contain sensitive data. |
For detailed information on entitling content nodes, see Section 8.16, "Setting Visitor Entitlements on Content Management Resources." |
|
Review delegated administration policies for the content management resources. |
Be sure the delegated administration policies are configured the way you want them for the content management resources. For more information, see Section 7.19, "Setting Delegated Administration on Content Management Resources." |
|
Secure the WebDAV API. |
Unified User Profile (UUP) allows you to store user-specific information. For detailed information on UUP and WebLogic Portal, see the chapter "Configuring a UUP" in the Oracle Fusion Middleware User Management Guide for Oracle WebLogic Portal.
Table 3-5 Securing UUP Data
| Security Action | Description |
|---|---|
|
Encrypt sensitive information stored as UUP data. |
If you intend to store sensitive information, such as credit card numbers, as UUP data, you must take measures to encrypt that data. I would repeat the general statement here: Tip: Never store passwords or sensitive data (like credit cards) in clear text. |
|
Avoid storing sensitive user profile information in the default profile store. Use UUP instead. |
Using UUP allows the data to be stored further back in the network stack. Sensitive customer data preexisting in protected repositories can be accessed only as needed through a custom UUP implementation. |
|
Protect UUP access methods. |
UUP access methods can be role protected through EJB method protection declaration in |
Configure application-scoped resources to further protect your portal system. To do this, you need to create JDBC Pool definitions in the portal application and reference them in the weblogic-application.xml configuration file. In addition to JDBC Pools, any JMS resources can also be application-scoped in the same manner.
For more information, see "Configuring JDBC Application Modules for Deployment" in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server. And see "Configuring JMS Application Modules for Deployment" in Oracle Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server.
This section explains how to secure the WebDAV web application. WebDAV is automatically deployed with your WebLogic Portal application.
Example 3-1 shows the default security constraint stanza found in the web.xml for the WebDAV web application WAR file, <WLPORTAL_HOME>\content-mgmt\lib\j2ee-modules\webdav-web-lib.war. To change the default security setting for WebDAV, you can change the default <role-name> attribute of the <auth-constraint> element to only allow members of a specific administrative role to have access to the WebDAV web application.
Tip:
WebLogic Server supplies RDBMS authentication providers including the SQL Authenticator, Read-only SQL Authenticator, and Custom RDBMS Authenticator. WebLogic Server also supplies authentication providers for external LDAP servers including Open LDAP, Sun iPlanet, Microsoft Active Directory, and Novell NDS LDAP servers, as well as its embedded LDAP server.
Example 3-1 WebDAV Configuration in web.xml
<security-constraint id="securityconstraint">
<web-resource-collection>
<web-resource-name>webdav</web-resource-name>
<description>Security constraint for webdav</description>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>AllAuthenticatedUsers</role-name>
</auth-constraint>
</security-constraint>
This section explains best practices and techniques for implementing login/logout functionality programatically. Sample code to handle login and logout in a JSP portlet is included in this section.
Redirecting after a login or logout prevents certain serious security problems, such as:
Receiving a previous user's session in a WSRP portlet.
Seeing previous form values show up in a new page.
Seeing the wrong portlet instance, such as a user instance after logout.
The recommended redirect techniques for commonly used portlet types are:
For JSP portlets, the best practice is to redirect and reload the portal after a log in or a log out operation using the portal framework's JspContentContext.sendRedirect() method. See Section 3.12.3, "Sample JSP Login/Logout Code."
For Struts portlets, use the JspContentBackingContext.sendRedirect() method to perform the redirect.
Note:
Avoid calling HttpResponse.sendRedirect() to perform the redirect in JSP and Struts portlets. The best practice is to always use the appropriate WLP mechanisms. See also Section 3.12.2, "Avoid Using JSP Tags for Login and Logout."
Note:
Apache Struts is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
For page flow portlets, the best practice is to perform the redirect by marking the forward from the login action with the redirect annotation. Another technique is to place the login/logout logic in the page flow Controller.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
For JSF portlets, you can call HttpResponse.sendRedirect() to perform the redirect. Be sure to obtain the response object from the ExternalContext, which functions as a request wrapper that ensures the portal takes the correct action.
The <auth:login> tag performs weak authentication (of the user name and password combination) against the current security realm, and sets the authenticated user as the current WebLogic user. The <auth:logout> tag ends the current user's WebLogic Server session.
Caution:
The use of these tags can lead to certain security problems because they are called after rendering has started. At the render phase of the portlet life cycle, it is impossible to apply the best practice of redirecting the portal, as explained in Section 3.12.1, "Always Redirect After Login or Logout." The redirect must be called during the handlePostbackData life cycle phase.
For more information on these tags refer to the Oracle Fusion Middleware JSP Tag Java API Reference for Oracle WebLogic Portal.
The sample code listed in this section demonstrates how to perform a log in and log out in a JSP portlet. Example 3-2 lists a backing file that uses the com.bea.p13n.security.Authentication helper class to perform log in and log out operations. This code also demonstrates the best practice of calling JspContentContext.sendRedirect() after a log in or a log out. See also Section 3.12.1, "Always Redirect After Login or Logout."
Example 3-3 shows a sample JSP that submits the user's name and password to the server. To use this JSP, create a portlet from it and add the backing file in Example 3-2 to the portlet.
Note:
The portal framework can only perform a redirect during the handlePostbackData phase of its life cycle; therefore, the authentication code is placed in the handlePostbackData() method of the backing file, as demonstrated in Example 3-2.
Example 3-2 Backing File That Performs Authentication
package examples.login;
import com.bea.netuix.servlets.controls.content.JspContentContext;
import com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking;
import com.bea.p13n.security.Authentication;
import com.bea.portlet.GenericURL;
import com.bea.portlet.PostbackURL;
import javax.security.auth.login.LoginException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class LoginBacking extends AbstractJspBacking {
private static final long serialVersionUID = 1L;
public static final String REDIRECT_ACTION = "redirect";
public boolean handlePostbackData(HttpServletRequest request, HttpServletResponse response) {
if (isRequestTargeted(request)) {
if (request.getParameter(GenericURL.STATE_PARAM) == null) {
String username = request.getParameter("username");
String password = request.getParameter("password");
PostbackURL url = PostbackURL.createPostbackURL(request, response);
if (username != null && password != null) {
try {
Authentication.login(username, password, request, response);
}
catch (LoginException le) {
request.setAttribute("loginErrorMessage3", new String("true"));
return false;
}
}
else if (request.getParameter("logout") != null) {
Authentication.logout(request);
}
url.addParameter(GenericURL.LOADSTATE_PARAM, "false");
url.addParameter(GenericURL.PAGE_LABEL_PARAM, "login");
try {
JspContentContext jspContext = JspContentContext.getJspContentContext(request);
jspContext.sendRedirect(url.toString());
}
catch (Exception ie) {
ie.printStackTrace();
}
}
}
return true;
}
}
Example 3-3 Sample Login JSP
<%@ page import="com.bea.portlet.WindowURL" %>
<h3 align="center">WebLogic Portal Login/Logout</h3>
<%
WindowURL url = WindowURL.createWindowURL(request, response);
if (request.getUserPrincipal() == null)
{
String errorMessage = (String) request.getAttribute("loginErrorMessage3");
%>
<form method="post" id="backingFileLoginForm" action="<%=url.toString()%>" type="POST">
<table border="0" width="100%">
<tr>
<td align="center" colspan="2">
<% if (errorMessage != null) { %>
<font color="red">Login failed. Please try again.</font><br>
<% } %>
Please enter your username and password below.<br>
</td>
</tr>
<tr>
<td align="right">
Username:
</td>
<td align="left">
<input type="text" size=15 name="username" >
</td>
</tr>
<tr>
<td align="right">
Password:
</td>
<td align="left">
<input type="password" size=15 name="password" >
</td>
</tr>
<tr>
<td colspan="2" align="center">
<input type="submit" value="Login">
</td>
</tr>
</table>
</form>
<%
}
else
{
%>
<form method="post" id="backingFileLoginForm" action="<%=url.toString()%>" type="POST">
<table border="0" width="100%">
<tr>
<td align="center">
<b><%=request.getUserPrincipal().getName()%></b>, Welcome to WebLogic Portal!
</td>
</tr>
<tr>
<td align="center">
<input type="hidden" name="logout" value="1">
<input type="submit" value="Logout">
</td>
</tr>
</table>
</form>
<%
}
%>
By default, WLP adds a security token to URLs generated by WLP. This feature is designed to prevent certain kinds of malicious eavesdropping attacks. A security token is a WLP-generated token that is appended to the end of WLP-generated URLs. The token encodes the user name of the logged in user and a time stamp. Any URLs posted back to the WLP server without the correct token will be rejected.
Security tokens are enabled by default. You can enable or disable the security token feature by adding the following XML to the WEB-INF/netuix-config.xml file.
<security-token>
<enable>true</enable>
<security-token-spi-class>com.bea.netuix.security.SecurityTokenManagerImpl
</security-token-spi-class>
<security-token-parameter-name>fooToken</security-token-parameter-name>
</security-token>
To turn off the security token feature, set <enable> to false.
The optional <security-token-parameter-name> element allows you to specify the name of the security token parameter. If you don't specify it, the default of _st is used as the parameter name.
You can write your own implementation of the SecurityTokenManger interface if you wish. A custom implementation could, for example, use something other than the user name and timestamp to produce the token. Refer to the Javadoc (Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal) for information on this interface.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|