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.
