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, WebSphere 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 WebSphere 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 WebSphere 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 need to customize the LDAPIntegrationCmdImpl class to support SSO into WebSphere Commerce. For more information, see 1.

A JAAS login module that is named WCLogin is created and used during authentication to enable WebSphere Commerce to generate the LTPA cookie. The login module is called during the logon process, where LogonCmd is mapped to the LTPATokenGenerationEnabledBaseAction Struts Action. 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 WebSphere 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 WebSphere 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 WebSphere 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 WebSphere 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 WebSphere Commerce user that is based on the identity in the custom SSO token: 
    public String getLDAPDNFromSingleSignOnTokenForWebServices(String ssoToken)
Note:
  • If WebSphere Commerce is not configured with LDAP, and you are using a third-party authentication server and custom SSO token, set the SingleSignOn flag to 1 in the WebSphere Commerce instance configuration flag: SingleSignOn="1". In this case, the user profile (except for the password) must exist in theWebSphere Commerce database before log-on or SSO into WebSphere Commerce can take place. Configuring WebSphere Commerce to use third-party authentication is described in the following page: WebSphere Commerce authentication model.

    Then, when users register to WebSphere Commerce, the user profile is created in the WebSphere 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, WebSphere 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 WebSphere Commerce database.
  • For an OpenID Connect (OIDC) integration, you can use the WebSphere Application Server OIDC Relying Party feature. In this approach, WebSphere 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 WebSphere 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 WebSphere 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.