Security Guide

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Securing Your Portal Deployment

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: The information in this chapter is specific to WebLogic Portal. Before continuing, we recommend you read the WebLogic Server document, Securing a Production Environment for detailed information on securing your WebLogic Server installation.

This chapter discusses the following security topics:

 

Encrypting Sensitive Information

A simple security measure is to ensure that sensitive data, such as passwords or credit card numbers, are never stored in clear text.

 

Using Firewalls

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.”

 

Securing the WebLogic Portal Administration Console

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.”

 

Securing Database Communications

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.

 

Reviewing Policies and Visitor Entitlements

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 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 Configuring Visitor Entitlements.

 

Securing WSRP Applications

This section lists best practices for securing WebLogic Portal applications that use WSRP. For detailed information on WSRP security, see the Federated Portals Guide.

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 Federated Portals Guide.
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 Federated Portals Guide for detailed information.
When logging out on a consumer, always do the following:
  • Terminate the session
  • Enable destroySessions support
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 Workshop for WebLogic 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 Federated Portals Guide.
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 Federated Portals Guide.
When publishing portlets, books, or pages to a UDDI registry, use credential aliases instead of username/passwords.
For detailed information on publishing to UDDI registries, see the chapter “Publishing to UDDI Registries” in the Federated Portals Guide.
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 Federated Portals Guide.
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 Federated Portals Guide.
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 Federated Portals Guide.
Disable the WSRP SOAP monitor.
You can monitor activity between producers and consumers by using the message monitor servlet installed with Workshop for WebLogic. For information on the monitor, see the chapter “Other Topics and Best Practices” in the Federated Portals Guide.
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.”
Disable a WSRP prodcuer.
See “Disabling a WSRP Producer” in the Federated Portals Guide.

 

Blocking Non-HTTP Protocols

Firewall the server so that all non-HTTP protocols are blocked. These include such protocols as JNDI, EJB, RMI, and T3.

 

Securing the Content Management System

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 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 Setting Delegated Administration on Content Management Resources.
Secure the WebDAV API.
See Securing WebDAV Web Application.

 

Securing UUP Data

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 User Interaction Management Guide.

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 ejb-jar.xml.

 

Application-Scoping Resources

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” and “Configuring JMS Application Modules for Deployment.”

 

Securing GroupSpace Applications

This section explains how to prevent users from creating new GroupSpaces from within GroupSpace. The ability of members to create new GroupSpaces from within GroupSpace is controlled by the community role (the admin designation of your community capability). For more information on community roles and capabilities, see the WebLogic Portal Communities Guide.

Specified in the communities-config.xml file, the following kind of member can access the administration tools to create a new GroupSpace from within another GroupSpace: 

<capability>
     <name>manager</name>
     <display-name>Manager</display-name>
     <admin>true</admin>
 </capability>

The following kind of member cannot: 

<capability>
     <name>memberuser</name>
     <display-name>Member User</display-name>
 </capability>

You can check the admin capability of any member with the code in Listing 3-1:

Listing 3-1 Checking the Admin Capability of a GroupSpace Member 
CommunityContext cc = CommunityContext.getCommunityContext(request);
CommunityUserContext userContext = communityContext.getCommunityUserContext();
CommunityMember thisMember = userContext.getMember();
CommunityMembership membership = userContext.getMembership(thisMember.getId(),   cc.getCommunity().getCommunityDefinitionId());
if(membership.hasAdminCapability())
{
    ...
}

 

Securing WebDAV Web Application

This section explains how to secure the WebDAV web application. WebDAV is automatically deployed with your WebLogic Portal application.

Listing 3-2 shows the defatul 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: It is recommended that you use a deployment plan to modify the default security constraint in web.xml settings. See the Production Operations Guide for information on using deployment plans.
Listing 3-2 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>

 

Implementing Authentication Programmatically

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.

Always Redirect After Login or Logout

Redirecting after a login or logout prevents certain serious security problems, such as:

The recommended redirect techniques for commonly used portlet types are:

Avoid Using JSP Tags for Login and Logout

The <auth:login> tag performs weak authentication (of the username 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.

WARNING: 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 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 JSP Tag Javadoc.

Sample JSP Login/Logout Code

The sample code listed in this section demonstrates how to perform a log in and log out in a JSP portlet. Listing 3-3 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 Always Redirect After Login or Logout.

Listing 3-4 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 Listing 3-3 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 Listing 3-3.
Listing 3-3 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;
   }
}
Listing 3-4 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>
<%
}
%>

  Back to Top       Previous  Next