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