How the Agent Reads SiteMinder Cookies

How the Agent Reads SiteMinder Cookies

• Web Agents use agent keys to encrypt and decrypt SiteMinder cookies so the data they contain can be read. The Agent uses the key to encrypt cookiesbefore sending them to a user’s browser and to decrypt cookies received fromother Web Agents.
• All Web Agents need to be aware of the same keys, and the keys must be set to the same value for all Agents communicating with a Policy Server. This rule is particularly important for Agents in a single sign-on environment. To ensure that the keys remain secure, the Policy Server performs a key rollover. A key rollover is the process of generating new keys, encrypting them, and distributing them to all Web Agents within a SiteMinder environment.
• When a Web Agent starts up and makes a management call request, the Policy Server supplies the current set of keys. Each time that the Web Agent polls the Policy Server, the agent again makes the management call. The Web Agent receives the updated keys.

The Policy Server provides two types of keys:

• Dynamic Keys—A dynamic key is generated by a Policy Server algorithm and distributed to other connected Policy Servers and their associated WebAgents. Dynamic keys can be rolled over at a regular interval, or by usingthe Key Management dialog box of the Policy Server User Interface.

• Static Keys—A static key remains the same indefinitely, and can be generated by a Policy Server algorithm or configured manually. SiteMinder uses this type of key for a subset of features that require information to be stored in cookies over extended periods of time.

Automated key changes ease the process of managing agent keys for largeSiteMinder installations that share a single key store. A key store is a storage location for all key information; all agents access the key store to obtain the current keys. For Agents that are configured for single sign-on, the key storemust be replicated and shared across all Policy Servers in the single sign-onenvironment. Automating key changes also ensures the integrity of the keys.

Agent Key Dynamic Rollovers

You can use the SiteMinder Key Management dialog box of the Policy ServerUser Interface to configure dynamic Agent key rollover. Web Agents poll thePolicy Server for key updates at regular intervals. If keys have been updated,Web Agents pick up the changes during polling. The default polling time is 30seconds, but can be configured by changing the PSPollInterval parameter of a Web Agent.

When a Web Agent detects that a key rollover has occurred, the Agent retrieves new values for the following Agent keys:

• Old Key—Last value used for the dynamic Agent key before the currentvalue.

• Current Key—Value of the current dynamic Agent key.

• Future Key—Next value that will be used as the current key in a dynamicAgent key rollover.

• Static Key—A long-term key that the Agent can use for SiteMinder featuresthat need to identify a user and maintain this information for long periods of time. Static keys also support cookie encryption for single sign-on whendynamic keys are not enabled.

Web Agents require multiple keys to preserve cookie data and ensure a smoothtransition between old keys and new keys.

Key Stores

When the Policy Server generates dynamic keys, it saves and maintains thesekeys in the key store. The key store is a repository from which all Web Agents retrieve the most current keys. The key store may be part of a SiteMinder policy store or maintained as a standalone key store.


Source :http://vaibhav181.wordpress.com

Analyze Siteminder Logs

Here is the understanding of analyzing Siteminder Event logs

If the event category is authentication  or authorization , the format is:

lpszEvent lpszHostName lpszTimeString "szClientIp szUserName" "szAgentName szAction szResource" [szTransactionId] [nReason] szStatusMsg

The above format is described as follows,

• lpszEvent. The name (type) of the access event:

  SmLogAccessEvent_AuthAccept : lpszEvent = "AuthAccept"
  SmLogAccessEvent_AuthReject : lpszEvent = "AuthReject"
  SmLogAccessEvent_AuthAttempt : lpszEvent = "AuthAttempt"
  SmLogAccessEvent_AuthChallenge : lpszEvent = "AuthChallenge"
  SmLogAccessEvent_AzAccept : lpszEvent = "AzAccept"
  SmLogAccessEvent_AzReject : lpszEvent = "AzReject"
  SmLogAccessEvent_AdminLogin : lpszEvent = "AdminLogin"
  SmLogAccessEvent_AdminLogout : lpszEvent = "AdminLogout"
  SmLogAccessEvent_AdminReject : lpszEvent = "AdminReject"
  SmLogAccessEvent_AuthLogout : lpszEvent = "AuthLogout"
  SmLogAccessEvent_ValidateAccept : lpszEvent = "ValidateAccept"
  SmLogAccessEvent_ValidateReject : lpszEvent = "ValidateReject"
  

• lpszHostName. The name of the host.
• lpszTimeString. The timestamp of the occurrence of the event, in the format: [//:::
  ]. For example: [27/Jun/2000:11:27:29 -0500]
