Thursday, July 19, 2012

How Siteminder cache works



Caches implemented by the Policy Server
Object Store Cache
Purpose: Stores contents of the Policy Store in memory in order to reduce round trip calls to LDAP and ODBC policy stores.
Policy Cache
Purpose: Stores the list of policy links applicable to a given resource and action. Prevents the scanning of all rules within a given realm in order to determine which policies protect a particular resource.
Agent Name Cache
Purpose: Stores easy searchable table of Agent Oids. During IsProtected it is necessary to determine Agent Oid from Agent Name. The Agent Name Cache prevents enumerating all agents to find one with matching name.
Agent Group Cache
Purpose: Stores easy searchable lists of Agent Oids. During IsProtected it is necessary to find all Agents that might protect this resource, i.e. if given agent belongs to Agent Group, all agents (and agent groups) of this group might protect given resource. The Agent Group Cache prevents recursive scanning of all agents to find applicable ones.
Realm Cache
Purpose: Stores Realms for best resource matching. During IsProtected it is necessary to find best matching Realm for given Agents and resource. The Realm Cache prevents scanning of all Realms to find best lexical match.
Server Command Cache
Purpose: Stores Server Commands for configurable amount of time (default 10 seconds) before actually storing them in Policy Store. When changes are made to Policy Store, duplicate commands may be created. Also, “Flush” commands of broader scope overwrite more specific Flush commands. For example, if user initiates “Flush All” command, all other “flush” commands become irrelevant. This is done to decrease overall number of Server Commands.
User Authorization Cache
Purpose: Stores information about policies applied to a given user. When a policy is bound to a user directory object such as a group it is necessary to determine whether a particular user belongs to the group i.e. it is necessary to search the directory to get the user’s membership list. The User Authorization Cache prevents this round trip to the directory. Note that if a policy is bound to a user name (or DN, OU, and O), the Authorization Cache is ineffective because in this case there is no need to search the directory in the first place.
Authentication Cache
Purpose: Stores full response packets for a successful user authentication. Prevents a round trip to the LDAP or ODBC user store in order to authenticate a particular user. There are a number of limitations with this cache
Certificate Revocation List (CRL) cache
Purpose: Stores CRLs. Eliminates search of the CRL Directory during certificate-based authentication.
Type: Unbounded linked list of objects. During successful lookup the “NextUpdate” field of the CRL is checked. If the current time is bigger then the value of that field, the entry is removed.

Friday, July 6, 2012

To create the SiteMinder schema



1. Start the Query Analyzer and log in as the person who administers the Policy Server database.
2. Select the database instance from the database list.
3. Open sm_mssql_ps.sql in a text editor and copy the contents of the entire file.
4. Paste the schema from sm_mssql_ps.sql into the query and execute the query.
The policy and key store schema is added to the database.
5. Open SQLServer.sql in a text editor and copy the contents of the entire file.
6. Paste the schema from SQLServer.sql into the query, and execute the query.
The policy store schema is extended.
7. Repeat steps three and four to use the policy store as an audit logging database. Use the following schema file:
sm_mssql_logs.sql
Note: You are not required to configure the policy store to store additional SiteMinder data. You can configure individual databases to function as a separate audit log database, key store, and session store.
The database can store SiteMinder data.

How to Configure the Siteminder Policy Store



Complete the following procedures to configure a SQL Server database as a policy store.
Note: Be sure that you have gathered the required database information before beginning. Some of the following procedures require this information.
1. Be sure that the SQL Server database instance that is to contain the SiteMinder data is accessible from the Policy Server system.
2. Using the SQL Server Enterprise Manager, create the database instance for the SiteMinder data store.
Example: smdatastore.
3. Create the SiteMinder Schema.
4. Configure a SQL Server data source for SiteMinder.
■ (Windows) Create a SQL Server data source.
■ (UNIX) Create a SQL Server data source on UNIX systems.
■ (UNIX) Configure the SQL Server wire protocol driver.
5. Point the Policy Server to the database.
6. Set the SiteMinder super user password.
7. Import the default SiteMinder objects.
8. Import the policy store data definitions.
9. Restart the Policy Server.
10. Prepare for the Administrative UI registration.

SiteMinder and ASP.NET


Process Description
  1. User types the URL for an ASP.NET application into the web browser.
  2. The SiteMinder Web Agent intercepts the request and checks its resource cache. If there is no information in cache about this resource (URL), the Web Agent then sends the request to the Policy Server, asking if the resource is protected.
  3. The Policy Server responds indicating that the resource is protected.
  4. The Web Agent forwards the request to a login page for challenging the user for their credential.
  5. The Web Agent forwards the credentials back to the Policy Server for authentication and authorization.
  6. The Policy Server authenticates the user against a directory. After verifying the user’s identity, the Policy Server checks rules in the Policy Store, where user entitlements are stored and grant the user access to the resource.
  7. The Policy Server notifies the Web Agent that the user is authenticated and authorized for this resource.
  8. The Web Agent constructs several SiteMinder HTTP headers with information about the authenticated user (userid), generates an encrypted session cookie and redirects the request to the original target URL.
  9. The request reaches the ASP.NET application where the userid can be extracted from the SiteMinder headers for further processing.

Tuesday, July 3, 2012

Unable to process SMSESSION cookie


"Unable to process SMSESSION cookie" warning in siteminder webagent logs


Multiple reasons:
=============
1>We could see this warning in siteminder web agent logs. user tries to perform any action(navigating to any page or url) after his session time out. Then web agent will log this warning "Unable to process SMSESSION" in webagent logs and redirects user to login page.


2>OS time on webserver hosting the webagent is not the same