Set up SSL

 

+

Search Tips   |   Advanced Search

 

This section describes the overall tasks that are required to configure SSL for IBM WebSphere Portal.

This procedure might be slightly different if a front-end security proxy server such as WebSEAL is used, in which case the security server handles the client SSL connections and the Web server receives connections from the proxy server. Mutually authenticated SSL can be configured in the Web server and the front-end security proxy server if needed. To use a TAM WebSEAL TAI with an SSL junction, perform only steps 1-3 of this procedure.

If only the login process should be secure over SSL, perform the first three steps and then go to Configuring SSL only for the login process.

  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, we can use the iKeyman utilty to generate a self-signed certificate.

  2. Configure the Web server plug-in for Secure Sockets Layer

    Configure the plugin 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).

  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, we 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 WAS.

    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 Service, 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.logout.ssl determines the protocol that is used when you click the logout 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 portal 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 WebSphere Portal 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, the changes will be deleted when the EAR file is updated.

    1. Export the WebSphere Portal EAR file and use the EARExpander tool to expand the contents of the exported EAR file.

    2. Update the Transport Security Constraint.

      This step is only required if we need to completely secure the portal protected area over HTTPS. We can modify the transport guarantee so that WAS will enforce the use of SSL for all pages under the '/myportal/' URL.

      Edit...

      wps_expanded/wps.war/WEB-INF/web.xml

      Change the security-constraint tag of the protected portal URL (/myportal/*) to use HTTPS by setting the transport guarantee from '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">
      
            // replace NONE by CONFIDENTIAL
            <transport-guarantee>CONFIDENTIAL</transport-guarantee> 
      
         </user-data-constraint>
      
      </security-constraint>
      

    3. To update themes:

      1. Edit the JSP and JSPF files that provide the login link. We can search the theme directories under...

        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>
        

        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 EAR file through the wsadmin tool; see steps 4 through 6 in Deploying themes and skins in a production environment.

      If this is a clustered environment, verify that the EAR changes have synchronized to all nodes. Restart the servers on each node.

  6. 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 parameter UseSecureLoginActionUrl and set the parameter to true.

    3. Restart server1 and WebSphere_Portal server:

      was_profile_root/bin
      ./stopServer.sh server1 -user admin_userid -password admin_password
      ./stopServer.sh WebSphere_Portal -user admin_userid -password admin_password
      ./startServer.sh server1
      ./startServer.sh WebSphere_Portal

      If this is a clustered environment, verify that the EAR changes have been successfully synchronized to all nodes. Restart the servers on all nodes.

  7. To test the changes:

    1. Launch the portal home page in a Web browser through an unsecure HTTP URL. For example,...

      http://portalserver.com/wps/portal

    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.

      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 unsecured HTTP URL that points directly to the protected portal area. For example,...

      http://portalserver.com/wps/myportal

    6. Verify that you are requested to login and that the login page and the portal page afterwards are protected through SSL.

      If the security-constraint has not been modified to CONFIDENTIAL, SSL will not protect the login page and the portal pages.

 

Related information

  1. IBM WAS V6 Security Handbook, SG24-6316-00
  2. Security planning overview
  3. Manage digital certificates
  4. http://www.redbooks.ibm.com/
  5. http://www.ibm.com/software/webservers/httpservers/library.html
  6. Set up LDAP over SSL
  7. Deploying themes and skins in a production environment

 

Parent topic:

Secure Socket Layer overview