• szClientIp. The IP address of the client machine.
• szUserName. The name of the user.
• szAgentName. The name of the agent.
• szAction. The action associated with the resource.
• szResource. The accessed resource.
• [szTransactionId]. A string that contains: idletime=.
• [nReason]. The reason associated with the event. Reasons are enumerated in Sm_Api_Reason_t, which is in SmApi.h.
• szStatusMsg. The message associated with the event. The message depends on the event type, as shown in in the following table:

For example:

AuthAccept testbox [27/Jun/2000:11:27:29 -0500] "190.158.4.90 uid=scarter,ou=people,o=airius.com" "testagent GET /test/index.html" [idletime=3600;maxtime=7200;authlevel=5;] [0]

In this example,

• lpszEvent is AuthAccept
• lpszHostName is testbox
• lpszTimeString is [27/Jun/2000:11:27:29 -0500]
• szClientIp is 190.158.4.90
• szUserName is uid=scarter,ou=people,o=airius.com
• szAgentName is testagent
• szAction is GET
• szResource is /test/index.html
• [szTransactionId] is [idletime=3600;maxtime=7200;
      authlevel=5;]
• [nReason] is [0]
• szStatusMsg is not specified.

Siteminder Impersonation

Definition: Impersonation is a method where a Priveleged User assumes the identity of another user,without losing the privileged users session.

Example:

Admin URL : www.xyz.com  

Target URL: www.xyz.com/imperso/targetURL

EndUser Application : www.xyz.com/application

Impersonator : Priveleged User who can assume the identity of another user

Impersonatee :A User whose identity is assumed by the Impersonator

Request Flow:

1)Impersonator logs into Admin URL www.xyz.com which is protected by Siteminder .

Siteminder creates a SMSESSION for the Impersonator.

2)Impersonator clicks on the Target URL: www.xyz.com/imperso/targetURL which initiates Impersonation Journey since the Target URL is protected by Impersonation Authentication Scheme

Impersonation Authentication Scheme prompts for Impersonatee’s user name

3)Impersonator lands to the Target URL  as a Impersonatee

Siteminder creates a SMSESSION for Impersonatee and saves the Impersonators session as SMSAVEDSESSION

4)Now Impersonator assumes the identity of Impersonatee and access the End User Application.

5)Impersonator clicks logout to end Impersonation journey which does the following,

SMSAVEDSESSION Cookie of Impersonator gets restored to SMSESSION and SMSAVEDSESSION returns a NULL value

 

Siteminder Configurations:

In the above example ,Consider Imperso.fcc,Impersologout.fcc and TargetURL are placed under www.xyz.com/imperso/

Realm 1:Create a realm for /imperso/

Authentication Scheme : Impersonation Auth Scheme [www.xyz.com/imperso/Imperso.fcc ]

Rules : Get/Post,ImpersoStart,ImpersoStartUser

Realm 2 for Admin URL[It will be an existing realm which creates a SMSESSION for the Impersonator]

Authentication Scheme: HTML Forms Authentication Scheme

Rules:Get/Post [existing Rules]

Realm 3 for EndUser Application :[Existing Realm]

Rules:Create a ImpersoStart and ImpersoStartUser Actions for all the each existing Rules.

Policies:

Impersonator Policy :

Add all the ImpersoStart Rules under this policy.

User Group:Only Impersonator

Impersonatee policy:

Add all the ImpersoStartUser Rules under this policy.

User Group:Only Impersonatee

Access policy:

Add Get/Post Rule from Realm 1

As part of Impersonation,Imperso.fcc file as to be protected,Since FCC files are ignored as part of IgnoreExt parameter in ACO,Create the following:

OverrideIgnoreExt = /Imperso.fcc

Hope this Documentation Helps!!!Any Queries please comment

SM Session Cookie

SMSESSION cookie represents user's session and contains:

- User's ID

- ID of the directory or database from which the user was authenticated

- SMSESSIONSPEC

- Unique Session ID (a hash of the GUID of the logged in user)

- other proprietary information

The Web Agent is responsible for validating an SMSESSION cookie's integrity, session expiration timeouts, and session revocations.

The session-spec field of the SMSESSION cookie is encrypted as it is transmitted by the Web Agent to the Policy Server to take decision about authentication and authorization. By decoding the SMSESSION cookie, you get the information about:

SM_AGENTAPI_ATTR_USERDN

SM_AGENTAPI_ATTR_SESSIONSPEC

SM_AGENTAPI_ATTR_SESSIONID

SM_AGENTAPI_ATTR_USERNAME

SM_AGENTAPI_ATTR_CLIENTIP

SM_AGENTAPI_ATTR_DEVICENAME

SM_AGENTAPI_ATTR_IDLESESSIONTIMEOUT

SM_AGENTAPI_ATTR_MAXSESSIONTIMEOUT

SM_AGENTAPI_ATTR_STARTSESSIONTIME

SM_AGENTAPI_ATTR_LASTSESSIONTIME