Commerce SSO is managed by a dedicated ATG server instance. When you set up your ATG environment in CIM, it gives you the option of setting up this server. The server includes the SSO and DPS.InternalUsers modules, and uses the same datasources as the Content Administration server, so it can access the ATG Internal Profile Repository.
When an unauthenticated user attempts to access the Business Control Center or the Workbench, he or she is redirected to the SSO server’s login page. The login is authenticated against the ATG Internal Profile Repository, and if it succeeds, the requested application is displayed.
To access the Business Control Center via Commerce SSO, the user must have an account in the Internal Profile Repository. To access the Workbench, the user must also have an account with the same user name in Endeca. If a user attempts to log into the Business Control Center with an ATG account that does not have a corresponding Endeca account, the login to the Business Control Center succeeds, but the user is not able to access the Workbench. If a user attempts to log into the Workbench with an Endeca account that does not have a corresponding ATG account, the login fails.
The SSO module includes a web application that manages the single-sign on process. The application, whose context root is sso, provides five main functions that can be accessed via plug-ins by client applications: login, validate, keep alive, control, and logout.
To perform these tasks, the Commerce SSO makes use of ticket granting tickets and service tickets. A ticket granting ticket is like a global flag that indicates the user has been successfully authenticated. When a user is authenticated successfully, a service ticket is issued to the user. The service ticket is a short-term object that is used to perform validation. The first time the user attempts to access a URL, the service ticket is passed to the SSO server along with the URL to validate that the user is permitted to access the URL. The SSO server responds either “yes” or “no” to the request based on the status of the ticket.
The SSO application adds the /atg/sso/servlet/SSODispatcherServlet component, of class atg.servlet.pipeline.ServletPathDispatcherPipelineServlet, to the ATG request-handling pipeline on the SSO server. This servlet dispatches requests to other servlets that provide the five SSO server functions. The servlet that SSODispatcherServlet dispatches the request to depends on the servlet path of the request:
/login– Dispatches the request to the/atg/sso/servlet/LoginServletcomponent, of classatg.sso.servlet.LoginServlet. This servlet manages the process of authenticating the user and issuing a service ticket./validate-- Dispatches the request to the/atg/sso/servlet/ValidateServletcomponent, of classatg.sso.servlet.ValidateServlet. This servlet manages the process of validating requests based on the status of service tickets./keepAlive-- Dispatches the request to the/atg/sso/servlet/KeepAliveServletcomponent, of classatg.sso.servlet.KeepAliveServlet. This servlet ensures that an SSO session remains active as long as there is activity in either the Business Control Center or the Workbench. For example, if the user logs in to Commerce SSO and accesses the Workbench for several hours without accessing the Business Control Center, the keep alive function ensures that subsequent attempts to access the Business Control Center do not require logging in again./control– Dispatches the request to the/atg/sso/servlet/ControlServletcomponent, of classatg.sso.servlet.ControlServlet. This servlet handles configuration of the client logout URL. This function is accessed only by the Endeca plug-in./logout– Dispatches the request to the/atg/sso/servlet/LogoutServletcomponent, of classatg.sso.servlet.LogoutServlet. This servlet manages the process of deleting any tickets associated with the session and then redirecting to the login page.
