When a user opens a new browser session and navigates to a CA SSO protected resource, the Agent intercepts the request at the webserver end where the protected resource resides. At the Agent end there are different Managers that each perform different actions. The following describes the flow:
1. To start, the HighLevelAgent (HLA) passes the request to the Resource Manager. It is the responsibility of the Resource Manager to extract information about the requested resource such as HTTP_Host, Client IP address, Agent Name, URL, Method (Get, Post etc), Cookie Domain. Furthermore, it does some checks such as CSSChecking, BadURLChars, AutoAUthorize URL etc.
2. Next comes the Session Manager. Since there is no session established yet, the Session Manager will return no action.
3. At this point the Protection Manager is called. Now the agent, via the Low Level Agent (LLA), makes a TCP/IP connection to the Policy Server. The Policy Server, based on the Agent name and resource URL (already captured by Resource Manager above), is able to identify if the resource is Protected by CA SSO. This information is captured by the Realm\Rule objects at Policy Server. Once the Policy Server identifies this information, it sends the response back to the Agent via TCP/IP. If the resource is protected, Agent pass on to the next manager.
4. The Agent calls the Credential Manager. Since there are no credentials present, the Credential Manager calls the Challenge Manager.
5. The Challenge Manager, based on the Authentication Scheme selected (this information is captured at the Protection Manager step from the Realm), processes the credential collection mechanism via HTML Form credentials, NTC etc.
6. At this time the user is presented with a credential collection page (based on the authentication scheme defined).
7. On supplying the credentials, the Webagent calls the Authentication Manager. The agent again makes a TCP/IP connection to the Policy server via LLA as it cannot make this decision on its own. The Policy Server at this point tries to disambiguate/Authenticate the user based on the User Directories selected for that Domain Object. Once it authenticates the user, it generates a SessionSpec and encrypts it with SessionTicket Key and sends it along with SessionID and other Authentication responses to the Webagent.
8. The Webagent at this point declares that the user is Authenticated and passes the request on to the Session Manager.
9. The Session Manager at this point generates the user session, creates a SMSESSION cookie and writes to the user’s browser.
10. Finally, the Agent calls the Authorization Manager. Since the agent again does not have the capability to make this decision it calls the Policy Server via TCP/IP. The Policy server, based on the ‘Policy’ object definition for that domain, makes the Authorization decision. It then sends the Authorization responses to the Webagent.
11. At this point, the Webagent has all the information it needs to make the decision. Now the Webagent passes on the control to the webserver to show the target page to the end user.
If the user tries to browse another protected resource using the same browser session, it will have the same flow but a few things will be different such as, the Session Manager at step 2 decodes the SMSESSION cookie already present in the browser and checks if it is a valid cookie (session timeouts etc). Furthermore, the Credential Manager at step 4 uses session information and by-passes the challenge Manager step to perform the authentication. This way single-sign-on is achieved without challenging the user while Authentication/Authorization occurs in the background.
Hopefully you will find the information above useful as you troubleshoot Webagent-related issues.