Portal, Express Beta Version 6.1 Operating systems: i5/OS, Linux,Windows

Set up SSL

This section describes the overall tasks that are required to configure SSL for IBM^® WebSphere^® Portal Express. Some of these tasks are performed on the IBM WebSphere Application Server and the Web server. The steps that refer to the WebSphere Application Server and the Web server are summarized here; you should refer to the WebSphere Application Server and the Web server documentation for more detailed information. Steps that are unique to WebSphere Portal Express are described in detail here.

1. Configure the Web server to support HTTPS. This involves setting up the Web server to accept inbound connections from client browsers over SSL. The Web server must have a port defined (usually 443), and the necessary certificates and keys must be installed. Go to Set up the Secure Sockets Layer protocol for information on how to enable SSL on an IBM HTTP Server.

   If this is a production environment, obtain a certificate from a certificate authority. For testing purposes, you can use IKEYMAN to generate a self-signed certificate. Refer to the Managing digital certificates section of the WebSphere Application Server information center.

   For Internet Information Server, create SSL keys by using the Web server's Version 6.0 resource tool kit.

2. Configure the WebSphere Application Server plugin for the Web server to forward WebSphere Portal Express traffic that is received over SSL to WebSphere Application Server (which will then forward the traffic to WebSphere Portal Express ). Go to Configuring the Web server plug-in for Secure Sockets Layer for information on how to configure the plug-in. This topic discusses the configuration for the IBM HTTP Server; however, the Web server-related configuration in this situation is not specific to any distributed platform Web server.
3. In configurations where the Web server and WebSphere Portal Express reside on separate machines, requests to the Web server are rerouted to the application server. Under these circumstances, you can also configure SSL between the Web server and the application server to provide more complete security. This requires that you create additional keyfiles for the Web server plugin and for the embedded HTTPS of WebSphere Application Server. For detailed instructions on configuring SSL between the Web server and the application server, refer to the section entitled 7.3.1: Secure the transport channel between Web server and WebSphere, of the IBM WebSphere Application Server V6.1 Security Handbook, SG24-6316-00. Note: Always create a new SSL repository for the external Web server and change the WebSphere_Portal server's secure transport channel to use the new SSL repository. Do not modify the default SSL repository.
4. Add or change the following two property parameters in configuration services, as described in Setting configuration properties:

       redirect.login.ssl = true
       host.port.https = alias_port

   where alias_port is the port number that is used for the virtual host alias that is specified in a previous step (usually 443). The parameter redirect.login.ssl determines the protocol that is used when you click the login button. If this parameter is set to true, https is used. If this parameter is set to false, http is used. This setting is not affected by the protocol that is used to access the main page.

