Setting the Windows Security Context with SiteMinder

Note: Portions of this post come from details in the SiteMinder Policy Server Configuration and User Context Gateway Guides Copyright © by CA Technologies.

Overview: In a Windows network, a security context defines a user’s identity and authentication information. Web applications such as Microsoft Exchange Server or SQL Server need a user’s security context to provide native security in the form of Microsoft’s access control lists (ACLs) or other access control tools. The SiteMinder Web Agent can provide a Windows user security context for accessing Web resources on IIS Web servers. By establishing a user’s security context, the server can use this identity to enforce access control mechanisms. This approach can be used to supply the security context to applications that call native .NET (or other) methods to get the user and associate security information.

There are several requirements to use SiteMinder’s native mechanism to establish the security context in IIS:

  • Active Directory must be used as the user store with the “Use authenticated user's security context” option checked.
  • The SiteMinder Session Server must be configured and enabled on all the Policy Servers. The Session Server requires a relational database (e.g. MS SQL) in which to store session information.
  • The realm protecting the applications requiring the user’s security context must have Persistent Session enabled.

The session server stores a user’s encrypted credentials and associates the user with a session ID. When a SiteMinder session is established between a client and a Web Agent, the Windows user account is established and linked to the session.

Considerations: There are several considerations to keep in mind when using SiteMinder to establish the Windows Security Context. These items may impact the ability to leverage SiteMinder functionality for this purpose.

The following items should be considered:

  • The user must initially authenticate to a realm with Persistent Session enabled. This is required to establish the initial session for the user in the session server and to capture the user’s credentials. In an environment where a user can authenticate to multiple realms, each of those realms must have Persistent Session enabled. A user may be re-challenged when entering a realm with Persistent Session enabled if the initial authentication was to a non-persistent realm. However, it looks like SiteMinder is instead throwing an error in that scenario.
  • The user must authenticate to Active Directory for the necessary information to be captured in the session store. When domains have a combination of multiple user directories of different types listed, the Active Directory user directory may need to be listed first to ensure that a user’s credentials do not match another directory prior to being authenticated to Active Directory. If that occurs SiteMinder will not be able to establish the user’s security context.
  • Persistent Sessions introduce performance implications since the session must be validated against the session server. This can be minimized by setting the validation period on the session to a high value to reduce the number of times the session is checked. The validation period should be set less than the idle timeout value. Once a persistent session is established for a user, the users session is always validated against the session server regardless of if the realm being accessed has persistent session enabled. Using security zones for the Web Agents protecting applications requiring persistent sessions constrains the session validation to that zone only. This eliminates the need for other agents to validate the session with the session server.
  • Environments with global implementations require either the session database to be replicated in real-time to each data center or for the Policy Servers to point back to a common session store across the network. If the Policy Server does not have the session server enabled or is pointed to a database that does not contain the user’s session, the user will be re-prompted for authentication. Pointing at a database across the network to a common session store eliminates that issue, but due to the latency and frequency of the calls to the session server this is not recommended.
  • Only authentication schemes that leverage an ID and password can be used with SiteMinder’s capability to establish the Windows Security Context. The following authentication schemes are supported:
    • Basic Authentication Schemes
    • Basic Over SSL Authentication Schemes
    • HTML Forms Authentication Schemes
    • X.509 Client Certificate and Basic Authentication Schemes
    • X.509 Client Certificate and HTML Forms Authentication Schemes

Other Options: Since third-party Web Access Management (WAM) systems are fairly prevalent, modern applications should support the capability to integrate with this type of system. This is usually done by trusting a header or token created by WAM system that contains the user’s identity. For SiteMinder the application should read the SM_USER header or allow the option to specify a header that contains the user’s identity. SiteMinder can then set the appropriate header using a response that ties the header to the specific identity attribute in the underlying user store.

In cases where that is not possible and the SiteMinder native capabilities to establish the security context do not meet the specified requirements, CA has a solution module called the “User Context Gateway” that can establish the security context for the user. The User Context Gateway (UCG) is used for three purposes:

  • Establishing a Windows Security Context under IIS.
  • Capturing a user’s sign-on password for later use.
  • Maintaining and verifying a Windows password independent of the user’s sign-in (also known as “directory”) password.

UCG differs from SiteMinder native security in the following ways:

  • All user directories that are writable to SiteMinder can be used by UCG. SiteMinder natively requires Active Directory as the user store.
  • The session server is not required for UCG.
  • All authentication schemes are supported by UCG. SiteMinder natively requires authentication schemes that leverage an ID and password.
  • The user’s credentials are stored persistently in the user directory instead of being stored in the session store.
  • While not recommended a user’s credentials can be made available to third-party applications. SiteMinder natively can only supply the user’s password to the first resource requested after authentication.

Since the User Context Gateway is a solutions module, there may be additional costs for this solution. Compatibility with the deployed version of SiteMinder should also be validated.

Configuring SiteMinder to Establish the Windows Security Context:

The following steps outline what is required to configure SiteMinder to establish the Windows Security Context for the user:

  1. Create the session server database and run the relevant SQL scripts to create the tables, etc.
  2. Define the ODBC data source for the session database.
  3. Configure the session database on the Data tab of the Policy Server Management Console and enable the session server.
  4. Enable the user directory containing the Windows users to run the security context by checking the “Use Authenticated User's Security Context” check box on the Directory Setup group box on the User Directory pane.
  5. Associate one of the authentication schemes defined in the Considerations section with each realm where a user can authentication in the resource group box of the Realm pane.
  6. Enable persistent sessions for each realm and set a high Validation Enabled period with each realm where a user authenticates or the Windows Security Context is required in the session group box of the Realm pane.

Refer to the relevant SiteMinder documentation for details on how to perform these steps.