Single sign-on

HTTP single sign-on preserves user authentication on different web applications. By using HTTP single sign-on, 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 LDAP servers, IBM Directory Server.

In a single sign-on (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).

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. To support SSO, WebSphere Commerce requires LDAP to be used as the common user repository that is shared by all of the applications that require SSO.

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.

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:
  1. 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 the WebSphere Commerce database before logon 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.

  2. For SAML integration, you can use the SAML support that was added in WebSphere Application Server 7.0.0.23. 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 more information about SAML, see Understanding the WebSphere Application Server SAML Trust Association Interceptor on IBM developerWorks.
Attention: There are several 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.