Configure Virtual Servers

How to Set Up Virtual Server Support
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 and
You can assign any of the following to a virtual server:
  • A unique IP address
  • An IP address that is shared with the physical server
  • An IP address that is shared with another 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.comand another user accesses the server through, 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
of the following tasks:
  • Define and add an Agent identity for each virtual server, specify a value for the AgentName parameter, and assign it the IP address or host header name of a virtual server.
  • Define an Agent identity only for virtual servers that need to be uniquely identified.
  • Set a Default Agent Name.
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.)
Assign Web Agent Identities for Virtual Servers
Additional Web Agents for each virtual server are not actually
, but are
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 Single Sign-On
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
  1. Enter the name of the agent and the IP address, separated by a comma.
  2. Specify the port number associated with the IP address (for example: if your virtual servers share the same IP address, but use different ports. If you are using default ports, port numbers are not required.
  3. To add more than one Agent, put each entry on a separate line, as in the following example:
    agentname="agent1," agentname="agent2," agentname="agent3,"
  4. If you add an Agent Identity, you must define it in the Administrative UI with the same configuration. Make sure that the Agent Identity is defined in Administrative UI exactly as it is defined for the Agent configuration.
If it finds no entries in the AgentName parameter,
CA Single Sign-On
uses the value of the DefaultAgentName only for a virtual server.
If you change the DefaultAgentName, make sure that it is defined in the Administrative UI exactly as it is defined for the Agent.
Specify Virtual Servers for the Web Agent to Ignore
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.
 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.
 (URL shown with port specified)
 (local configuration file)
 No default
To specify virtual servers for the Web Agent to Ignore, do either of the following tasks:
For central configuration, add the servers you want to ignore to your agent configuration object. For more than one server, use the multi-value setting for the parameter.
  • For local configuration, add a separate line for each server in the local configuration file.
Resources using the specified URLs are ignored by the Web Agent and access to those resources is granted automatically.