+

Search Tips   |   Advanced Search

 

Set up SSL

This section describes the overall tasks that are required to configure SSL for IBM WebSphere Portal. Some of these tasks are performed on the IBM WAS and the Web server.

Steps that are unique to WebSphere Portal are described in detail here.

This procedure might be slightly different if a front-end security proxy server such as IBM TAM 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 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 Configure SSL only for the login process.

  1. Configure the Web server to support HTTPS for inbound connections from client browsers.

    Depending on the Web server you want to use, other software may have to be installed on the Web Server machine, for instance, with Microsoft Internet Information Server, also install Microsoft Certificate Service.

    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, use IKEYMAN to generate a self-signed certificate.

    For Internet Information Server, use the Web server's resource took kit to create SSL keys.

  2. Configure the WAS 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, 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 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. To create or modify the redirect.login.ssl=true and host.port.https=alias_port properties in the configuration services:

    1. Log on to the WAS Administrative Console.

    2. Navigate to...

        Resources | Resource Environment | Resource Environment Providers | WP ConfigService | Additional Properties | Custom Properties

    3. If the property already exists, click the appropriate property to modify it or click New to create the properties.

    ...where alias_port is the port number that is used for the virtual host alias 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

    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 to completely secure the protected area over HTTPS.

      You 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 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 "wps.Login" string: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.

      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 allow direct access to the WebSphere_Portal node on the internal port, for example http://www.ibm.com:10040/wps/portal, 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 WAS 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. 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. Stop and restart the server1 and WebSphere_Portal servers.

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

  9. 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 WAS.).

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

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

 

Parent topic

Configure SSL