Commerce SSO is managed by a dedicated Oracle Commerce Platform server instance. When you set up your environment in CIM, it gives you the option of setting up this server. The server includes the SSO module and the DPS.InternalUsers module (which the SSO module has a dependency on), and uses the same datasources as the ATG Content Administration server, so it can access the Oracle Commerce Platform 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 either the internal profile repository or the LDAP server, depending on which configuration is used. If the login succeeds, the requested application is displayed.
The SSO module includes a web application that manages the single-sign on process. The application, whose context root is sso, provides six main functions that can be accessed via plug-ins by client applications: login, validate, keep alive, query, 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 Oracle Commerce Platform request-handling pipeline on the SSO server. This servlet dispatches requests to other servlets that provide the 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 into 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./query-- Dispatches the request to the/atg/sso/servlet/QueryServletcomponent, of classatg.sso.servlet.QueryServlet. This servlet is responsible for issuing RQL queries against the internal profile repository. This function is accessed only by the Guided Search plug-in./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 Guided Search 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.
