Securing sensitive data using SSL in Websphere Portal

Portal administrators and developers learn an approach for securing personal information on selected portal pages.

Greg Herringer (gherring@ca.ibm.com), IT Architect, IBM

Greg Herringer photoGreg Herringer is an IT Architect with 15 years experience in Customer Relationship Management and Contact Center technologies, with focus on the financial services and public sector industries. He has a wide variety of experience across the entire application development life cycle.



Zaman Valli-Hasham (zamanv@ca.ibm.com), IT Specialist, IBM

Zaman Valli-Hasham photoZaman Valli-Hasham is an IT Specialist with the Pacific Development Centre in Burnaby, British Columbia. He has experience in a variety of areas including web casting, Web development, and application development. Recently, he has been working in WebSphere deployment management and infrastructure configuration.



22 November 2005

Also available in Japanese

Introduction

A highly interactive and useful Web site delivers optimal value when the user experience can be enhanced through personalization. Most users have come to expect that any personal data provided to a Web site will be transmitted through secure means. IBM WebSphere Portal is an excellent platform on which to enable a content rich Web site; however, selectively securing specific pages (using SSL) is not a straight-forward task.

This article describes the approach taken on a recent WebSphere Portal deployment project to secure specific pages on the portal that collect and display personal information about the user. Portal administrators and developers might be able to use this technique for your WebSphere Portal deployment.

This article assumes the reader is familiar with Websphere Portal, Websphere Application Server, and IBM HTTP Server administration tools, which are required to deploy the configuration described below.


Deployed portal architecture

A recent project for a company in the travel and leisure industry resulted in a highly functional and content rich Web site based on WebSphere Portal. Figure 1 illustrates the components that were deployed or integrated to support the portal implementation.

Figure 1 Architectural overview of the portal
Figure 1 Architectural overview of the portal

The solution included these IBM products:

Table 1. IBM products in the architecture
ProductDescription
WebSphere Edge ServerLoad balancing component. Distributes incoming requests for portal pages.
IBM HTTP Server V1.3Web server responsible for serving the content.
WebSphere Portal V5.0.2The user experience engine for site content, navigation, look-and-feel, access to third party sites, and access to Siebel via the Siebel Java Data Bean.
WebSphere Application Server V5.0.2J2EE application server on which WebSphere Portal runs.
IBM Directory Server V5.1LDAP server. Stores site user and administrative credentials for WebSphere Portal.
Lotus Workplace Web Content Management V1.1Content management component. Supports editing of content and, through WebSphere Portal portlets, display of content to site users.
Tivoli Site Analyzer V4.5Provides site usage metrics and reports to the site owner.
DB2 V8.1Relational database. Stores content and other site-related assets.
WebSphere MQSupports XML message exchange between the portal and the legacy application.

Together these products produce an engaging Web site experience and support transactions including site registration, profiling for travel and vacation preferences, and online purchasing of travel and related products. A key feature of the site is the ability for the site owner to use the personal profile data to tailor content display based on marketing campaigns targeted for the specific site user.

The capture and display of personal profile data, in addition to the capture of purchasing details for online transactions, requires that some portal pages be secured using SSL. Because most of the site’s pages provide content available to both anonymous and registered users, enabling the entire portal for SSL was not considered a practical alternative.


The challenge

The challenge for the design team was to prepare an approach for securing the sensitive data in the portal that met the following criteria:

  1. Only pages that request or display sensitive data are secure.
  2. A secure page will always display as a secure page, regardless of the method used to navigate to it.
  3. A secure page will always display as secure, regardless of the state of the portlet that contains the embedded Web application.
  4. Errors or results generated on a secure page will also display as a secure page.
  5. Navigating from a secure page to an unsecured page on the portal will not render the unsecured page in a secure session.
  6. The user will recognize the page as secure because the browser will indicate so with the familiar lock symbol (or equivalent).
  7. The approach will be easy to maintain and be extensible for future site enhancements and upgrades.

The solution

After some research and experimentation, the design team developed an approach that met the above criteria. We modified the following components in the following ways:

  1. SSL-enabled the IBM HTTP server so that SSL traffic could travel from the Web servers to WebSphere Portal.
  2. Configured WebSphere Portal to accept SSL traffic.
  3. Defined a protected subset of pages in WebSphere Application Server.

We'll walk you through those same modifications so you can see how you might apply this type of solution in your own environment.

Enabling SSL on IBM HTTP Server

