Identify Who Will Manage Your Web Agents

Web Agents connect to a Policy Server upon startup. The Policy Server contains an Agent Configuration Object (ACO), which directs the associated Web Agent to the location of its configuration parameters.

How your applications are deployed throughout your organization can help you determine the most efficient method of storing the configuration parameters for your SiteMinder Web Agents. Consider the following questions:

1. Are most of your web applications deployed on a large server farm with the same security requirements?
2. Are most of your web applications managed by a centralized person or group?
3. Are most of your web applications deployed on separate web servers with different security requirements?
4. Are most of your web applications managed by different personnel in different departments or physical locations?

If you answered yes to questions one or two in the previous list, try the following configuration method:

• Central Configuration

  Manages one or more Web Agents from an Agent Configuration Object (ACO) that resides in the Policy Server. With central configuration, you can update the parameter settings of several Web Agents at once. Generally, each distinct web application uses a separate ACO, whose settings are shared among all the Web Agents that protect the web application. For example, if you have five Web Agents protecting one accounting application, you can create one ACO with the settings for the application. All five Web Agents would use the parameter settings from the same ACO.

  For different applications, we recommend using separate Agent Configuration Objects. For example, if you want to protect a human resources application with stricter security requirements, create a separate ACO for the human resources application.

  When a Web Agent starts, it reads the value of the AllowLocalConfig parameter of its associated ACO. If the value is set to no, then the Web Agent uses the parameter settings from the ACO.

  Note: We recommend using central web agent configuration (wherever possible) because it simplifies agent configuration and maintenance.

If you answered yes to questions three or four in the previous list, try the following configuration method:

• Local Configuration

  Manages each Web Agent individually using a file installed on the web server itself. When a Web Agent starts, it reads the value of the AllowLocalConfig parameter of its associated Agent Configuration Object (ACO). If the value is set to yes, then the Web Agent uses the parameter settings from LocalConfig.conf file on the web server. The parameter settings from the LocalConfig.conf file override any settings stored in an ACO on the Policy Server.

  Note: For more information about the location of the LocalConfig.conf file on your respective web server, see the Web Agent Configuration Guide.

The following questions can help you identify other situations where local agent configuration better serves the needs of your enterprise:

• Will your enterprise deploy some of your Web Agents on reverse proxy servers?

  For example, you want to protect your internal resources with a large group of Web Agents, while implementing reverse-proxy servers in a few locations. You can use local configuration to manage the reverse-proxy Web Agents.

• Do you want to allow local web server administrators to change some Web Agent configuration settings but not others?

  For example, your organization uses SiteMinder to manage and enforce security policies, but allows web server administrators in remote offices to customize their log on and log off pages. You can add individual parameters to the value of the AllowLocalConfig parameter of the ACO to allow the administrators to change only those settings for the customized pages but no others.

  Note: For more information, see the Web Agent Configuration Guide.