Web Agent Guides › Web Agent Configuration Guide › Web Agents

Web Agents

This section contains the following topics:

How Web Agents Secure Resources

How Web Agents and the Policy Server Work Together

How the Agent Reads CA SiteMinder® Cookies

Framework and Traditional Agent Architectures

Parameters Requiring a Server Restart when Changed

Multiple Agent for IIS Directory Structures According to Operating Environment

How Web Agents Secure Resources

A CA 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 CA 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:

• Intercept access requests for protected resources and work with the Policy Server to determine whether or not a user should have access.
• Provide information to a Web application that dictates how content is presented to the user (policy-based personalization) and how to deliver access privileges.
• Ensure a user’s ability to access information quickly and securely. Web Agents store contextual information about user access privileges in a session cache. You can optimize performance by modifying the cache settings.
• Enable single sign-on across Web servers in a single cookie domain or across multiple cookie domains without requiring users to re-authenticate.

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

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

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:

• After authorizing a user to access a Web application, the Web Agent could also send information to the Web application dictating how long the user session can last.
• If the user is returning to a site where he or she previously registered, the Web Agent could return information about that user’s buying preferences.

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

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

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.