SSO Flow of Siteminder Agent with Policy Server

After working into CA Siteminder based projects for more than 5 years, I have came to the following conclusions about Siteimnder.

 
 Flow-1:
============
a. The user enters the application url in the browser, it goes to the web server, if web agent is installed on the web server, The request is first intercepted by the webagent.conf file

b. In web agent.conf file it finds the path of the smhost.conf file and the request goes to smhost.conf file.

c.  In the smhost.conf file it finds the policy server which it needs to contact.

d. Then Web server contacts the policy server through the ports 4444(1,2,3) that are mentioned in smhost.conf file. This is done by LLAWP(Low Level Agent Worker Process)

e. The LLAWP sends the request to policy server asking for initializing the communication between the web agent and policy server. In the request web agents send the details of trusted host that is present in smhost.conf file

f. While policy server receives the request it checks whether it can trust the request by seeing whether the trusted host present is present in policy store and if it belongs to web server from which it got the request.

g. This initial request sent by web agent is encrypted by the shared secret present in smhost file. So the request is securely and only policy server can decry-pt it.

h. If policy server trusts the request it starts the communication with the web agent. This communication will be started HLA process from policy server. HLA process uses HCO that web agent used to register with policy server.

i. When the communication from policy server reaches the web agent it decrypts the communication using shared secret and in communication it will have details about the HCO which have started the communication, it compares if HCO in communication is same as HCO present in smhost.conf file.

j. This way the policy server and web agent handshake with each other and sets the communication.Now Web agent sends the details of the ACO present in webagent.conf to policy server.

k. The policy server now takes the this ACO and it will see if it is present in policy store, if it is present it will get the agent name present in ACO and also the properties of the agent present in ACO.

l. Now policy server asks for the resource and web agents sends the resource it go from browser.

m. policy server gets the list of all the realms present in policy store which are linked to the agent that is present in the ACO. It compares the resource it got from web agent is present in any realm in the list (Here it sees the longest match) and gets the realm which has this resource and policy server see's whether this realm is configured for protected or not protected. If not protected , it will say web agent it is not protected.

n. If it is protected, it will whether the request that got from browser has smsession. If no smsession then policy server fetches the authscheme (Authentication Scheme) from realm and gives the corresponding login page to web agent and it gives it to browser.

This the process that will occur to check whether the resource or request got from browser is protected or not.

All the communication that occur after handshake between policy server and web agent is in encrypted for security. The encryption and decryption is done using keys present in key store.

Flow- 2:
=========
The WebAgent Initialization:
========================

While you register the agent with the policy server thru smreghost command, The SmHost.conf file gets created and SmHost.conf file contains information that the Web Agent uses to make initial connections to the Policy Servers to which it is associated.it also creates a trustedHost object into the policy store.which you specify at the time of registration.
Trusted Host is a client computer where one or more Web Agents is installed. It handles the connection to the Policy Server. The term trusted host refers to the physical system. You can have more than one trusted host on a physical server, but each must be identified by a unique name.

Hence when you enable the webagent and bounce the webserver, the initial connection flow goes like this, the webagent reads the WebAgent.conf file and looks for the path of SmHost.conf file, from that path it reads the SmHost.conf file and tries to connect to the IP Address of the policy Server m/c which are present there. once that is done, it then fetches the trustedHost object from the policy store (The policy Store is connected with the policy Server). Once that is done then a successful TCP connection is established between the webAgent and the policy server. the WebAgent then never uses the SmHost.conf file.


Before explaining the request processing part, let me explain the connection between WebAgent and the WebServer. There is a Http connection between the WebAgent and the WebServer. As soon as you configure the webagent with the webserver, remember we specify the webagent binaries inside the configuration of webserver. so when you bounce the webserver after configuration, it loads the webagent DLL / Binaries into the webserver process. This is how a Http connection is made.

Request Processing:
===================
When user access a resource from the browser say http://www.test.com/site/test.html . The WebAgent filters this request from the web server module and after parsing the host and the resource name webagent sends the resource name to the policy server thru the TCP socket connection in form of packets. for e.g. ACO, AgentName, HostName, Client IP, resourceName etc. each in a seperate encrypted packet. 

The Policy Server decrypts the each packet and it knows the agent name which has sent the request, from the agent name it fetches all the matching Realm Object and from the Realm object it checks the resource which has been associated with a specific realm, it then checks that if the resource is protected in a realm and if it is protected, it sends a challange response back to the webagent over the same TCP socket connection, WegAgent who is listing over that socket connection reads the response and throw a chalange to the user in the browser.