Single sign-on

HTTP single sign-on preserves user authentication on different web applications. By using HTTP single sign-on (SSO), the user is not prompted multiple times for security credentials within a trust domain.

The trust domain includes the following applications and servers:
  • Cooperating but disparate WebSphere Application Server servers.
  • Cooperating applications such as IBM Security Directory Server.

In an SSO scenario, an HTTP cookie is used to propagate a user's authentication information to disparate web servers. This propagation relieves the user from having to enter authentication information for every new client/server session (assuming basic authentication).

By default, HCL Commerce can read and generate the Lightweight Third Party Authentication (LTPA) cookie, which is used to pass SSO credentials between WebSphere Application Server applications. The default mechanism to support SSO requires HCL Commerce to be used as the common user repository that is shared by all of the applications that require SSO, and the user distinguished name in the LTPA cookie matches the USERS.DN value in the HCL Commerce database. If the user does not exist in the database, then the user is created during the first SSO request.

Alternatively, if LDAP is not used, or the LTPA cookie does not contain the USERS.DN, or a different SSO token is used, then you must customize the LDAPIntegrationCmdImpl class to support SSO into HCL Commerce. For more information, see 1.

When LDAP is used for migrated local stores, a JAAS login module that is named WCLogin is created and used during authentication to enable HCL Commerce to generate the LTPA cookie. The login module is called during the process, where LogonCmd is mapped to the Struts Action com.ibm.commerce.struts.LTPATokenGenerationEnabledBaseAction (for HCL Commerce Versions 9.0.0.1+), or com.ibm.commerce.struts.v2.LTPATokenGenerationEnabledBaseAction(for Versions 9.0.1.0+). It proceeds to authenticate against the WCLogin JAAS login module to create the LTPA cookies if the user authenticates successfully.
Note: The AjaxLogon command cannot be used in place of LogonCmd as it does not support the generation of LTPA tokens.

If a non-WebSphere Application Server application must participate in SSO with HCL Commerce, an IBM product such as Tivoli Access Manager WebSEAL can be used to achieve SSO across the different applications. WebSEAL is a reverse proxy that intercepts protected requests and generate an LTPA token upon successful authentication. Alternatively, if you choose to use a non-IBM reverse proxy product, for example, CA SiteMinder, then you must incorporate a Trust Association Interceptor (TAI). A TAI converts the custom SSO token into an LTPA token that HCL Commerce can understand.

If you are using a non-IBM reverse proxy product, and do not want to use LTPA as the SSO token, then HCL Commerce can be customized to read (but not generate) the custom SSO token by overriding the following information:
  1. For SSO over HTTP requests, the following method of com.ibm.commerce.member.syncbeans.commands.LDAPIntegrationCmd must return the USERS.DN value of the HCL Commerce user that is based on the identity in the custom SSO token:
    public String getLDAPDNFromSingleSignOnTokenForWeb(HttpServletRequest request) 
  2. For SSO over web services requests, assuming that MemberFacadeClient.authenticateLTPA(Map) is called first, passing in the String value of the custom SSO token by using the parameter name "LTPAToken". Then, the following method of com.ibm.commerce.member.syncbeans.commands.LDAPIntegrationCmd must return the USERS.DN value of the HCL Commerce user that is based on the identity in the custom SSO token:
    public String getLDAPDNFromSingleSignOnTokenForWebServices(String ssoToken) 
Note:
  • If HCL Commerce is not configured with LDAP, and you are using a third-party authentication server and custom SSO token, you can enable SSO in HCL Commerce by completing the following steps.
    • HCL Commerce Developer
      1. Open the WebSphere Application Server Administrative Console within the Transaction server (ts-app) Docker image.
      2. Go to Application servers > server 1 > Java and process management > Process definition > Java virtual machine > Custom properties.
      3. Set the SingleSignOnEnabled property to true.
    • LinuxIn this case, the user profile (except for the password) must exist in the HCL Commerce database before log-on or SSO into HCL Commerce can take place. To configure HCL Commerce to use third-party authentication, see HCL Commerce authentication model.

    Now, when users register to HCL Commerce, the user profile is created in the HCL Commerce database, and the password is stored in the third-party authentication server.

  • For SAML integration, you can use the WebSphere Application Server SAML feature. For information on the WebSphere Application Server implementation, see Enabling your system to use the SAML web single sign-on (SSO) feature in the WebSphere Application Server documentation. In this approach, HCL Commerce is the service provider. You must customize the LDAPIntegrationCmd methods that are listed in step #1 and #2 to process the LTPA token, retrieve the corresponding SAML attributes that identify the user, and then return the USERS.DN value that corresponds to that user in the HCL Commerce database.
  • For an OpenID Connect (OIDC) integration, you can use the WebSphere Application Server OIDC Relying Party feature. In this approach, HCL Commerce is the Relying Party. You must customize the LDAPIntegrationCmd methods that are listed in step #1 and step #2 to process the LTPA token and then return the USERS.DN value that corresponds to that user in the HCL Commerce database. For information on the WebSphere Application Server implementation, see Configuring an OpenID Connect Relying Party in the WebSphere Application Server documentation.
Attention: Review the following key limitations of single sign-on when it is used with HCL Commerce:
  • The LTPA cookies might flow across different web server ports.
  • Applications that can read and issue the WebSphere Application Server LTPA token are supported.
  • Web browsers that accept cookies are supported so that LTPA cookies can be written.