This section contains the following topics:
How to Set Up Virtual Server Support
Assign Web Agent Identities for Virtual Servers
Specify Virtual Servers for the Web Agent to Ignore
A virtual server is a logical entity that you configure on a physical server. This logical entity acts as an independent server. Virtual servers let you host multiple websites on one physical server. For example, using virtual servers, you could set up a server to host both www.mysite.com and www.yoursite.com.
You can assign any of the following to a virtual server:
Although you configure only one Web Agent per web server, you can configure Agent identities to protect your virtual servers. If one user accesses the server through www.mysite.com and another user accesses the server through www.yoursite.com, each server is protected by an agent identity. The advantage of creating an agent identity for each virtual server is that you can define unique realms and rules for each site.
The settings that you define for the Web Agent apply to all virtual servers that you define for that web server instance; however, each virtual server processes requests independently and the Policy Server treats each virtual server request separately. For more information about virtual servers and how to configure them, see the documentation for your web server.
To configure support for virtual servers, do one of the following tasks:
Note: If you have more than one instance of the Oracle iPlanet web server, such as a server for HTTP communication and a server for HTTPS communication, two WebAgent.conf files exist. Each file can have multiple agent identities. (The name Oracle iPlanet refers to the web server that was formerly called Sun ONE and iPlanet.)
Additional Web Agents for each virtual server are not actually defined, but are assigned a Web Agent identity. To protect virtual servers that have unique access requirements or to protect distinct realms, assign each server a unique Agent identity and use the default agent name for all other virtual servers. The advantage of this option is that you can configure your CA SiteMinder® installation quickly, yet still guard virtual servers hosting realms that require separate protection.
The AgentName parameter and its associated IP address provide mapping for web server interfaces to agent names as defined in the policy store. Web Agents need to make Agent API calls in the proper agent name context in order for the correct set of rules and policies to apply. If no Agent name or IP address is assigned for mapping to the policy store, then the Web Agent uses the value of the DefaultAgentName parameter only for a virtual server.
To protect virtual servers using unique Agent identities, add a Web Agent for each virtual server in the AgentName parameter. Adding separate Web Agents for each virtual server lets you define unique realms and rules for each virtual server.
To assign a Web Agent identity
agentname="agent1,123.123.12.12:8080" agentname="agent2,123.123.12.12:8081" agentname="agent3,123.123.12.13"
If it finds no entries in the AgentName parameter, CA SiteMinder® uses the value of the DefaultAgentName only for a virtual server.
Note: If you change the DefaultAgentName, make sure that it is defined in the Administrative UI exactly as it is defined for the Agent.
If a web server at your site supports several virtual servers, there may be resources on these virtual servers that you do not want to protect with the Web Agent. To simplify how the Web Agent distinguishes which portions of a web server's content it protects, use the following parameter:
Specifies the fully qualified domain names of any virtual servers that you want the web Agent to ignore. Resources on such virtual servers will be auto-authorized, and the Web Agent always grants access to them regardless of which client makes the request. The authorization decision is based on the configuration of the Web Agent instead of being based on a policy.
The list of ignored hosts is checked first before any other auto-authorization checks, such as the IgnoreExt and IgnoreURL settings. Therefore, the double-dot rule will not trigger an authorization call to the Policy Server for resources on an ignored host but would not be ignored by extension.
The host portion of the URL entries for the IgnoreHost parameter must exactly match what the Web Agent reads for the host header of the requested resource.
Note: This value is case-sensitive.
If the URL uses a specific port, then the port must specified.
For centrally-managed agents, use a multi-value parameter in the Agent Configuration Object to represent several servers. For agents configured with a local configuration file, list each host on a separate line in the file.
Example: (URL shown with port specified)
IgnoreHost="myserver.example.org:8080"
Example: (local configuration file)
IgnoreHost="my.host.com"
IgnoreHost="your.host.com"
Default: No default
To specify virtual servers for the Web Agent to Ignore, do either of the following tasks:
Resources using the specified URLs are ignored by the Web Agent and access to those resources is granted automatically.
Copyright © 2014 CA.
All rights reserved.
|
|