5. Use the following steps to update transport security constraints and themes:

   Theme JSPs and deployment files are managed as part of the main application and are thus part of the EAR file. You must update and redeploy EAR files when changing JSPs or deployment related xml files; otherwise, your changes will be deleted when the EAR file is updated. See Deploying themes and skins in a production environment for information on updating and redeploying the EAR file with modified settings.

   1. Export the WebSphere Portal Express EAR file and use the EARExpander tool of WebSphere Application Server to expand the contents of the exported EAR file; see the first two steps in Deploying themes and skins in a production environment.
   2. Update the Transport Security Constraint.

      This step is only required if you need to completely secure the portal protected area over HTTPS. You can modify the transport guarantee so that WebSphere Application Server will enforce the use of SSL for all pages under the /myportal/ URL.

      Edit web.xml file in the directory/wps_expanded/wps.war/WEB-INF/web.xml directory. Change the security-constraint tag of the protected URL, /myportal/*, to use HTTPS by setting each occurrence of the transport guarantee value of 'NONE' to 'CONFIDENTIAL':

            <security-constraint id="SecurityConstraint_1">
               <web-resource-collection id="WebResourceCollection_1">
                  <web-resource-name></web-resource-name>
               
               <url-pattern>/myportal/*</url-pattern>
      				
      				
      			<http-method>DELETE</http-method>
                  <http-method>POST</http-method>
                  <http-method>GET</http-method>
                  <http-method>PUT</http-method>
               </web-resource-collection>
               <auth-constraint id="AuthConstraint_1">
                  <description></description>
                  <role-name>All Role</role-name>
               </auth-constraint>
               <user-data-constraint id="UserDataConstraint_4">
                  <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
                  // replace NONE by CONFIDENTIAL
               </user-data-constraint>
            </security-constraint>

   3. Follow these steps to update themes:

      1. Edit the JSP and JSPF files that provide the login link. You can search the theme directories under directory/wps_expanded/wps.war/themes/ for all JSP and JSPF files that include the following string:

         "wps.Login"

         This attribute should appear in a tag similar to this:

                     <wps:urlGeneration contentNode="wps.Login" 
                                       portletWindowState="Normal">

         The exact structure of this tag can vary depending on how it was constructed by the page designer. JSP comments might also be used to indicate where the login link is located:

               <%-- login button --%>

      2. After finding the login link, change or add the ssl="true" attribute to the <wps:urlGeneration> tag of the anchor, for example:

         <wps:if loggedIn="no" notSelection="wps.Login">
          <wps:urlGeneration contentNode="wps.Login" 
                     portletWindowState="Normal" ssl="true">
           <td class="wpsToolBar" valign="middle" nowrap>
            <a href="<% wpsURL.write(escapeXmlWriter); %>" class="wpsToolBarLink">
            <wps:text key="link.login" bundle="nls.engine"/>
            </a>
           </td>
          </wps:urlGeneration>
         </wps:if>

         Note: The previous examples use the 'wps:' prefix to designate JSP tags from the portal tag library in portal.tld. Your custom JSPs might use a different tag prefix.
   4. Use the EARExpander command to collapse the directory back into the EAR file and update the WebSphere Portal Express EAR file through the wsadmin tool; see steps 4 through 6 in Deploying themes and skins in a production environment. Note: If this is a clustered environment, verify that the EAR changes have synchronized to all nodes. Restart the servers on each node.
6. When using a remote Web server in a standalone or clustered environment, perform the following steps if one of the following scenarios is true:

   • If you need to allow direct access to the WebSphere_Portal node on the internal port, for example http://www.ibm.com:10040/wps/portal, you will need to create a Webcontainer Transport chain and specify the virtual host alias port (usually 443).
   • If this is a clustered environment, you will need to make this update on each WebSphere_Portal node in the cluster.

   1. From the WebSphere Application Server Administrative console go to Servers > Application Servers > WebSphere_Portal > Web Container Settings > Web Container Transport Chains.
   2. Click New.
   3. Select a name for the transport chain.
   4. Select the WebContainer-Secure template (templates/chains|webcontainer-chains.xml...).
   5. Select Next.
   6. Specify the Port name; for example 443.
   7. Specify the Port number, usually 443.
   8. Click Next.
   9. Click Finish to confirm the creation of the transport chain.
   10. Click Save.
   11. If this is a clustered environment, synchronize the changes to all nodes.
7. Perform the following steps only if using the Login portlet:

   1. The Login portlet uses the UseSecureLoginActionUrl parameter to control the generation of the login action URL. Set this parameter to true to use a secure URL for login.
   2. Use the Portlets administration portlet to do the following:

      • Go to Administration > Portlet Management > Portlets.
      • Search for Title start with = "Login".
      • Select the Configure portlet icon.
      • Edit UseSecureLoginActionUrl parameter and set the parameter to true.
8. Follow these steps to test your changes:

   1. Launch the home page in a Web browser through an HTTP URL that is not secure (for example, http://hostname.example.com:10040/wps/portal, where hostname.example.com is the fully qualified host name of the machine where WebSphere Portal is running and 10040 is the default transport port that is created by WebSphere Application Server.).
   2. Verify that the login link in the banner area uses the HTTPS schema for the link to the login page.
   3. Go to the login screen and verify that this page is already protected; the URL must be HTTPS and the browser must indicate that the page is protected. Note: A browser security prompt might appear after you click the login link to accept the server certificate.
   4. Log off.
   5. Log in using an HTTP URL that is not secure and that points directly to the protected area (for example, http://www.ibm.com:10040/wps/portal).
   6. Verify that you are requested to login and that the login page and the portal page afterwards are protected through SSL. Note: If the security-constraint has not been modified to CONFIDENTIAL, SSL will not protect the login page and the portal pages.