Previous Topic: Web AgentsNext Topic: How the Agent Reads SiteMinder Cookies


Two Types of Agents for Internet Information Services (IIS) Web Servers

SiteMinder r12.0 SP3 now offers the following types of Agents for Internet Information Services (IIS) web servers:

SiteMinder Agent for IIS

A SiteMinder Web Agent for IIS implemented as an ISAPI plug-in and a native HTTP module that supports the following functions:

SiteMinder Web Agent

A SiteMinder Web Agent implemented as an ISAPI plug-in that supports the following functions:

Multiple Agent for IIS Directory Structures According to Operating Environment

The directory structure added to your IIS web server for your Agent files varies according to the operating environment of your IIS web server. The following directory structures exist:

How Web Agents Secure Resources

A SiteMinder Web Agent is a software component that controls access to any resource that can be identified by a URL. The Web Agent resides on a web server and intercepts requests for a resource to determine whether or not the resource is protected by SiteMinder. The Web Agent then interacts with the Policy Server to authenticate and authorize users who request access to the protected web server resources.

Web Agents perform the following tasks:

For a list of SiteMinder Web Agents and supported Web server platforms, go to Technical Support and search for SiteMinder Support Matrix.

Web Agents reside on web servers as illustrated in the following diagram:

Graphic showing a SiteMinder deployment in which the agents reside in a web server

How Web Agents and the Policy Server Work Together

To enforce access control, the Web Agent interacts with the Policy Server, where all authentication and authorization decisions are made.

The Web Agent intercepts user requests for resources and checks with the Policy Server to see if the requested resource is protected. If the resource is unprotected, the access request proceeds directly to the web server. If the resource is protected, the following occurs:

  1. The Web Agent checks which authentication method is required for this resource. Typical credentials are a name and password, but other credentials, such as a certificate or a token card PIN, may be required.
  2. The Web Agent challenges the user for credentials.

    The user responds with the appropriate credentials.

  3. The Web Agent passes the credentials to the Policy Server, which determines if the credentials are correct.
  4. If the user passes the authentication phase, the Policy Server determines if the user is authorized to access the resource. Once the Policy Server grants access, the Web Agent allows the request to proceed to the web server.

The Web Agent also receives user-specific attributes, in the form of a response, to enable Web content personalization and session management. A response is a personalized message or other user-specific information returned to the Web Agent from the Policy Server after authorizing the user. It consists of name-value attribute pairs that are added to HTTP headers by the Web Agent for use with Web applications. Examples of responses include the following:

The following diagram shows the communication between the Web Agent and the Policy Server:

Graphic showing the decision process the web agent uses to respond to requests for resources

Considerations for Web Agents and Policy Servers in Different Time Zones

By default, the Policy Server and Web Agent calculate time relative to Greenwich Mean Time (GMT). Therefore, for each system that has a Policy Server or Web Agent installed, the system clock must be set for the time zone appropriate to that system’s geographical location.

The following illustration shows how the Policy Server executes a policy relative to time. A resource is stored on a web server in Massachusetts and is protected by a Policy Server in California. The policy allows access to the resource between 9:00 AM and 5:00 PM. However, the user in Massachusetts can still access the resource at 6:00 PM because the policy is based on the Policy Server’s time zone, Pacific Standard Time (PST), which is three hours behind the Web Agent’s time zone, Eastern Standard Time (EST).

This diagram shows how to adjust the time settings on your policies when your policy servers and web agents are in different time zones

Note: For Windows systems, both the time zone setting and the time of day (set in the Date/Time control panel) must agree. For example, to reset a system in the U.S. from Eastern time to Pacific time, perform the following tasks in the order shown:

  1. Set the time zone to Pacific time.
  2. Verify that the system clock displays the correct time (three hours earlier than Eastern time).

If these settings differ, single sign-on across multiple domains and agent key management will not work properly.