Set up SSL for WebSphere Portal

 

+
Search Tips   |   Advanced Search

 


Overview

Setting up Portal with SSL involves configuring...

In general, the Web server must be configured to accept inbound SSL traffic. Then, the WAS plug-in for the Web server must be configured to forward traffic on that port to WAS and WebSphere Portal. This involves configuring the virtual host information. Finally, WebSphere Portal must be set up to generate self-referencing URLs using SSL as the transport.

This procedure might be slightly different if a front-end security proxy server such as Tivoli Access Manager WebSEAL is used. In that case, the front-end security server handles the client SSL connections. The Web server receives connections from the front-end security proxy server. Mutually authenticated SSL could be configured in the Web server and the front-end security proxy server if needed. This is highly dependent on the security requirements of each deployment. If you plan to use a Tivoli Access Manager WebSEAL TAI with an SSL junction, perform only steps 1-3 of this procedure.

 

Encrypt all requests

After completing the following procedure, all requests, starting with the portal login, are encrypted. In addition, assuming that WAS is also configured to accept SSL connections, the LTPAToken and other security and session information can be completely protected against hijack and replay attacks.

  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.

    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.

  2. Configure the WAS plug-in for the Web server to forward WebSphere Portal traffic that is received over SSL to WAS (which will then forward the traffic to WebSphere Portal). Update the virtual host list for WAS to include the correct host name and port number, and regenerate the plug-in configuration.

    1. Open the WAS Administrative Console and click...

      Environment | Virtual Hosts

    2. Add a host alias for the host name and SSL port that were added to the Web server in step 1.

      In a default setup, simply adding the new alias to the "default_host" virtual host will be sufficient. Note that the host name might be "*", or might be a fully "*", or might be a fully qualified host name. Usually this would be the host name of the Web server.

    3. If the Web server is remote, copy the plugin-cfg.xml file to the remote Web server.

    4. Click...

      Environment | Update Web Server Plugin | OK

  3. In configurations where the Web server and WebSphere Portal 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 plug-in and for the embedded HTTPD of WAS. For complete instructions for this step, refer to the section 10.11: SSL between the Web server and WebSphere of IBM WebSphere V5.0 Security (SG24-6573-00).

  4. Edit...

    <wp_root>/shared/app/config/services/ConfigService.properties

    ...and change the following parameters...

      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 step 2. The parameter redirect.logout.ssl determines the protocol that is used when the logout button is clicked. 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 portal page.

  5. This step is only required if inbound connections to WebSphere Portal must be over SSL. If inbound connections are forwards from external Web Servers over standard HTTP, meaning that the Web Server is the SSL end point, then skip this step.

    Edit...

    <was_root>/installedApps/<hostname>/wps.ear/wps.war/WEB-INF/web.xml

    ...and change the <security-constraint> tag of the protected portal URL to use HTTPS:

        <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>GET</http-method>
              <http-method>POST</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">
    
               // replace NONE with CONFIDENTIAL
              <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
    
           </user-data-constraint>
    
        </security-constraint>
    

  6. Edit the JSPs that provide the login link. You can search the theme directories for all JSPs that have the following string:

        screen="Login"
          

    This attribute should appear in an anchor similar to this:

        <a href='<wps:url home="public" screen="Login"/>'>
          

    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 --%>
          
    After finding the login link, change or add the ssl="true" attribute to the <wps:url> tag of the anchor, for example:

    <%-- login button --%>
    <wps:if loggedIn="no" notScreen="Login">
    
    <td valign="middle">
    
       <a href='<wps:url home="public" ssl="true" screen="Login"/>'>
    
        <img src='<wps:urlFindInTheme file="nav_login.gif"/>' 
             alt='<wps:text key="link.login" bundle="nls.engine"/>' 
             border="0" 
             align="absmiddle" 
             width="25" 
             height="25" 
             title='<wps:text key="link.login" bundle="nls.engine"/>'>
       </a>
    
    </td>
    
    </wps:if>
      

  7. Delete the compiled JSPs from the application server cache by removing the contents of the following directory:

        
      <was_root>/temp/node/WebSphere_Portal/wps/wps.war
    

  8. Restart the Web server and the WebSphere Portal application server for these changes to take effect.

  9. Test the changes by launching the portal home page in a Web browser and clicking the login link. The session will be directed to a secure connection after you log in. A browser security prompt appears after you click the login link to send your credentials to the server.

 

Configure SSL for WebSphere Portal only for login process

Follow these steps to only encrypt the login process to WebSphere Portal and allow subsequent requests via HTTP:

WebSphere Portal should already be configured for SSL per the appropriate LDAP directory instructions.

  1. Set the following parameters...

    File Parameter
    ConfigService.properties redirect.login.ssl=false
    web.xml <security-constraint id="SecurityConstraint_1">
      <transport-guarantee>NONE</transport-guarantee> </security-constraint>
    login.jsp <wps:urlcommand="LoginUser" ssl="true"/>

    The locations of the above files are:

    • <wp_home>/shared/app/config/services/ConfigService.properties
    • <was_root>/installedApps/<hostname>/wps.ear/wps.war/WEB-INF/web.xml
    • <was_root>/installedApps/<hostname>/wps.ear/wps.war/screens/html/Login.jsp


  2. Restart the WAS

  3. Test the login by issuing the following URL: http://portalserver.com/wps/myportal.

  4. Submit the credentials; notice that the URL does not change to https.

    You can confirm the login was encrypted by monitoring the packets via a network utility such as Ethereal. Furthermore, set the browser to warn you when changing between secure and insecure modes to see the behavior on the client-side.

 

See also