This section outlines the steps that you would follow for SSL enabling IBM HTTP Server.

  1. Make a backup of the httpd.conf file found in IHS_HOME/conf.
  2. Edit the httpd.conf file. Add the entry below all of the pre-existing Load Module entries to load the IBM SSL module:
    LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll

    This entry causes IBM HTTP Server to initialize the SSL module code the next time it starts up. If the module is not properly initialized, IBM HTTP Server will have problems interpreting all SSL-related lines in the httpd.conf file.

  3. At the end of the httpd.conf file add:
    Listen 443
    <VirtualHost <fully qualified machine name>:443>
          Keyfile <location of keyfile.kdb>
          SSLEnable
          SSLClientAuth 0
    </VirtualHost>

    In the httpd.conf file, Listen entries specify ports on which the Web server monitors traffic. By adding the entry Listen 443, you tell IBM HTTP Server to allow content from port 443 to be served and displayed to the user.

    Important: Port 443 is the default SSL port.

A VirtualHost lets you configure a single machine to resemble multiple host machines, where each host has a logical name and a list of one or more DNS aliases by which it is known. By adding the entry <fully qualified machine name>:443, you enable the machine to serve secure content from port 443 and to differentiate this content from that served on port 80 (that is, you can use both at the same time). Make sure that the keyfile path is valid. If the keyfile path does not exist, create the necessary directory structure in order for IBM HTTP Server to be able to find the file. The SSLEnable and SSLClientAuth entries complete the SSL enablement.

Creating a certificate

Now that you have enabled IBM HTTP Server to serve SSL content on port 443, you need to either import a signed certificate or create a new personal certificate using the Key Management Utility. The example below walks through the process of creating a self-signed personal certificate.

