SiteMinder Overview

HOW CA SITEMINDER WORKS – BASICS

CA Site Minder (a.k.a. Netegrity Site Minder SSO) is a web access management system that enables user authentication and secure Internet SSO (single sign-on), policy-driven authorization, a federation of identities, and complete auditing of all access to the web applications it protects.

Site Minder was originally created by Netegrity, which was acquired by CA (Computer Associates) in 2005.SiteMinder is an Access Management component. It provides a centralized and secure policy management in large scale. It provides a way to authenticate the user and authorize the user for the application which he is only authorized for. Its authorization model is based on security policy. 

SiteMinder is combined with a Policy server and agents installed in web server to which deals operation behind. SiteMinder works on SSO and it also works on Cookie.

SiteMinder consists of two core components:

Policy Server:

The Policy Server provides policy management, authentication, authorization, and accounting.

SiteMinder Agents: 

Integrated with a standard Web server or application server, SiteMinder Agents enable SiteMinder to manage access to Web applications and content according to predefined security policies.

How CA SiteMinder Works:

The process for securely accessing web applications:

1. User attempts to access a protected resource.

2. User is challenged for credentials and presents them to the CA SiteMinder web agent or to the Secure Proxy Server.

3. The user’s credentials are passed to the Policy Server.

4. The user is authenticated against the appropriate user store.

5. The Policy Server evaluates the user’s entitlements and grants access.

6. User profile and entitlement information is passed to the application.

7. The user gets access to the secured application, which delivers customized content

How does SiteMinder Works? & Components of SiteMinder

Web Agents which are installed in Web servers will interrupt the user request and checks if the requested application is Protected? 

 If yes it will transfer the request to the Policy Server.

How web agents intercepts the request and communicate with the Policy Server

1.    When user enters the application url in the browser, it is directed to the web server, the web agent will be installed on the web serves, The request is first intercepted by the webagent.conf file.

2.    In web agent.conf file it will find the path of the smhost.conf file and the request goes to smhost.conf file.

3.    From smhost.conf file it finds the policy server details which it needs to contact for verification[authentication and authorization].

4.    Now Web server contacts the policy server from the details from smhost.conf file.

5.    The Ports included in that is 4441,4442 and 4443 which is done by LLAWP[Low Level Agent Worker Process] process.

6.    LLAWP  sends the request to policy server asking for initializing the communication between the web agent and policy server, there comes to play the role of trusted host[which is created when the agent is installed on the webserver].The Trusted host name will be mentioned in the smhost.conf file.

7.    We need to have a one time trust build for the secure communication between Policy Server and Webserver.

8.    When 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.

9.    The initial communication from the webserver will be encrypted and it is maintained by a Shared Secrete Key which will be present in the smhost.conf. So the request will be secure and only the Policy Server can de-crypt it.

10.A trust is created and communication between webagent and Policy Server will be started, a Process call HLA will be started and it uses the HCO[registered when agent is installed].

11.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.

12.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.

13.The policy server now takes the this ACO[which is in webagent.conf file] and it will check whether the same is  present in policy store of Policy Server, if it is present it will get the agent name present in ACO and also the properties of the agent present in ACO .Now policy server asks for the resource and web agents sends the resource it go from browser.

14.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. After that comparing the resource it got from web agent present in realm in the list, and gets the realm which has this resource and policy server see’s whether this realm is configured for protected or not protected.

Not Protected–> User will be able to access the resource.

if protected–>it will check whether the request that got from browser has a valid smsession. If there is no smsession then policy server fetches the authscheme from realm and gives the corresponding login page to web agent and it gives it to browser[Final output].