HTTP Single sign-on

HTTP single sign-on (SSO) preserves user authentication on different web applications. The user is not prompted multiple times for security credentials within a trust domain. The trust domain includes the following applications and servers:

An HTTP cookie is used to propagate a user's authentication information to disparate web servers, relieving 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 WAS applications. A common user repository 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.

For migrated local stores, a JAAS login module named WCLogin is created and used during authentication to enable WebSphere Commerce to generate the LTPA cookie. The login module is called during the process, where LogonCmd is mapped to the Struts action...

...or...

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 we must incorporate a Trust Association Interceptor (TAI). A TAI converts the custom SSO token into an LTPA token that WebSphere Commerce can understand.

If we 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 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:

  1. If WebSphere Commerce is not configured with LDAP, and we 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: authentication model is based on the following concepts: challenge mechanisms, authentication mechanisms and user registries.">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.

  2. For SAML integration, we can use the WebSphere Application Server SAML feature. For information on the WebSphere Application Server implementation, see Enable 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. We must customize the LDAPIntegrationCmd methods 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 more information about SAML, see on IBM developerWorks.

Attention: Review the following key limitations of single sign-on when it is used with WebSphere Commerce:


Related tasks
Enable single sign-on