For instructions on importing certificates, see the IBM HTTP Server product documentation. From the Windows Start menu, select Start => IBM HTTP Server => Start Key Management Utility.

  1. From the Key Database File menu, select New.

    The key database type is CMS keydatabase file and the filename is the Keyfile you used in Step 3. In this example, we use the name keyfile.kdb. Make sure that the location entry coincides with the one referenced in step 3 above, and that the path exists on the file system.

  2. Click OK to continue.
  3. Type in a password, and remember this password because you will need it later!
  4. Click the option to Stash the password to a file, which encodes the password and saves it to a flat file stored on the file system with the extension .sth. When the server starts, it automatically reads the encoded password from the .sth file without prompting the user to enter it.
  5. Click OK. This message displays.
  6. Click OK to close the message box.
  7. Create a new self-signed certificate. Select Create => New Self-Signed Certificate.

    The Create New Self-Signed Certificate window displays.

  8. Complete the required fields:
    Key Label
    <machine name>. In the screenshot above the machine name is c040
    Version
    X509 V3
    Key Size
    1024
    Common Name
    <fully qualified machine name>. In the screenshot above the fully qualified machine name is c040.vancouver.can.ibm.com
    Organization
    <name of your organization>. In the screenshot above the organization is IBM
    Country
    <country>. In the screenshot above the country is US.
    Validity Period
    In the screenshot above we chose 365 Days.

    Make sure that the Common Name matches the hostname in the URL. If these two entries do not match, you will not be able to serve SSL content.

    Congratulations! You have successfully SSL-enabled IBM HTTP Server on port 443, and created a certificate.

    There are two more steps to complete before you can test the implementation.

  9. Open a command line session and browse to the IHS_HOME or HTTP Server Installation directory (C:/WebSphere/HTTPServer in our example). Type in this command to ensure there are no syntactical errors in the httpd.conf file:
    apache –t

    You should get one of these results:

    • If the syntax in the file is correct, the result will be:
      [C:/websphere/httpserver/conf/httpd.conf: Syntax OK.

      Of course, the location of the httpd.conf file depends on the location of the HTTPServer install.

    • If there are errors or warnings, the result will be:
      [date and time]  [error or warn] [error listing] [action taken]

      For example (on one line normally):

      [Tue Nov 22 16:08:16 2005] [error] Cannot resolve host name 
         www.c040.vancouver.can.ibm.com --- ignoring!

    We recommend that you resolve all errors and warnings prior to testing the SSL configuration. If the system has been running with errors and warnings for some time prior to the SSL implementation, they will be reported at this time, even though they were not caused by the configuration changes required to implement SSL.

  10. Restart IBM HTTP Server to reload the httpd.conf file with the new SSL enablement settings.
  11. In order to test, open this address in a Web browser:
    https://<fully qualified machine name>

    You should see this security alert:

  12. Click Yes to proceed. If you see the Welcome to IBM HTTP Server window (shown below), you have successfully SSL-enabled your server.

If you are unable to serve up content, please check the configuration changes you made earlier.

Enabling Websphere Portal to accept SSL

In the previous section, you enabled the IBM HTTP Server to serve SSL-enabled content on port 443. In this section, you see how to enable WebSphere Portal to accept SSL.

  1. Open the WebSphere Application Server Administrative console by browsing to:
     https://<fully qualified machine name>:9043/admin/logon.jsp
  2. Click the Environment link in the left column, and then click the Virtual Hosts link on the left side to display the following:

    In the same way you have configured IBM HTTP Server to act as multiple host machines, configuring Virtual Hosts in WebSphere Application Server lets you configure a single machine to resemble multiple host machines where each host has a logical name and a list of one or more DNS aliases by which it is known.

  3. In this example, we work with the default host, so click the checkbox next to the default host entry, and then select the New button. In this example, the hostname is the same regardless of the type of content to be served, so use * for hostname. Similarly, since we are using the default SSL port, we can use 443 as the value for port. Click the Apply button.
  4. On the Save Changes page, click the Save button inside the Save to Master Configuration box.

    You have just successfully configured WebSphere Portal Server to serve SSL content. Before continuing, you need to modify the Web Server plugin.

  5. Click on the Update Web Server Plugin link on the left side and then click OK to regenerate the plugin file.

    Important: If you have made any manual changes to your plugin file, do NOT regenerate the file because it will overwrite your custom code. In this situation, you need to make any changes to the plugin file manually. In our case, we had made some manual changes to the plugin file to mask the machine name and port for a backend Web Content Management server, so we did not regenerate the file using the WebSphere Application Server Administrative Console.

    To make the changes manually:

    1. Make a backup of the existing plugin-cfg.xml file found in WAS_HOME\config\cells.
    2. Regenerate the plugin file using the instructions above.
    3. Use a comparison tool to compare the backup you created and the newly created file, and manually make any changes required to restore the desired functionality from the previous manual changes.
    4. Save all configuration changes and close the WebSphere Application Server Administrative Console.
  6. Whether you generate the file automatically or you use the manual procedure (in the previous step), open the plugin-cfg.xml file and check to ensure that the <VirtualHost Name="*:443"/> entry looks like the highlighted one here:

    This entry adds the 443 Virtual Host to WebSphere Application Server.

    Before testing serving SSL content, you need to restart both IBM HTTP Server and WebSphere Portal Server to reload the SSL capabilities that have been added. You see how to do this in the next couple of sections.

Restarting the IBM HTTP Server

Stop and then re-start the IBM HTTP server can using the Windows Services panel, as shown below.

Restarting WebSphere Portal

By default, WebSphere Portal Server is not configured to run as a Windows Service. If you have configured your installation to run as a Windows Service, you can stop and restart the server using the Windows Services panel.

Otherwise, start and stop WebSphere Portal Server using the default method; that is, by entering commands on the command line.

From the WPS_HOME\bin directory, stop WebSphere Portal with the command:

stopserver WebSphere_Portal –user <username> -password <password>

Start WebSphere Portal with the command:

startserver WebSphere_Portal

Testing basic SSL functionality

Open a browser window and browse to the SSL-enabled implementation of your portal implementation:

https://<fully qualified hostname>/wps/portal

The security alert shown below displays if you are using a self signed certificate. However, you will not see this warning if you use an industry standard certificate.

Check that the last condition, The security certificate has a valid name matching the name of the page you are trying to view, has a green checkmark associated with it.

A yellow exclamation mark next to the first condition (as shown), indicates that the common name you entered during IBM HTTP Server SSL enablement does not match the hostname of the machine.

Click Yes to close the warning window. If the WebSphere Portal homepage displays correctly, you are done! If not, please confirm that all previous steps done to this point were successful. For help with troubleshooting, contact IBM Support (1-800-IBM-SERV, in the US).

Modifying the portal theme to use absolute links

Once you have successfully completed the enablement task (as described in the previous sections), the portal can serve up any or all pages through SSL. As we stated in The challenge of this paper, the goal of this project was to have the flexibility to secure a small number of pages that contain customer sensitive information without the operational overhead of having to SSL-enable every page. A by-product of restricting SSL encryption to specific pages is that the burden of managing the navigation between secured and unsecured pages falls on the Web site developers. If relative links were used, as in the default used by WebSphere Portal, SSL encryption remains in effect when browsing from secured to non-secured pages until the session ends.

Prior to indicating to WebSphere Application Server which specific pages are SSL-enabled, we needed to modify the portal theme to use absolute links (links that included http:// or https://). Then, users could navigate between secured and non-secured pages without breaking the security model. With Version 5.1 of WebSphere Portal, you can configure the product to use absolute links throughout the site by modifying a single property file. However, we used WebSphere Portal Server 5.0.2 which we does not have this capability.

The WebSphere Portal theme is in this directory:

WAS_HOME\installedApps\<machine name>\wps.ear\wps.war\themes

The themes folder contains chtml, html, and wml folders, which correspond to a version of the theme for each markup .

To ease maintainability, the snippet of code below builds the part of the link missing from the default WebSphere Portal relative URLs.

String serverName = request.getServerName();
int portNumber = request.getServerPort();
String preURL = "http://" + serverName;
if (portNumber == 9081) {
	preURL = preURL + ":" + portNumber;

This function allows you to simply pre-pend preURL to all of the default relative links to create the absolute links required. There are many different approaches to solving this issue--just be sure your solution creates absolute URLs.

Indicating which pages to SSL-enable

After modifying the portal theme, you make these changes to enable WebSphere Application Server to SSL-enable specific pages.

  1. Browse for the file:
    WAS_HOME\config\cells\<machine name 
    	  or cluster name>\applications\wps.ear\deployments\wps\wps.war\WEB-INF\web.xml

    Assuming you have successfully implemented and tested the SSL functionality, there should be an entry in the file that looks like the following:

    <security-constraint id="SecurityConstraint_XXXXXXXXXXXXX">
    <web-resource-collection id="WebResourceCollection_XXXXXXXXXXXXX">
                <web-resource-name>secure</web-resource-name>
             <http-method>GET</http-method>
                <http-method>POST</http-method>
    </web-resource-collection>

    The <web-resource-name>secure</web-resource-name> entry enumerates the secure pages that WebSphere Portal Server should serve using SSL.

  2. In order to enumerate specific pages, you need to specify each URL pattern in this file.

    For example:

    <web-resource-name>secure</web-resource-name>
    <url-pattern>
           /portal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_S5/_s.7_0_A/7_0_S5
    </url-pattern>

    specifies that the URL, as specified inside the <url-pattern> </url-pattern> pair, should be served using SSL. In the example above, the URL specified is a non-authenticated page, but you use a similar strategy for authenticated pages.

    For example:

    <url-pattern>
           /portal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_S5/_s.7_0_A/7_0_S5
           /myportal/!ut/p/.cmd/cs/.ce/7_0_A/.s/7_0_S5/_s.7_0_A/7_0_S5
    </url-pattern>

    The example above shows how to specify that both the authenticated and non-authenticated versions of the page should be served over SSL. Use this as a template to enumerate each secure page.

  3. After enumerating each secure page using the procedure above, restart WebSphere Application Server and WebSphere Portal.
  4. Test the implementation by browsing to a secure page or entering its URL into the Web browser and confirm that you are redirected to a secure page. As a reminder, secure pages are easily recognizable by a lock (or other equivalent) in the lower right hand corner of the browser.

    Important: If you are working in a clustered WebSphere Portal environment, you need to modify the web.xml file on each node of the cluster. The file is found in:

    WAS_HOME\config\cells\<cluster name>\applications\wps.ear\deployments\
                 wps\wps.war\WEB-INF\web.xml

    There could be several items found under the cells directory, but you are only concerned with the clustered one.

  5. Restart each node, using the stopserver and startserver commands described earlier, and test the implementation. It is a good idea to test all of the pages on each of the individual cluster nodes to ensure they are served up securely. This can be achieved by locally using the Web browser located on each of the WebSphere Portal Server cluster nodes.

Conclusion

In summary, the team learned the following about securing specific pages in a Websphere Portal deployment.

  1. Securing specific portal pages is possible. The team proved that securing a Websphere Portal implementation does not have to be an all or nothing decision. The techniques described above allowed the team to secure specific pages to meet the customer’s security requirement in an efficient and maintainable manner.
  2. Securing specific portal pages requires custom configuration. As described above there are a fair number of steps required to secure specific portal pages. If there are many pages to secure or if the customer will be adding secure pages frequently then it may be simpler to secure the full portal.
  3. Identify secure pages during user interface design. Establishing a list of pages to secure during the user interface design phase can facilitate configuration planning, testing and deployment. If this activity is delayed in the project timeline, there may be reconfiguration and retesting required.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=99147
ArticleTitle=Securing sensitive data using SSL in Websphere Portal
publish-date=11222005