| Oracle® Access Manager Access Administration Guide 10g (10.1.4.2.0) Part Number B32420-01 |
|
|
View PDF |
| Oracle® Access Manager Access Administration Guide 10g (10.1.4.2.0) Part Number B32420-01 |
|
|
View PDF |
WebGates, AccessGates, and Access Servers are key components when a user attempts to access a protected resource. An Access Server provides an authentication, authorization, and auditing engine. You install a WebGate on each server that you want to protect. The WebGate intercepts HTTP requests for Web content on the server and forward the requests to an Access Server. An AccessGate is a custom WebGate that can intercept requests for HTTP and non-HTTP resources.
This chapter explains how to define and manage AccessGate and Access Server instances.
This chapter includes the following topics:
Prerequisites for Configuring AccessGates and Access Servers
Configuring Preferred HTTP Hosts, Host Identifiers, and Virtual Web Hosts
Associating a WebGate with Particular Virtual Hosts, Directories, or Files
Controlling access to applications and content is the cornerstone of e-business infrastructure. You want to allow some users to use certain resources and deny access to others. You control access to your company's resources through the Access System. The Access System provides base components, consisting of a server and plug-ins, that are the foundation upon which you define access controls.
The following sections discuss setting up the base components of the Access System. These components provide the underlying software that makes it possible to control user access to resources.
As discussed in Oracle Access Manager Introduction and this manual, the following are the primary components of the Access System:
Access Server—A standalone server that provides authentication, authorization, and auditing services for AccessGates.
WebGate—WebGate is an out-of-the-box plug-in that is installed on each server that you want to protect. The WebGate intercepts Web resource (HTTP) requests and forwards them to the Access Server for authentication and authorization.
AccessGate—A custom WebGate that processes resource requests from users or applications. It intercepts user requests for resources and forwards them to the Access Server for authentication and authorization. Unlike a WebGate, you can define a custom AccessGate that intercepts requests for non-http resources.
For information about how Access Servers and WebGates protect resources, see "The Access Login Process".
You administer the Access System through a Web-based user interface that consists of the Policy Manager and the Access System Console.
Policy Manager—This is an Access System application that enables you to create and manage policy domains to protect resources, and to test policy enforcement.
Access System Console—This is an Access System application that provides functions for the following configuration and management tasks:
System Configuration—Functions include configuring administrators and server settings. The View Server Settings page provides information on email, the single sign-on logout URL, and the directory server. See "Configuring Access Administrators and Server Settings" for details.
System Management—Enables you to identify Access Servers on which to run diagnostics, manage user access-privilege reports, and manage sync records. See "About Access System Configuration and Management" for details.
Access System Configuration—Includes the following functions (see also "Managing Access System Configuration Files"):
Oracle Access Manager 10.1.4 should be installed and set up as described in the Oracle Access Manager Installation Guide. The Oracle Access Manager Introduction provides an overview of Oracle Access Manager not found in other manuals. Also, familiarize yourself with the Oracle Access Manager Administration Guide which introduces Access System applications, installation, configuration, administration, and common functions.
Important:
You must have appropriate rights to complete activities in this chapter. See "Configuring Access Administrators and Server Settings" for more details.As described in the Oracle Access Manager Installation Guide, you must install at least one Access Server. It is recommended that you install at least two on different machines to ensure uninterrupted service to your users. Each Access Server must be configured to communicate with one or more AccessGate instances, and to communicate with a directory server.
You must have appropriate rights to configure the Access System. See "Configuring Access Administrators and Server Settings" for more information.
Task overview: Creating an Access Server
Create an Access Server instance in the Access System Console, as described in "Adding an Access Server Instance".
Install the Access Server, as described in the Oracle Access Manager Installation Guide.Configure the Access Server, as described in "Modifying Access Server Details".
Synchronize the clocks on the Oracle Access Manager hosts.
Access Server clocks can be ahead of WebGates by no more than 60 seconds. Webgate clocks should never be ahead of Access Server clocks.
Access Servers record their activity in Greenwich Mean Time (GMT) because you could have servers operating in several time zones. Synchronizing clocks on Oracle Access Manager hosts is critical. See the Oracle Access Manager Installation Guide for details.
Ensure optimal performance by tuning the directory that the Access Server communicates with.
See your directory vendor's documentation for details. For Oracle Internet Directory, see the chapter on performance optimization in the Oracle Internet Directory Administrator's Guide for details.
Using the Access System Console, Access System Configuration function, you can perform a number of key tasks including the following:
You can view all the configured Access Servers in the Access System Console.
To view Access Server configuration details
Launch the Access System Console.
Click Access System Configuration, then select Access Server Configuration.
The existing Access Servers are listed on the configuration landing page.
Select an Access Server to view its configuration.
The configuration details of the Access Server appear, as described next. For details about configuring these parameters, see "Adding an Access Server Instance".
The Access Server configuration parameters appear on the Access System Console, Access Server Configuration page. Table 3-1 lists the configuration parameters:
Table 3-1 Access Server Configuration Parameters
| Field | Description |
|---|---|
|
Name of the Access Server. |
|
|
Hostname |
Name of the Web server that is hosting the Access Server. |
|
Port |
Port number the Access Server is listening to. |
|
Debug |
Indicates whether debugging is on or off. See "Adding an Access Server Instance" for details. |
|
Debug File Name |
The name of this Access Server's debug file. The absolute path to the debug file is also indicated. If the file does not exist, it is created after you restart the Access Server. |
|
Level of transport security to and from the Access Server. Available options are: Open—No transport security. Simple—Encrypted transport security with prepackaged certificates. Cert—Encrypted transport security. |
|
|
The duration, in hours, for a connection between AccessGate and an Access Server. |
|
|
Maximum number of service threads allowed on the Access Server. By default, the number of threads is set to 60. The number of threads may have implications for system performance. See the Oracle Access Manager Deployment Guide for details. |
|
|
Whether Policy Manager API Support Mode is enabled. Setting this to On enables the Policy Manager engine in the server. The Access Server starts servicing Policy Manager API requests from AccessGates for policy management. See "AccessGate Configuration Parameters" for details. |
|
|
Writes audit information to a database. If you set the value to On, you must install a supported database and do additional configuration. See the Oracle Access Manager Administration Guide for details. |
|
|
Writes audit information to a file. |
|
|
Maximum size of the audit file, in bytes. |
|
|
Size of the audit buffer, in bytes. |
|
|
Time, in seconds, that this audit file can exist. |
|
|
Frequency, in seconds, of configuration updates to this server. Note: Changes you make to this parameter do not take effect until the previous Engine Configuration Refresh Period has expired. |
|
|
Frequency, in seconds, with which new URLs are recognized by this Access Server. |
|
|
Frequency, in seconds, with which new password policies are recognized by this Access Server. |
|
|
Number of authenticated users that can be saved in the cache for this Access Server. The default is 10000. A value of -1 disables the cache. |
|
|
Maximum time, in seconds, for inactive user data to reside in cache. |
|
|
Maximum number of elements that can be stored in the policy cache. |
|
|
Maximum time, in seconds, for inactive policy data to reside in cache. |
|
|
Specifies whether SNMP is enabled or not. For details on SNMP monitoring, see the Oracle Access Manager Administration Guide. |
|
|
The port number of the SNMP agent. |
|
|
The session token cache can be used when decrypting the user's session token on the Access Server. If enabled, the Access Server checks if the decrypted session token resides in the cache. If not, the Access Server decrypts the incoming session token. For a description of the session token, see "Single Sign-On Cookies". |
|
|
The maximum number of decrypted session tokens that can be kept in the cache. This cache should be tuned periodically because the cache can become very large if the Access System manages many users and the activity rate is high. The default value is 10,000. |
Before installing the Access Server, you must add a new instance in the Access System Console. At this time, you need only specify the Access Server name, hostname, port, and transport security mode. After installation, you can modify the configuration.
The following procedure describes how to add and configure the instance.
Note:
You must add the Access Server instance to the Access System Console before installing the component.To add an Access Server instance
From the Access System Console, select Access System Configuration, then click Access Server Configuration.
The Access Server Configuration page appears.
Click Add.
The Add a New Access Server page appears.
You must enter information in the Name, Hostname, and Port fields. All other fields are optional.
In the Name field, type a name for this server.
Type an alphanumeric string without spaces.
Note:
You cannot give the same name to an AccessGate and an Access Server.In the Hostname field, type the name or IP address of the computer hosting this server.
In the Port field, type the port number of the computer hosting this server.
Click On to capture all messages sent from each AccessGate and Policy Manager to this Access Server.
The messages are stored in a Debug file if a Debug file is provided. Otherwise, the messages are printed out to stderr.
Click Off if you do not want to capture this information.
Capturing messages confirms that communication is taking place between AccessGate instances and this Access Server.
Note:
Capturing debug messages records user passwords, a potential security problem, and causes the Access Server log file to grow rapidly. Use debugging only when diagnosing a problem.In the Debug File Name field, type the path to this Access Server's debug file.
In the Transport Security field, select a method for encrypting messages between this Access Server and the AccessGates it is configured to talk to.
For AccessGates and Access Servers that are configured to communicate with each other, be sure to choose the same encryption method.
Your choices are Open mode, Simple mode, or Cert mode.
For a description of configuring transport security modes, see the Oracle Access Manager Administration Guide.
In the Maximum Client Session Time (hours) field, type the number of hours that a connection between an AccessGate and this Access Server can last.
The default is 24 hours.
The longer the session time, the more vulnerable your system is to attack.
In the Number of Threads field, type the number of threads this Access Server will start.
The default entry is 100. The minimum is 1.
Beside Policy Manager API Support Mode, select the option for your environment.
Setting the Policy Manager API Support Mode to "On" enables the Policy Manager engine in the server. The Access Server starts servicing Policy Manager API requests from AccessGates for policy management. See "AccessGate Configuration Parameters" on page 3-18 for details.
Choose the Auditing option you want for your environment:
Audit to Database (on/off)— Selecting On requires specific configuration in the Access System, plus installation of a supported database, as described in the Oracle Access Manager Administration Guide.
Audit to File (on/off)—Selecting On requires specification of the following additional items:
Audit File Name—Type the path to this Access Server's audit file. The file is stored on the computer hosting this Access Server. Each Access Server has its own audit file. The information captured for the file is determined by the Master Audit Rule. See "About the Master Audit Rule" for details.
Audit File Size (bytes)—Type a number representing the number of bytes this audit file can hold. If you change the default size, you need to restart the server after committing the change. When the maximum size is reached, the current file is closed and stamped with the date and time, and a new audit file with the original name is created.
In the Buffer Size (bytes) field, type a number representing the number of bytes that the audit file's buffer can hold.
The default is 512000. Using a buffer increases performance by reducing the number of times information is read to the audit file.
If you type a value in this field, audit information is stored in the buffer before it is written to the audit file. When the buffer reaches the size you specify, it transfers its contents into the audit file.
If you enter 0 in this field, audit information is written directly to the audit file.
In the File Rotation Interval (seconds) field, type a number representing the number of seconds that this audit file can exist.
The default is 0. A setting of 0 means that the audit file never times out, and audit information continues to be added to the file.
When the limit is reached, this file is rotated, which means it is closed, stamped with the date and time, and a new audit file with the original name is created.
In the Engine Configuration Refresh Period (seconds) field, type a value in seconds to indicate the frequency with which configuration changes to this server take place.
The default is 14400. A setting of 14400 means the audit file name and related parameters are refreshed once every 4 hours. If set to 0, they are never refreshed. They are loaded when the server comes up and remain the same while the server is up.
The changes are implemented with the frequency you indicate in this field. For example, if you type 600 seconds, configuration changes are implemented within 10 minutes.
For more information, see "Modifying Access Server Details".
Note:
Changes you make to this parameter do not take effect until the previous Engine Config Refresh Period has expired.In the URL Prefix Reload Period (seconds) field, type a number representing the frequency with which new URLs are recognized by this Access Server.
The default is 7200.
For example, if you type 600 in this field (600 seconds = 10 minutes), URLs are reloaded from the directory server every 10 minutes. This is helpful in cases where a particular URL Prefix cache flush request did not reach an Access Server.
In the Password Policy Reload Period (seconds) field, type a number representing the number of seconds that specifies the reload interval for the password policies.
The default is 7200.
In the Maximum Elements in User Cache field, type a number representing the number of authenticated users that can be saved in the Access Server's cache.
The default is 10000. A value of -1 disables the cache.
When the maximum is reached, the newest user activity is added to the cache, and the oldest is deleted.
In the User Cache Timeout (seconds) field, type a number representing the number of seconds that entries remain in the user cache until they are purged.
The default is 1800 (30 minutes). Setting the timeout to 0 means that the cache element never expires.
After the timeout on cached user entry has expired, the Access Server goes to the directory server to get user profile data needed during authentication actions and authorization actions.
In the Maximum Elements in Policy Cache field, type a number representing the number of items and activities associated with activities within policy domains, such as URLs mapped to specific rules, that can be cached.
The default is 100000.
When the maximum is reached, the newest user activity is added to the cache, and the oldest is deleted.
In the Policy Cache Timeout field, type a number representing the number of seconds that entries about policies can last before they are purged.
The default is 7200 (two hours).
In the SNMP State field, click On to enable SNMP or click Off to disable SNMP.
In the SNMP Agent Registration Port field, enter the port number for the SNMP Agent.
Indicate if the Session Token Cache is Enabled or Disabled.
If it is enabled, the Access Server stores the session token in the cache. For a description of the session token, see "Single Sign-On Cookies".
Indicate the maximum number of elements that can be stored in the session token cache.
You may need to tune this number periodically because this cache can become very large.
Click Save to save this new Access Server (or click Cancel to exit the page without saving).
Repeat the steps in this procedure for each Access Server that you want to install in your e-business infrastructure.
Now that you have created an Access Server instance, you can install this Access Server. When installing, use the Name, Hostname, and Port number information you typed in this page.
See the Oracle Access Manager Installation Guide for information on installing an Access Server.
A default directory profile is created for the Access Server during Access Server installation. For information on how to view or modify this profile, see information on directory profiles in the Oracle Access Manager Administration Guide.
If you install more than one Access Server instance, each server uses the same default directory server profile. If you modify a shared directory server profile for a particular Access Server instance, all of the other Access Server instances are affected. If you do not also change the profiles for these servers, you receive a warning whenever you:
View the server configuration
Restart the server
Reconfigure the server
Occasionally, you may need to change an Access Server's configuration settings. You can modify an Access Server instance through the Access System Console. If you change any field marked with an asterisk, you must restart the Access Server.
Note:
You cannot change an Access Server's name. To give an Access Server instance a new name, you must delete and uninstall the current instance, then create a new one.Launch the Access System Console.
Navigate to Access System Configuration, then click Access Server Configuration.
The Access Server Configuration page appears. The name, host, and port of each configured Access Server are listed on this page.
Click the link of the Access Server you want to modify.
On the Details for Access Server page, click Modify.
The Modify Access Server page appears. For details about all parameters, see "Access Server Configuration Parameters".
Enter new values (see "Adding an Access Server Instance".)
Select Update Cache to immediately send your changes to this Access Server's cache.
Click Save to save your changes (or click Cancel) and return to the previous page.
To remove an Access Server from your system, you must first delete its configured instance, then uninstall the Access Server.
When you delete an Access Server, all AccessGate instances that are configured to send requests to the server are automatically notified. Before deleting an Access Server, make sure that all AccessGate instances are configured to send requests to at least one other Access Server.
Launch the Access System Console.
Click Access System Configuration, then click Access Server Configuration.
The existing Access Servers are listed on the page.
Select the server you want to delete.
Click Delete.
You are prompted to confirm your decision.
Click OK to delete the instance (or click Cancel to stop the deletion).
Uninstall the Access Server.
In large Oracle Access Manager implementations, there can be thousands of AccessGates. Whenever a new Access Server is added, the administrator must manually configure all the AccessGates to communicate with the Access Server. In addition, the administrator must also configure failover and load balancing for the new Access Server, as described in the Oracle Access Manager Deployment Guide.
Grouping Access Servers into clusters reduces the time needed to manage these tasks, because Oracle Access Manager automatically performs some of the configuration tasks. After you create a cluster, you add Access Servers to it and then associate one or more AccessGates with the cluster. Oracle Access Manager automatically configures all the AccessGates associated with the cluster to communicate with all the Access Servers in the cluster.
If you are a Master Access Administrator or a Delegated Access Administrator with appropriate rights to manage Access Server clusters, you can:
Add an Access Server to multiple clusters.
Associate multiple AccessGates with a cluster.
Associate multiple clusters with an AccessGate.
Oracle Access Manager dynamically configures failover and load balancing for all the servers in a cluster and ensures that requests are routed to those Access Servers with the lightest load. For details about configuring failover, see the Oracle Access Manager Deployment Guide.
Note:
All Access Servers in a cluster and all AccessGates associated with the cluster must have the same transport security mode and Policy Manager API Support Mode.To add an Access Server cluster
Launch the Access System Console.
In the Access System Configuration page, click Access Server Clusters.
The existing Access Server clusters are listed on the page.
Click Add.
The Create a New Cluster of Access Servers page appears.
Enter a unique name for the cluster.
Select a transport security mode for the cluster.
Open mode is the default. You can select Open, Simple, or Cert. All Access Servers in a cluster must have the same transport security mode.
Specify the Policy Manager API Support Mode State.
On—Click the On button.
Off—By default, it is turned Off.
Note:
All Access Servers in a cluster must have the same Policy Manager API Support Mode.Click Next to go to the next page (or click Cancel if you do not want to save the cluster).
On the next page, select the Access Server that you want to add to the cluster by clicking an Access Server in the list.
The Access System only displays those servers that have the same security mode and Policy Manager API Support Mode as the one specified for the cluster.
Click the double right arrow (>>) button to add the Access Server to the cluster.
To remove an Access Server from the cluster, select it in the Access Servers in Clusters box and click the double left arrow (<<) button.
Click Save to save your changes, or click Cancel if you do not want to save your changes.
Click Back to return to the first page.
To view or modify an Access Server cluster
Launch the Access System Console and click Access Server Clusters.
The existing Access Server clusters are listed on the page.
Click a cluster to view its details.
The Details for Access Server Cluster page appears. The details of Access Servers in the cluster are listed.
Click Modify to modify a cluster's details.
The Modify Cluster page appears.
You can add or delete Access Servers.
To add an Access Server to the cluster, select the server from the Available Access Servers list and click the >> button to add it to the cluster.
To remove an Access Server from the cluster, select the server in the Access Servers in Cluster box and click the << button to remove it from the cluster.
Click Save (or click Cancel if you do not want to save your changes).
You can perform an automated installation of the Access Server using a file that contains installation parameters and values. This is called installing in silent mode. Silent mode permits installation without user intervention.
To install an Access Server in silent mode
At the command line, enter the following command:
configureAAAServer.exe install install_dir -S -f aaa_input.xml
where aaa_input.xml is a file that contains installation parameters and values.
The Access System provides two sample input files named aaa_input.xml and silent-mode-sample-AAA-Input.xml. The files are located in:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
where AccessServer_install_dir is the directory in which the Access Server is installed. For information on silent mode, installation, see the Oracle Access Manager Installation Guide.
You can perform Access Server-related administration tasks through a command-line tool called configureAAAServer. This tool can be used in both Windows and Solaris installations.
Commands that you can use with configureAAAserver tool:
install
reconfig
chpasswd
remove
Windows Systems—Use the remove and install commands to remove or re-install an Access Server Service.
Non-Windows Systems—Use the start_configureAAAServer script to invoke the configureAAAServer tool. To see the options, you can run this tool without any options.
To access the configureAAAserver tool
Navigate to the folder where configureAAAserver is located.
The default location is:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
Note:
On non-Windows systems, use start_configureAAAServer.Use the configureAAAserver tool in a procedure, as needed.
To reconfigure an Access Server
Navigate to the folder where configureAAAserver is located.
For example:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
Run the following executable:
configureAAAServer reconfig AccessServer_install_dir
Specify the following when prompted:
The transport security mode in which you want Access Server to run
The transport security mode in which the directory server is running
The host machine on which the directory server resides
The port number on which the directory server listens
The bind DN of the directory server
The password of the directory server
The directory server to which you are connecting
The location where configuration data is stored
The configuration DN
The policy base
The Access Server ID
See "Configuring the Directory Server" for information on directory server configuration.
Restart the Access Server.
Navigate to the folder where configureAAAserver is located.
The default location is:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
where AccessServer_install_dir is the directory where the Access Server was installed.
Run the following executable:
configureAAAServer reconfig AccessServer_install_dir
You are then asked if you want to specify failover information for configuration or policy data.
Select Yes (Y).
Specify whether the data is stored in the configuration directory tree, or the policy tree.
The following options appear:
Add a failover server
Modify a failover server
Delete a failover server
Modify common parameters
Quit
Select Modify common parameters.
Specify values for the following common configuration parameters as needed:
Maximum Connections—The maximum number of connections that an Access Server can establish with the associated directory servers for load balancing.
Sleep For (seconds)—The frequency with which the Access Server checks its connections to the directory server. For example, if you set a value of 60 seconds, the Access Server checks its connections every 60 seconds from the time it comes up.
Failover Threshold—The number representing the point when the Access Server opens a new connection to a directory server. For example, if you type 3 in this field, and the number of connections from the Access Server to the directory server falls to 2, a new connection is opened between the Access Server and the configured directory servers.
Maximum Session Time—The maximum period of time that a session between an Access Server and a directory server is valid.
For more information, see the Oracle Access Manager Deployment Guide.
Select Quit to exit.
You are prompted to commit the changes.
Select Y to commit your changes (or select N to cancel your changes).
To remove an Access Server service
Navigate to the folder where configureAAAserver is located.
The default location is:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
Note:
On non-Windows systems, use start_configureAAAServer.From the command line, run the following executable:
configureAAAServer remove AccessServer_install_dir serviceName
where AccessServer_install_dir is the directory in which the Access Server was installed and serviceName is the name of a service such as AccessManager_AccessServer.
A message appears stating that the registry entries are being removed. This confirms that the Access Server has been removed.
Note:
The serviceName variable is applicable only for Microsoft Windows. The serviceName is the name you specify for the Access Server on the Access System Console.To re-install an Access Server service
Navigate to the folder where configureAAAserver is located, for example:
AccessServer_install_dir\access\oblix\tools\configureAAAServer
Note:
On non-Windows systems, use start_configureAAAServer.From the command line, run the following executable:
configureAAAServer install AccessServer_install_dir serviceName
where AccessServer_install_dir is the directory in which the Access Server was installed and serviceName is the name of a service such as AccessManager_AccessServer.
Specify the following:
Whether or not you want to reconfigure the Access Server
The transport security mode for the Access Server
The transport security mode for the Oracle Access Manager directory server
The host machine on which the directory server resides
The port number on which the Oracle Access Manager directory server resides
The bind DN of the directory server
The password of the directory server
The directory server to which you are connecting
The configuration DN
The location of the policy data
The policy base
The Access Server ID
Note the name of the Access Server service.
A message appears stating that the Access Server has been successfully installed.
Start the Access Server from the Windows Control Panel services.
Requests are queued as they are sent to an Access Server. A thread processes each request. For example, if you have two request queues and 60 threads, the Access Server spawns 120 threads.
You cannot specify the number of queues in the Access System Console. When you configure an Access Server, however, you specify the number of threads in the Number of Threads field. The default setting is 60.
Use a command line entry to specify the number of queues each Access Server can support. Keep the number of queues in balance with the number of threads. Typically, one queue is adequate for each WebGate.
A command is available with Solaris, Windows 2000, or Windows NT. On Solaris, you open a shell window to use this command. On Windows, use the Start Parameter field in the Services window to use this command.
Tip:
Additional information on threads and queues is provided in the Oracle Access Manager Deployment Guide.To set the number of queues on Solaris
Open a shell window.
At the command line, enter the following command:
start_access_server -QN
where N is the number of queues.
To set the number of queues on Windows 2000
Navigate to Start, Programs, Administrative Tools, Services, and then COREidAAAServerID.
Right-click COREidAAAServerID and select Properties.
The Properties window appears.
To specify the number of queues, in the General tab, enter
-QN
where N is the number of queues in the Start Parameter field.
To set the number of queues on Windows NT
Navigate to Start, Control Panel, Services, and then COREidAAAServerID
where ID is the name of the Access Server.
Right-click COREidAAAServerID and select Properties.
The Properties window appears.
To specify the number of queues, in the General tab, enter
-QN
where N is the number of queues in the Start Parameter field.
At least one Access Server and one AccessGate must be configured and installed for the Access System to run. The AccessGate that you configure can be a WebGate, which is an out-of-the-box AccessGate for http resources. The Access Server must be installed before you install the AccessGate.
The rest of this section discusses the following topics:
Task overview: Configuring an AccessGate
Create one or more AccessGate instances in the Access System Console, as described in "Adding an AccessGate".
Associate each AccessGate instance with an Access Server, as described in "Associating AccessGates and WebGates with Access Servers".
Install an AccessGate for each instance that you created in the Access System Console, as described in the Oracle Access Manager Installation Guide.
Change the AccessGate settings as needed, as described in "Modifying a WebGate".
Note:
When configuring a WebGate, Oracle recommends setting DenyOnNotProtected to true to ensure that Web content is protected. See "Denying Access to All Resources by Default" for details.You can view existing AccessGates in the Access System Console by searching for the AccessGate.
You use a Search page to search for an AccessGate by any of its attributes. Depending on the attribute you select, the search conditions and values vary. For example, if you select Security as your search attribute, Equals may be the condition that is displayed in the list, and the possible values would be one of the available security modes. The system then displays the existing AccessGates that have been configured with the specified security mode.
The search attributes, conditions, and values for an AccessGate are listed in Table 3-2.
Table 3-2 AccessGate Search Attributes, Conditions, and Values
Launch the Access System Console and click Access System Configuration, and then click AccessGate Configuration.
The Search for AccessGates page appears.
The Search list contains a selection of attributes that can be searched, as described in Table 3-2.
The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Select the search attribute and condition from the lists (or click the All button to find all AccessGates).
Click Go.
The search results are displayed on the page.
Click an AccessGate's name to view its details.
The configuration details of the AccessGate appear.
To view the AccessGates associated with an Access Server
Launch the Access System Console and click Access System Configuration, then click Access Server Configuration.
The Access Server Configuration: List all Access Servers page appears.
Click the link for the desired Access Server.
The Details for Access Server page appears.
Click the View Associated AccessGates button at the bottom of the Details for Access Server page.
The AccessGates associated with server page appears.
Check Primary Server to view AccessGates for which the Access Server is configured as a primary server.
Check Secondary Server to view AccessGates for which the Access Server is configured as a secondary server.
Select All to list all the specified AccessGates, or enter a number to specify the number of search results you want displayed on the page.
Click Go to display the search results.
The details of the AccessGates associated with the Access Server are displayed on the page.
If there are multiple pages, click Next to go to the next page, or click Previous to go back to the previous page.
Click Back to return to the Access Server page.
Table 3-3 summarizes the AccessGate configuration parameters:
Table 3-3 AccessGate Configuration Parameters
| Field | Description |
|---|---|
|
Name of the AccessGate. |
|
|
Additional information to identify this AccessGate. |
|
|
Whether or the AccessGate is enabled or disabled. |
|
|
Name of the machine hosting the AccessGate. |
|
|
Optional, for information only. Identifies the Web server port protected by the AccessGate when deployed as a WebGate. This field should be empty for an AccessGate configuration that supports an application using the Access Manager SDK. |
|
|
Optional, unique password for the AccessGate, created when you defined the AccessGate in the Access System Console. When the AccessGate connects to an Access Server, it uses the password to authenticate itself to the Access Server. This prevents unauthorized AccessGates from connecting to Access Servers and obtaining policy information. |
|
|
Turns debugging on or off. |
|
|
Maximum amount of time in seconds that a user's authentication session is valid, regardless of their activity. At the expiration of this session time, the user is re-challenged for authentication. This is a forced logout. Default = 3600 A value of 0 disables this timeout setting. |
|
|
Amount of time in seconds that a user's authentication session remains valid without accessing any AccessGate protected resources. Default = 3600 A value of 0 disables this timeout setting. |
|
|
The maximum number of connections that this AccessGate can establish with Access Servers. This number must be the same as or greater than the number of Access Servers that are actually associated with the WebGate. Default = 1 |
|
|
Level of transport security to and from the Access Server, can be set to: |
|
|
IP address validation is specific to WebGates and is used to determine whether a client's IP address is the same as the IP address stored in the ObSSOCookie generated for single sign-on. See "Configuring IP Address Validation for WebGates" for details. |
|
|
IPValidationException is specific to WebGates. This is a list of IP addresses that are excluded from IP address validation. It is often used for excluding IP addresses that are set by proxies. See "Configuring IP Address Validation for WebGates" for details. |
|
|
Connection maintained to the Access Server by the AccessGate. If you are deploying a firewall (or another device) between the AccessGate and the Access Server, this value should be smaller than the timeout setting for the firewall. Default: 24 hours. |
|
|
Number representing the point when this AccessGate opens connections to Secondary Access Servers. If you type 30 in this field, and the number of connections to primary Access Servers falls to 29, this AccessGate opens connections to secondary Access Servers. |
|
|
Applicable only to WebGates. Number in seconds to wait for a response from the Access Server. If this parameter is set, it is used as an application TCP/IP timeout instead of the default TCP/IP timeout. For example, suppose a WebGate is configured to talk to one primary Access Server and one secondary Access Server. If the network wire is pulled from the primary Access Server, the WebGate waits for the TCP/IP timeout to learn that there is no connection to the primary Access Server. The WebGate tries to reestablish the connections to available servers starting with the primary Access Server. Again, the WebGate waits for the TCP/IP timeout to determine if a connection can be established. If it cannot, the next server in the list is tried. If a connection can be established to another Access Server (either a primary or secondary), the requests are re-routed. However this can take longer than desired. Rather than rely on the default TCP/IP timeout, you can specify the Access Server Timeout Threshold in the Access System Console, Access System Configuration, AccessGate Configuration. The default value of -1 means the default network TCP/IP timeout is used. A typical value for this parameter is between 30 and 60 seconds. If set to a very low value, the socket connection can be closed before a reply from Access Server is received, resulting in an error. When finding new connections, WebGate checks the list of available servers in the order specified in its configuration. If there is only one primary Access Server and one secondary Access Server specified, and the connection to the primary Access Server times out, the WebGate still tries the primary Access Server first. As a result, the WebGate is unable to send requests to an Access Server for a period greater than twice the setting in the Access Server Timeout Threshold. If the Access Server takes longer to service a request than the value of the timeout threshold, the WebGate abandons the request and retries the request on a new connection. Note that the new connection that is returned from the connection pool can be to the same Access Server, depending on your connection pool settings. Also, other Access Servers may also take longer to process the request than the time specified on the threshold. In these cases, the WebGate can continue to retry the request until the Access Servers are shut down. You can control the number of retry attempts with the user-defined parameter client_request_retry_attempts. See "Configuring User-Defined Parameters" for details. |
|
|
Number in seconds that represents how often this AccessGate checks its connections to Access Servers. For example, if you set a value of 60 seconds for the Sleep For parameter, AccessGate checks its connections every 60 seconds from the time it comes up. |
|
|
Number of elements maintained in the cache. Cache elements are the following:
The value of this setting refers to the maximum consolidated count for elements in both of these caches. Default = 10000 |
|
|
Amount of time cached information remains in the AccessGate cache when neither used nor referenced. Default = 1800 |
|
|
The name of the trusted user that you created to be user for impersonations. The value should contain the domain name, for example, testdomain@user.net. You specify the trusted username here to bind it to this AccessGate (WebGate) so that the AccessGate can use it for impersonation. For information about impersonation and explanation of how to create a trusted user for impersonation, see the Oracle Access Manager Integration Guide. |
|
|
The password for the trusted user to be used for impersonation. You must enter this password twice; that is, you are asked to re-type it. |
|
|
This parameter determines whether Policy Manager API Support Mode is enabled.
Select On to enable the server's Policy Manager engine. The Access Server then starts servicing Policy Manager API requests from AccessGates for policy management. |
|
|
This parameter describes the Web server domain on which the AccessGate is deployed, for instance, .mycompany.com. You must configure the cookie domain to enable single sign-on among Web servers. Specifically, the Web servers for which you configure single sign-on must have the same Primary HTTP Cookie Domain value. The Access System uses this parameter to create the ObSSOCookie authentication cookie. This parameter defines which Web servers participate within the cookie domain and have the ability to receive and update the ObSSOCookie. The WebGate cookie domain parameter is not used to populate the ObSSOCookie; rather it defines which domain the ObSSOCookie is valid for, and which Web servers have the ability to accept and change the ObSSOCookie contents. |
|
|
This required field determines how the host name appears in all HTTP requests as they attempt to access the protected Web server. The host name in the HTTP request is translated into the value entered into this field regardless of the way it was defined in a user's HTTP request. There are special considerations for field if you use virtual hosting. See "Configuring Virtual Web Hosting" for details. Except for casess where virtual hosting is required, Oracle recommends that you always specify a value in the Preferred HTTP Host field for each WebGate, and ensure that it maps to a host name in the Host Identifiers field. You use the host identifiers when defining policies. See also, "Configuring Preferred HTTP Hosts, Host Identifiers, and Virtual Web Hosts". |
|
|
This setting applies only to WebGates. The default value for this parameter is false. In this case, there is no protection, and access is enabled. More importantly, access may be granted inadvertently. For example, if someone attempts to access a resource using the decimal value of an IP address in the URL, access may be granted unless the host identifier includes this representation of the address. Setting DenyOnNotProtected to true is the most secure way to protect Web server content. If you set DenyOnNotProtected to true, all requests for Web pages on the Web server protected by the WebGate are denied unless access is explicitly allowed by a policy. When this is set to true, you need to create an anonymous authentication method and allow access to content using an anonymous access policy. For information describing how to use the DenyOnNotProtected switch, see "Denying Access to All Resources by Default". |
|
|
This setting applies only to WebGates. These settings control the browser's cache. By default, CachePragmaHeader and CacheControlHeader are set to no-cache. This prevents WebGate from caching data at the Web server application and the user's browser. However, this may prevent certain operations such as downloading PDF files or saving report files when the site is protected by a WebGate. You can set the Access Manager SDK caches that the WebGate uses to different levels. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html section 14.9 for details. All of the cache-response-directives are allowed. For example, you may need to set both cache values to public to allow PDF files to be downloaded. |
|
|
This setting applies only to WebGates. The LogOutUrls parameter enables you to configure one or more specific URLs that log out a user. You can provide a portal logout URL for this parameter. For example, suppose that a finance portal is protected by a Webgate, and the portal logout page is finance_exit.html. If you add finance_exit.html as a LogOutUrls entry, users who are logged out of the finance portal are also logged out of Oracle Access Manager. Oracle recommends that you provide the SSO Logout URL as one of the values for the LogOutUrls parameter. This will add consistency and enable a global logout value for multi-domain single sign-on implementations. See "Configuring Logout for an Identity System Resource" for details. Also, if you have configured a WebGate to protect a WebPass or Policy Manager, the LogOutUrls parameter must contain the SSO Logout URL values. This is required since the WebPass or Policy Manager logout button redirects the user to the SSO Logout URL. |
|
|
These settings apply only to WebGates. As of Oracle Access Manager 10.1.4, the WebGateStatic.lst file is no longer present. Some of the parameters that were set in WebGateStatic.lst are now specific data entry fields in the AccessGate configuration page. Others have been made available as user-defined parameters on this page. See "Configuring User-Defined Parameters" for details. |
You must add an AccessGate instance in the Access System Console before installing the AccessGate. Required parameters before installation include the AccessGate name, hostname, transport security mode, and the preferred HTTP host. All other AccessGate parameters can be configured after installation, as described in the following sections.
See "AccessGate Configuration Parameters" for details about all parameters. See the Oracle Access Manager Installation Guide for details about installing an AccessGate.
Note:
Once you assign and save an AccessGate name, you cannot change the name. To rename an AccessGate, you must delete and uninstall the instance, then create a new AccessGate.To create an AccessGate instance
Launch the Access System Console and click Access System Configuration.
Click Add New AccessGate in the left navigation pane.
The Add New AccessGate page appears.
Fill in the form as follows:
AccessGate Name: Type the name of this AccessGate instance. Type an alphanumeric string without spaces. Note that an AccessGate and an Access Server cannot have the same name.
Description: Type a summary that will help you identify this AccessGate later on.
Hostname: Type the name or IP address of the server hosting this AccessGate.
Port: Type the Web server port protected by the AccessGate when deployed as a WebGate.
This field is optional and is provided for informational purposes only. It is recommended that you enter the Web server port number for a WebGate. Other AccessGates may or may not use a port.
This field must be empty when the AccessGate describes the configuration in support of an application using the Access Manager SDK.
AccessGate Password: Type an alphanumeric string to represent a password for this AccessGate.
The AccessGate uses this password to identity itself to an Access Server. If you provide a password here, you must enter the same password when re-configuring the AccessGate and during AccessGate installation.
Note:
If this AccessGate is a WebGate, this password must be the same one specified when you installed the WebGate.Re-type AccessGate Password: Re-type the password.
If the entries in these two steps do not match, when you click Save, an error message appears, and you must repeat this process.
Debug: The Debug field is relevant only for WebGates.
In this field:
Click On to write debug messages between the AccessGate and Access Server to the standard out for most platforms. Note that on IIS this information is not written to the standard out because the IIS server runs as an NT service.
Click Off if you do not want to capture this information.
Important:
Capturing debug messages records user passwords, a potential security problem, and causes the Access Server log file to grow rapidly. Debugging should only be turned on when diagnosing a problem.Maximum user session time: Type the maximum amount of time, in seconds, that a user's authentication session is valid, regardless of their activity. At the expiration of this session time, the user is re-challenged for authentication. This is a forced logout.
The default is 3600.
Idle Session Time: Type the amount of time in seconds that a user's authentication session remains valid without accessing any AccessGate protected resources.
The default is 3600.
Maximum Connections: Type the maximum number of connections this AccessGate can establish with associated Access Servers. This number may be greater than the number allocated at any given time.
The default is 1.
Transport Security: Select a method for encrypting messages between this AccessGate and the Access Servers it is configured to talk to.
For AccessGates and Access Servers that are configured to communicate with each other, be sure to choose the same encryption method.
Your choices are:
For a description of configuring transport security modes, see the Oracle Access Manager Administration Guide or see the table of AccessGate configuration parameters in "AccessGate Configuration Parameters" .
Note:
If you want to change an AccessGate mode from simple or cert to open, you must move the /oblix/config/simple directory (if in simple mode) or the /oblix/config/*.pem files (if in cert mode) to a new folder. Then you must run the configureAccessClient program.Supply IPValidation for a WebGate to determine if a client IP address is the same as the IP address stored in the ObSSOCookie generated for single sign-on.
See "Configuring IP Address Validation for WebGates" for details.
Supply values for IPValidationException if you want to supply IP addresses to exclude from IP address validation.
See "Configuring IP Address Validation for WebGates" for details.
Maximum Client Session Time: Specify the connection maintained to the Access Server by the AccessGate.
If you selected Open in the Transport Security field, this field is ignored.
If the Maximum Client Session Time is 0, the AccessGate establishes a new connection to the Access Server for each request that it makes to the Access Server. There may be more than one AccessGate request for each user request to the AccessGate.
The default is 24 hours. This value must be larger than the Sleep For parameter. Using the same session key for longer than 24 hours can make your system vulnerable to attack.
Failover Threshold: Type the number representing the point when this AccessGate opens connections to secondary Access Servers. If you type 30 in this field, and the number of connections to primary Access Servers falls to 29, this AccessGate opens connections to secondary Access Servers.
You can type a number ranging from 1 to the total number of primary servers. If you do not type a value, the number of maximum connections is used.
For details about configuring failover, see the Oracle Access Manager Deployment Guide.
Access Server timeout threshold: Applicable only to WebGates. Specify the time (in seconds) during which the AccessGate must wait for a response from the Access Server. If this parameter is set, it is used as an application TCP/IP timeout instead of the default TCP/IP timeout.
Sleep For (seconds): Type a number (in seconds) that represents how often this AccessGate checks its connections to Access Servers.
If a connection to an Access Server is broken, but the AccessGate finds that the Access Server is now up, it tries to reconnect to that server.
The default is 60 seconds. The shorter the value, the quicker AccessGate can reestablish a connection to an Access Server that has come back up. But the overhead for checking connections is higher.
An entry in this field does not affect failover to other servers, which is always immediate when needed.
Fill in caching details as follows:
Maximum elements in cache: Enter the maximum number of elements that can be maintained in the URL and authentication scheme caches. This number represents the grand total elements in both caches.
The default is 10000.
Cache timeout (seconds): Specify the time period during which cached information remains in the AccessGate cache when neither used nor referenced.
The default is 1800.
Complete impersonation details, as follows:
Impersonation username: Specify the name of the trusted user that you created to be used for impersonations. The name should contain the domain name, for example, testdomain@user.net. You specify the user name here to bind it to this AccessGate.
Impersonation password: Enter the password for the impersonation user name.
Re-type impersonation password: Enter the password for the impersonation user name.
For Policy Manager API Support Mode, set the state to On or Off.
See "AccessGate Configuration Parameters" for details.
Continue completing the information as follows:
Primary HTTP Cookie Domain: Type the AccessGate's domain name.
For example,
.yourcompany.com
Note:
The dot (".") in the initial position of the domain name is required. See "Configuring Single Sign-On" for information on how the primary HTTP cookie domain is used.Preferred HTTP Host: Specify how the hostname appears in all HTTP requests as they attempt to access the protected Web server. The hostname within the HTTP request is translated into the value entered into this field regardless of the way it was defined in a user's HTTP request.
The Preferred Host function prevents security holes that can be inadvertently created if a host's identifier is not included in the Host Identifiers list. However, it cannot be used with virtual Web hosting. For virtual hosting, you must use the Host Identifiers feature.
Unless you disable the preferred HTTP host feature, you must enter one of the variations entered in the Host Identifiers feature to ensure that single sign-on works properly. See "Configuring Preferred HTTP Hosts, Host Identifiers, and Virtual Web Hosts" and "Configuring Virtual Web Hosting" for details.
DenyOnNotProtected: This setting applies only to WebGates. Specify true to deny all access to resources on the Web server protected by WebGate unless access is allowed by a policy. A value of true requires that you set an anonymous authentication method and allow access to content using an anonymous access policy. See "Denying Access to All Resources by Default" for details.
CachePragmaHeader: This setting applies only to WebGates. See "AccessGate Configuration Parameters" for details.
CacheControlHeader: This setting applies only to WebGates. See "AccessGate Configuration Parameters" for details.
LogOutUrls: This setting applies only to WebGates.
To ensure that users log out completely from Identity and Access applications when they click Logout, set the value of this parameter to the value of the SSO logout URL. See "AccessGate Configuration Parameters" and "Configuring Logout for an Identity System Resource" for details.
User-defined parameters: This setting applies only to WebGates. To configure the AccessGate to work with particular browsers, proxies, and so on, there are user-defined parameters that you can set. See "Configuring User-Defined Parameters" for details.
Click Save to save this new instance of AccessGate (or click Cancel to return to the previous page without saving).
Now that you have created an AccessGate instance, you can install and set up this instance. When installing, use the Name, Hostname, and Port number information you typed in this page. See the Oracle Access Manager Installation Guide for details.
When the Identity System applications are protected by a WebGate, a logout button is not automatically configured for the Policy Manager and the Identity System Console. You must configure the logout button and logout URL, as explained in the following procedure.
To configure the logout button
As described in "Configuring a Single Sign-On Logout URL", configure a URL that points to a logout page that you want to show to the user when they log out of the application.
Note:
Alternatively, you can specify the logout URL on the SSOLogoutURL parameter in the OblixBaseParams.lst file. This file is located in:PolicyManager_install_dir/access/oblix/apps/common/bin/To ensure that the WebGate logs out the user from the Identity or Access application when they click Logout, be sure that the LogOutUrls parameter is set to the same value as the SSO Logout URL.
See "Modifying an AccessGate" for details.
In earlier versions of Oracle Access Manager, a file named WebGateStatic.lst to configure various settings for a WebGate. The settings in this file have moved to the AccessGate configuration page. Some of the settings are displayed as static parameters on this page (for example, DenyOnNotProtected). Several of these settings now appear as user-defined parameters on the configuration page.
The user-defined parameters address the following issues:
Working with URLS that are encoded in UTF-8.
Working with Microsoft Passport or Integrated Windows Authentication on IIS.
Working with older Netscape Web servers.
Setting the frequency with which the shared secret is updated.
Preserving compatibility with NetPoint 5.x systems.
Working with reverse proxies that use SSL between the client and a reverse proxy and non-SSL between the reverse proxy and the Web server.
To implement user-defined parameters, you must enter them in the AccessGate configuration page and contact Oracle for a patch for the WebGate.
The following are the user-defined parameters:
UrlInUTF8Format—In an environment that uses Oracle HTTP Server 2, this parameter must be set to true to display latin-1 and other character sets.
UseIISBuiltinAuthentication—By default, this parameter value is false. Set UseIISBuiltinAuthentication to true only if you are using Microsoft Passport or Integrated Windows Authentication on this machine. It is used only for IIS, and is ignored if the WebGate is installed for another type of Web server.
SlowFormLogin—In some versions of the Netscape Web server, form login over https may not work as expected. In this case, the SlowFormLogin parameter eliminated the problem. This parameter is not necessary with the latest version of the Netscape Web server.
InactiveReconfigPeriods—The WebGate has an update thread that reads the shared secret from the Access Server every 1 minute when the WebGate is active. The Access Server server returns the shared secret in its own cache (the AAA cache). By default, this value is updated every 10 minutes. For example, the Access Server reads the shared secret from the directory at an interval of 10 minutes and this cached value is returned to WebGate. You can change this setting. See "Changing the WebGate Polling Frequency" for details.
In the idle state the WebGate reads the shared secret from the Access Server using the InactiveReconfigPeriod value. If this value is not set, the WebGate polls the Access Server for the shared secret value at an interval of 1 minute even though the updated shared secret value will be returned only after 10 minutes.
WaitForFailover—Used only for compatibility with NetPoint 5.x systems, this parameter has been replaced by Access Server TimeOut Threshold on the AccessGate configuration page (click Access System Console, Access System Configuration, then AccessGate Configuration).
Both the WaitForFailover parameter, and its replacement the Access Server Timeout Threshold parameter, control the TCP/IP timeout between the WebGate and the Access Servers it communicates with. The default value is "-1," which means the network default TCP/IP timeout value is used.
Be sure that both the WaitForFailover parameter and the Access Server Timeout Threshold configured on this page use the same value.
GetProxySSLStateHeader—This parameter is used when the WebGate is located behind a reverse proxy, SSL is configured between the client and the reverse proxy, and non-SSL is configured between the reverse proxy and the Web server. It ensures that URLs are stored as https rather than http. This parameter ensures that URLs are stored in https format by setting a custom header variable named GetProxySSLStateHeader with a value of ssl in an SSL-enabled proxy server. If the header variable is not set, the SSL state is decided by the SSL state of the current Web server.
client_request_retry_attempts—A WebGate-to-Access Server timeout threshold specifies how long (in seconds) the WebGate waits for the Access Server before it considers it unreachable and attempts the request on a new connection. If the Access Server takes longer to service a request than the value of the timeout threshold, the WebGate abandons the request and retries the request on a new connection. Note that the new connection that is returned from the connection pool can be to the same Acess Server, depending on your connection pool settings. Also, other Access Servers may also require more time to process the request than the time specified on the timeout threshold. In some cases, the WebGate can retry the request until the Access Servers are shut down. You can configure a limit on the number of retries that the WebGate performs for a non-responsive server using the client_request_retry_attempts parameter. The default value for this parameter is -1. Setting the parameter value to -1 (or not setting it at all) allows an infinite number of retries.
The WebGate-to-Access Server configuration polling reduces the traffic between both the WebGate and Access Server and the Access Server and the LDAP directory server.
Process overview: WebGate-to-Access Server configuration polling
When the WebGate is inactive for 60 seconds, it reduces the frequency of polling for its configuration information.
The polling frequency is determined by the parameter InactiveReconfigPeriod, which is a user-defined parameter that is set in the AccessGate configuration page. See "Configuring User-Defined Parameters" for details. The value for InactiveReconfigPeriod is specified in minutes. Within ten seconds of resuming activity, the WebGate performs reconfiguration polling once a minute.
At startup, the WebGate checks the bootstrap configuration to see if any important parameters have changed.
This makes the re-initialization process unnecessary in most cases and reduces the transient Access Server load.
WebGate and Access client configurations are cached in the Access Server.
The default cache timeout is 59 seconds. This should cause no modifications to the system behavior on non-Apache Access clients. The Apache Web server with WebGate avoids unnecessary hits to the directory server. The caching parameters can be set in the oblix/apps/common/bin/globalparams.xml file. The parameter clientConfigCacheMaxElems sets the maximum size of the cache (default 9999). The parameter clientConfigCacheTimeout determines the maximum lifetime of any element in the cache (default 59 seconds).
There are two ways to reduce off-time network traffic between both the WebGate and Access Server and the Access Server and the LDAP directory server:
Changing WebGate polling frequency for configuration information.
Changing the default configuration cache timeout for WebGate and Access client configurations that are cached in the Access Server.
One way to reduce off-time network traffic between both the WebGate and Access Server and between the Access Server and the LDAP directory server is to change the WebGate polling frequency for configuration information.
To change the configuration polling frequency
Add the InactiveReconfigPeriod parameter to the configuration page for this WebGate.
Specify the value for InactiveReconfigPeriod in minutes.
The default is 1 minute. When the WebGate is inactive for more than 60 seconds (for example, when no authentication requests are being processed), it reduces the frequency of polling for its configuration information. Within ten seconds of resuming activity, the WebGate resumes reconfiguration polling once every minute.
If set to -2, Webgate never polls.If set to a value greater than 0 it polls at the specified interval.If set to -1 and Webgate is inactive and has been for 1 minute, then Webgate does not poll. WebGate resumes reconfiguration polling when it returns to an active state.
Occasionally you may need to modify an AccessGate's parameters. You can modify an AccessGate through the Access System Console or through a command line tool named configureAccessGate. Typically, you use the command line tool to change the transport security mode. This tool can be used in both Windows and Solaris installations.
Note:
If you change fields marked with an asterisk(*), you must restart the server hosting this AccessGate. Once you assign and save an AccessGate name, you cannot change the name. To rename an AccessGate, you must delete and uninstall the instance, then create a new AccessGate.To modify an AccessGate through the Access System Console
Launch the Access System Console and click Access System Configuration, and then click AccessGate Configuration.
The Search for AccessGates page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
The Search list is a selection list of attributes that can be searched, as described in Table 3-2. The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
Click the name of the AccessGate you want to modify.
The AccessGate Details page appears.
Click Modify.
The Modify AccessGate page appears. You can enter new information on this page
You cannot change an AccessGate's name. To rename an AccessGate, you must delete it from the Access System Console and then uninstall it. You then create a new AccessGate.
Type new values as needed.
Click Save to save your changes (or click Cancel to exit the page without saving).
To modify an AccessGate through the command line
Go to:
AccessGate_install_dir\access\oblix\tools\configureAccessGate
where AccessGate_install_dir is the directory where AccessGate is installed.
From the configAccessGate directory, run the following command:
configureAccessGate -i AccessGate_install_dir -t AccessGate|WebGate options
Specify parameters using the commands listed in Table 3-4.
Table 3-4 configureAccessGate and configureWebGate Commands
To reconfigure transport security mode through the command line
To reconfigure an AccessGate transport security mode, run the following command:
configureAccessGate -i AccessGate_install_dir -t <AccessGate|WebGate> -R
For example:
configureAccessGate -i C:\COREid\WebComponent\access -t AccessGate -R
The system prompts you to for a transport security mode:
| If you select Open. . . | If you select Simple. . . | If you select Cert. . . |
|---|---|---|
| The transport security mode is reconfigured to run in Open mode | 1. Supply the AccessGate password. If you specified a password during installation or reconfiguration of the AccessGate, enter it. If you did not, press Enter to skip the prompt.
2. Supply the Global Access Protocol Pass Phrase. After you enter it, the system generates and installs the certificate. |
1. Supply the AccessGate password. If you specified a password during installation or reconfiguration of the AccessGate, enter it. If you did not, press Enter to skip the prompt.
2. Supply the Global Access Protocol Pass Phrase. After you enter it, the system generates and installs the certificate. Next, complete the steps that follow. |
Note:
The Global Pass Phrase must always be the same for all AccessGates, WebGates, and Access Servers within an Access System installation.For Cert mode: The system prompts you to specify whether you want to request a certificate or install a certificate.
If you specify a certificate request, the system prompts you for the following organization information:
Country name
State or Province
Locality
Organization name
Organizational unit
Common Name:For example, HostName.DomainName.com
Email address
After you enter the information, a certificate request is generated and placed in the Component_install_dir\access\oblix\config\aaa_req.pem file.
where Component_install_dir is the directory in which the Access System component is installed.
You must have this certificate request signed by the Certificate Authority.
The system prompts you for the full paths to the location of the Certificate Key file, the Certificate file, and the Certificate Chain file.
After you specify the paths, the transport security mode is reconfigured.
To change the transport security mode password
From the command line, run the following command:
configureAccessGate -i AccessGate_install_dir -t AccessGate -k
Enter the following information:
The old password
The new password
Reconfirm the new password
The password is changed.
If you delete an AccessGate, the applications and content on the hosts with which it was connected are not be protected by the Access System. Be sure this is what you want to do before deleting an AccessGate.
Uninstall the AccessGate from the host.
Launch the Access System Console and click Access System Configuration, and then click AccessGate Configuration.
The Search for AccessGates page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
The Look For list is a selection list of attributes that can be searched, as described in Table 3-2. The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
Check the AccessGate that you want to delete and click Delete.
You are prompted to confirm your decision.
Click OK to delete the AccessGate (or click Cancel to stop the deletion).
A WebGate is an out-of-the-box Access Client for HTTP-based resources. A WebGate is an NSAPI or ISAPI plug-in that intercepts HTTP requests for Web resources and forwards them to the Access Server.
The process of configuring a WebGate is the same as configuring an AccessGate. See "Adding an AccessGate". The following topics provide additional information:
All Access Servers and their corresponding WebGates must be time-synchronized. Each secure request includes a timestamp.
For successful operation:
Ensure all machines are synchronized within 60 seconds.
Ensure each machine running a WebGate is not running ahead of the Access Servers with which it is associated.
Occasionally you may need to modify a WebGate's parameters. You can modify a WebGate through the Access System Console or through a command line tool named configureWebGate. Typically, you use the command line tool to change the transport security mode. This tool can be used in both Windows and Solaris installations.
To modify a WebGate through the command line
To modify a WebGate, navigate to the directory:
WebGate_install_dir\access\oblix\tools\configureWebGate
where WebGate_install_dir is the directory in which WebGate is installed.
From the configureWebGate directory, run the following command:
configureWebGate -i WebGate_install_dir -t WebGate
Specify parameters using the commands listed in Table 3-4.
Example of using configureWebGate
The following is an example of configuring a WebGate using the configureWebGate tool on Microsoft Windows:
C:\COREid\webcomponent\access\oblix\tools\configureWebGate> configureWebGate -i c:\COREid\webcomponent\access -t WebGate -w andium_AG -m cert -c install -S -P milpid -h andium -p 5160 -a andium_AS -r 99malibu -Z 5
IP address validation is specific to WebGates. It determines if a client's IP address is the same as the IP address stored in the ObSSOCookie generated for single sign-on. The IPValidation parameter turns IP address validation on and off. If IPValidation is true, the IP address stored in the ObSSOCookie must match the client's IP address, otherwise, the cookie is rejected and the user must reauthenticate. The default IPValidation setting is true.
The IPValidation parameter can cause problems with certain Web applications. For example, Web applications managed by a proxy server typically change the user's IP address, substituting the IP address of the proxy. This prevents single sign-on using the ObSSOCookie.
The IP Validation Exceptions parameter lists IP addresses that are exceptions to this process. If IPValidation is true, the IP address can be compared to the IP Validation Exceptions list. If the address is found on the exceptions list, it does not need to match the IP address stored in the cookie. You can add as many IP addresses as needed. These addresses are the actual IP addresses of the client, not the IP addresses that are stored in the obSSOCookie. If a cookie arrives from one of the exception IP addresses, the Access System ignores the address stored in the ObSSOCookie cookie for validation. For example, the IP addresses in the IP Validation Exceptions parameter can be used when the IP address in the cookie is for a reverse proxy.
To configure single sign-on between WebGate and an access client that does not have the client IP address at authentication, the IP validation can be explicitly turned off. To do this, you set IP Validation to false. When the IP Validation parameter is set to false, the browser or client IP address is not used as a part of the ObSSOCookie. However, Oracle recommends that you keep IP validation on whenever possible.
To configure the IPValidation parameter setting
From the Access System Console, click the tab for Access System Configuration.
Click AccessGate Configuration in the left navigation pane.
Find an AccessGate and click its link.
In the details page for this AccessGate, click Modify.
To turn off validation, in the IPValidation field, select the Off option.
To turn on validation, in the IPValidation field select the On option and in the IPValidationExceptions field enter any IP addresses that you want to exclude from validation.
Use standard notation, for example, 10.20.30.123 for the addresses. Press the plus or minus buttons to add or delete IP addresses.
A WebGate Diagnostic URL is available to display information regarding an Access Server connected to a WebGate. It also displays associated directory server information.
Diagnostic URL links are as shown in Table 3-5:
Table 3-5 Diagnostic URL links
| Platform | URL |
|---|---|
|
Domino |
http://WebGate_machine:portnumber/access/oblix/apps/webgate/
bin/webgate.cgi?progid=1
|
|
IIS |
http://WebGate_machine:portnumber/access/oblix/apps/webgate/ bin/webgate.dll?progid=1
|
|
Netscape and Apache |
http://WebGate_machine:portnumber/access/oblix/apps/webgate/ bin/webgate.cgi?progid=1
|
Where WebGate_machine is the machine in which the WebGate was installed and portnumber is the port number of the machine.
Note:
For IIS6, in order to use the Diagnostic URL feature, you must enable the direct access of webgate.dll through the IIS Lockdown tool.When you access this URL, your browser displays the information shown in Table 3-6:
Table 3-6 Information Displayed in the Browser After Entering the Diagnostic URL
| Topic | Description | |
|---|---|---|
|
Access Server |
Hostname of the Access Server, its port number, and the number of connections with this WebGate |
|
|
State |
Status of the Access Server, either Up or Down |
|
|
Created |
Date and time this Access Server was installed |
|
|
Install_Dir |
Installation directory of this Access Server |
|
|
Num Of Threads |
Maximum number of threads allowed on the Access Server |
|
|
Directory Information |
Directory |
Type of information stored in this directory instance, User, Policy, or Oblix |
|
Host:Port |
Hostname and port number of this directory instance |
|
|
State |
Operational status of the directory server, Up or Down |
|
|
Priority |
Priority of this Access Server to this WebGate, primary or secondary |
|
|
Mode |
Directory server connection mode, Open or SSL |
|
|
Size Limit |
Maximum entries the LDAP server returns for a search |
|
|
Time Limit |
How long an LDAP operation in the LDAP server runs |
|
|
Login DN |
Root DN of the directory server instance |
|
|
Created |
Date and time this directory server instance was created |
|
Depending on the type of Web server you use, you can issue a URL to check the status of a WebGate from any browser.
To check the status of a WebGate
Issue one of the following URLS in the browser:
On IIS:
http://servername:port/access/oblix/apps/webgate/bin/webgate.dll?progid=1
On iPlanet and Apache:
http://servername:port/access/oblix/apps/webgate/bin/webgate.cgi?progid=1
On Domino:
http://servername:port/access/oblix/apps/webgate/bin/nwebgate.dll?progid=1
If you modify the configuration of a WebGate or an AccessGate, the change takes effect in less than a minute. For example, if you add a new primary server and increase the number of connections to the Access Server by one, this happens without a restart of the server.
The old connections between the Access Server and the WebGate (or AccessGate) are discarded after a few minutes, when any pending requests are finished. If you issue a netstat command before the old connections are discarded, you might find double the number of connections since the server was started. However, this number quickly drops to the number of configured connections, usually in a few minutes. Every time that connection information is modified, the number of connections detected on a netstat command doubles for a few minutes, then drops back to the configured number.
You can use WebGates with reverse proxies.
The following are benefits of a reverse proxy:
All Web content can be protected from a single logical component as long as all requests go through the proxy.
This is true even for platforms that are not supported by Oracle Access Manager. If you have different types of Web servers (for example, iPlanet, Apache, and so on) on different platforms (for example, Windows XP, Linux, and so on), all content on these servers can be protected. A reverse proxy can be a workaround for unsupported Web servers, eliminating the need to write custom AccessGates for unsupported Web servers and on platforms that do not have WebGate support, for example, MacOS.
A reverse proxy offers architecture flexibility.
Reverse proxies can allow deployments to expose an application that is available on the intranet to the extranet. Or applications that are available on the extranet can be exposed to the intranet. This can be done without any changes to the application that is already deployed.
You only need to install a separate WebGate on the reverse proxy, rather than on every Web server.
This allows for a single management point and can help with manageability of the system. You can manage the security of all of the Web servers through the reverse proxy without establishing a footprint on the other Web Servers.
The main pitfall of using a proxy is the extra work involved in setup. If you deploy the WebGate on a Web server that is behind a reverse proxy, the following are configuration requirements:
Ensure that any Web server that uses the reverse proxy for authentication only accepts requests from the reverse proxies.
This will also require that WebGates deployed on this Web server be configured to not enforce IP validation for requests from the reverse proxy server that front-ends the WebGate. This is done by configuring the known IP addresses of the reverse proxy server or servers in the IP Validation list. Note that while you can achieve the same effect by turning IP validation off for the WebGate, this is not a recommended approach due to security risks.Ensuring that the Web server only accepts requests from reverse proxies is typically done by adding an ACL statement in the server. This prevents users from bypassing the reverse proxy and directly accessing restricted content.
Update the virtual hosts that are configured in the Policy Manager so that the Access System intercepts requests that are sent to the reverse proxy.
Prevent people from circumventing the proxy by entering URLs that point directly to the back-end system.
You can prevent this problem through the use of Web Server Access Control Lists or firewall filters.
Since all user requests are processed by the proxy, you must deploy enough proxy servers to enable the system to handle the load.
Redirect all existing URLs to the host name and port number of the reverse proxy server.
This often requires configuring the reverse proxy to perform content inspection and rewriting to prevent any absolute HTML links, for instance, to prevent broken link. This is achievable with most reverse proxies, and this is something you can configure independently of the Access System,.
It is a best practice that URL links exposed to the front-ended applications rely on only relative URLs (../../sub-path/resource) rather than absolute URLs (http://hostname.domain:[port]/path/resource).
Absolute URLs can break links on the end user's browser when deployed behind a reverse proxy.
You can associate an AccessGate with either individual Access Servers or with Access Server Clusters. For each AccessGate, you must select at least one Access Server or Access Server cluster with which it can communicate. The Access Server or the Access Server cluster must already be configured and installed.
Note:
The process of associating a WebGate is the same as the process of associating an AccessGate.You can view associated AccessGates in the Access Server details page or the Access Server Cluster details page. You can also view associated Access Servers and Access Server clusters in the AccessGate's details page. If there are any errors in the configuration between an AccessGate and an Access Server or an Access Server cluster, the error is displayed on the page.
For example, the security mode for an AccessGate could be different from the security mode of an associated Access Server or Access Server cluster. In such cases, the error is displayed on the page.
The rest of this section discusses the following topics:
When you associate an AccessGate with an Access Server cluster, the AccessGate automatically communicates with all the Access Servers in the cluster. When you disassociate an AccessGate from a cluster, the connections between the AccessGate and the Access Servers in the cluster are automatically deleted.
When you add an Access Server to a cluster, all the AccessGates associated with the cluster automatically communicate with the new Access Server. When you delete an Access Server from the cluster, the connection between the AccessGate and the Access Server is automatically deleted.
Load balancing is automatically configured, based on the number of connections that you specified when you configured the AccessGate and the number of Access Servers in the cluster. For details about configuring load balancing, see the Oracle Access Manager Deployment Guide.
Failover is automatically configured when you associate an AccessGate with an Access Server cluster that you define as a primary or a backup cluster. For details about configuring failover, see the Oracle Access Manager Deployment Guide.
Use the following procedures to associate an AccessGate with an Access Server or cluster.
Task overview: Associating an AccessGate with an Access Server or cluster includes
Associating the individual components, as described in "To associate an AccessGate with an Access Server"
Configuring the communication between the components, as described in "To configure an Access Server to communicate with this AccessGate"
Associating the AccessGate with a cluster, as described in "To associate an AccessGate with an Access Server cluster"
To associate an AccessGate with an Access Server
Launch the Access System Console and click Access System Configuration, then click AccessGate Configuration.
The Search for AccessGates page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
The Look For list is a selection list of attributes that can be searched, as described in Table 3-2. AccessGate Search Attributes, Conditions, and Values. The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
The AccessGate Details page appears.
If the AccessGate is not associated with any Access Server, do the following:
Click Associate Access Servers
The Associate Access Servers with AccessGate page appears.
Select Individual Servers to associate the AccessGate with an Access Server.
Click Next
The page lists all primary and secondary Access Servers configured to communicate with the AccessGate.
To configure an Access Server to communicate with this AccessGate
From the Access System Console, click the Access System Configuration tab, then click AccessGate Configuration in the left navigation pane.
Note:
Remember that you must configure and install an Access Server before it can receive requests from an AccessGate.Enter search criteria for an AccessGate, or click All in the search bar and click Go.
Click the link for an AccessGate that you want to modify.
Click List Access Servers.
Click Add.
From the list, select an Access Server.
In the Select priority field, choose Primary or Secondary to specify whether the Access Server is a primary server or a secondary server.
Enter the maximum number of connections this AccessGate can establish to this Access Server.
The default is 1.
Click Add to complete the configuration of this server, or click Back to return to the previous page.
To associate an AccessGate with an Access Server cluster
Launch the Access System Console and click Access System Configuration, and then click AccessGate Configuration.
The Search for AccessGates page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
The Search list is a selection list of attributes that can be searched, as described in Table 3-2. The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
Click the link for the AccessGate that you want to associate with an Access Server cluster.
The AccessGate Details page appears.
If the AccessGate is not associated with any clusters, do the following:
Click List Access Servers to see a list of configured Access Servers.
The page lists all primary and secondary (backup) Access Server clusters configured to communicate with the AccessGate.
Click List Clusters to associate the AccessGate with clusters.
The page lists all primary and backup clusters configured to communicate with the AccessGate.
Click Add to associate a Access Server cluster with the AccessGate.
The Add a new Access Server Cluster to the AccessGate page appears.
Note:
You must configure an Access Server Cluster before it can receive requests from an AccessGate.Select an Access Server cluster from the list.
In the Select Cluster Type field, choose Primary or Backup to specify whether the Access Server cluster is a primary cluster or a backup cluster.
The AccessGate opens connections to the Access Servers in the primary cluster. If the AccessGate cannot open the specified number of connections, it opens connections with the Access Servers in the backup cluster.
For details about configuring failover and load balancing, see the Oracle Access Manager Deployment Guide.
Click Save to save your changes (or click Cancel if you do not want to save your changes).
You can view AccessGates that are associated with a particular Access Server.
To view AccessGates associated with a cluster
Launch the Access System Console and click Access System Configuration, and then click AccessGate Configuration.
The Search for AccessGate page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
The Search list is a selection list of attributes that can be searched, as described in Table 3-2. The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
Click the link for an AccessGate.
Click List Clusters.
Click an Access Server cluster to view its details.
The Details for Access Server Cluster page appears.
In the Details for Access Server Cluster page, click View Associated AccessGates.
The Associated AccessGates page appears.
Select a Primary Cluster to view AccessGates for which the cluster is configured as a primary cluster.
Select a Backup Cluster to view AccessGates for which the cluster is configured as a secondary cluster.
Select All to list all the specified AccessGates or enter a number to specify the number of search results you want displayed on the page.
Click Go to display the search results.
The details of the AccessGates associated with the Cluster are displayed on the page.
If there are multiple pages, click Next to go to the next page or click Previous to go back to the previous page.
Click Back to return to the previous page.
Use the following procedures to disassociate an AccessGate from an Access Server or cluster.
To disassociate an AccessGate from an Access Server or an Access Server cluster
Launch the Access System Console and click Access System Configuration, and then click AccessGate Configuration.
The Search for AccessGates page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
The Look For list is a selection list of attributes that can be searched, as described in Table 3-2. The remaining fields allow you to specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
Click the AccessGate that you want to disassociate from an Access Server or an Access Server cluster.
The AccessGate Details page appears.
Click List Access Servers or List Clusters.
The Access Servers or Access Server clusters associated with the AccessGate are listed on the page.
Choose whether to disassociate a server cluster or a server.
To disassociate an Access Server cluster, select the cluster and click the Delete button.
To disassociate an Access Server, select the Access Server and click the Delete button.
The connection is deleted.
You can identity Web server hosts to Oracle Access Manager in various ways, for example, by providing a machine name or an IP address. The following are examples of how the same host can be addressed:
site.com
site.com:80
www.site.com
www.site.com:80
216.200.159.58
111.111.11.1:80
3232236564 (decimal addressing)
There are two fields on the WebGate configuration page for identifying Web servers that host resources that you want to protect:
Preferred HTTP Host: The Preferred Host field is required.
The WebGate intercepts all user requests to this host, even if the user's request is a variation of the Preferred HTTP Host. For example, if the value of this field is myhost22:8080 the WebGate will protect all requests to this URL. But it will also intercept other ways of addressing the host, for example, http://123.123.123.123:8080, where 123.123.123.123 is the IP address of the server.
Host Identifiers: Host identifiers are a list of all URL addressing methods.
You create policies based on the host identifier. A WebGate protects all requests that match the addressing methods that you configured in the Host Identifier, and that match the Host Identifier used in the policy.
You can configure a third feature, DenyOnNotProtected, to deny users access to all resources unless access is explicitly allowed by a rule or policy. See "Denying Access to All Resources by Default" for details.
Task overview: Protecting resources on a host
Configure a preferred HTTP host that corresponds to the computer that hosts the servers or virtual servers to be protected.
See "About Preferred HTTP Hosts" and "To configure a preferred HTTP host for a virtual Web server" for details.
Configure Host Identifiers for each Web site or virtual Web site that you want to protect.
See "Configuring Host Identifiers" for details.
Create policies to protect these resources, using the host identifiers to differentiate among virtual hosts that are protected by the same WebGate.
For example, you can configure policies that allow one user to access only of the one virtual sites that are protected by the WebGate. See "Protecting Resources with Policy Domains" for details.
The rest of this section discusses the following topics:
You are always required to supply a Preferred HTTP Host when configuring a WebGate. See "Adding an AccessGate" for details.
The rest of this section discusses the following topics:
If your environment does not use Web hosting, the value for Preferred HTTP Host is the name of the computer where the WebGate is installed, for example, myhost22, the port were the Web site is hosted, for example, 8080. The complete value would be specified as myhost22:8080. The Preferred HTTP Host field must contain a host name that matches all possible methods by which the host can be addressed. The name you enter in this field must also match one of the names entered in the Host Identifiers field. See "Configuring Host Identifiers" for details.
When you specify a value for the Preferred HTTP Host for a WebGate, and you specify the same value in a Host Identifier field, all policies that use the host identifier apply to all requests that the WebGate processes, regardless of how the request was addressed originally. For example, if you have a WebGate on a Web server on host1.company.com, you can set the Preferred HTTP Host value to host1.company.com. Any policy that you configure for host1 will be applied to a request sent to the host, no matter how the user addresses the resource. For example, suppose that the user sets up an /etc/hosts file to map to the arbitrary host name my.host.com and requests the following URL:
http://my.host.com/someResource
The WebGate uses the Preferred HTTP Host when setting policies for this request, despite the URL that the user supplied. Requests for resources that match values in the Preferred HTTP Host field are redirected to the Access Server for policy evaluation. The Preferred HTTP Host feature prevents security holes that can be inadvertently created if a host's identifier is not included in the Host Identifiers list.
Configuring a Preferred HTTP Host is also required for environments that use virtual hosting. For virtual hosts, you specify a reserved value in the Preferred HTTP Host field. See "Configuring Virtual Web Hosting" for details. This field forces WebGate to pass the preferred host string to the Access Server for policy evaluation instead of the host typed into the browser by the user. No matter what is typed into the browser, the Access Server always sees the preferred host.
As described in the previous section, a host can be known by multiple names. Use the Host Identifiers feature to enter the official name for the host, and every other name by which the same host can be addressed by users. A request sent to any address on the list is mapped to the official host name.
As described in "Protecting Resources with Policy Domains", when you define policies to protect resources on the hosts, you use the name in the host identifiers field. When the WebGate intercepts a request, it checks the request for an address. If the address is on the host identifiers list, this address is mapped to the official host name, and the Access System can apply the rules and policies that protect the resource.
In your Host Identifiers list:
Each host name must be unique.
Each host name:port pair must be unique.
Each host name:port pair must belong to only one host identifier.
Each host name:port pair must match the end user's entry exactly.
With decimal addressing it may be impractical to define all possible URL combinations for the same site. Using the following formula to calculate possible decimal addresses for the original address 01.02.03.04, where each 0 is an 8 bit octet, you will find many ways to represent the original IP address:
Formula:
01*256^3+02*256^2+03*256+04
The following URL values are all for the same site:
http://%61%73%74%65%72%69%78
http://%31%39%32%2E%31%36%38%2E%34%2E%32%30/
http://%33%32%33%32%32%33%36%35%36%34
For more information, you may want to look at the site http://www.karenware.com/powertools/ptlookup.asp.
See "To add a Host Identifier" for the steps to create a host identifiers list.
You must specify a Preferred Host, and you can specify one or more Host Identifiers. You can provide host identifiers to identify a single host, and to identify multiple virtual Web hosts.
The rest of this section discusses the following topics:
If you redirect an authentication challenge to be processed by another host, you must add the name of that host to the Host Identifiers list. The host name that you enter in the Challenge Redirect field must be available in the Host Identifiers list when adding or modifying an authentication scheme. For example, if a user is redirected to an SSL-enabled server for authentication, that server must be included.
When adding URL prefixes to a policy domain, the Delegated Access Administrator must specify a server hosting the URL prefix. When a user attempts to access a URL that is protected by the policy domain, the user is redirected to the server specified in the Challenge Redirect field for authentication.
The Host Identifier details page displays the name, description, and host name variations, as described in the following procedure.
To view or delete Host Identifiers
Launch the Access System Console and click Access System Configuration.
The Access System Configuration page appears.
In the left navigation pane, click Host Identifiers.
The List all Host Identifiers page appears. The existing host identifiers are listed on the page.
To view a host identifier, select its name from the list.
To delete a host identifier, select its name from the list and click Delete.
When you configure host identifiers in an environment that does not use virtual Web hosting, you must enter one of the host name variations in the Preferred HTTP Host field to ensure that single sign-on works properly. If you attempt to add a host name variation that already exists for a different host identifier, a message alerting you of the duplication is displayed. You can save or cancel your changes.
If you support virtual Web hosting as described in "About Preferred HTTP Hosts", you supply a reserved name in the Preferred HTTP Host field instead of a host name variation.
Launch the Access System Console and click the Access System Configuration tab.
The Access System Configuration page appears.
In the left navigation pane, click Host Identifiers.
The List all Host Identifiers page appears.
Click Add to add a new host identifier.
In the Name field, type the name of the host.
In the optional Description field, type a short description.
In the Hostname variations field, enter all variations for identifying this host.
The Access System does not add a default port number if you do not provide one.
Click Save.
You can install a WebGate on a Web server that contains more than one Web site and domain name. The WebGate must reside in a location that enables it to protect all of the Web sites on that server.
The virtual Web hosting feature of many Web servers enables you to support multiple domain names and IP addresses that each resolve to their unique subdirectories on a single virtual server. For example, you can host abc.com and def.com on the same virtual server, each with its own domain name and unique site content. You can have name-based or IP-based virtual hosting.
Prior to Oracle Access Manager 10.1.4.0.1, you were not required to specify a Preferred HTTP host. This was useful for virtual Web hosting because you could specify several host identifiers and have them resolve to different virtual Web hosts. As of Oracle Access Manager 10.1.4.2, to support virtual Web hosting, you must specify a specific value, described in the following paragraphs, in the Preferred HTTP host field.
The following summarizes configuration for virtual servers:
To support virtual hosts on most Web servers other than Apache-based servers, you must set the Preferred HTTP Host value to HOST_HTTP_HEADER.
If you specify this value, when user's browser sends a request, the WebGate sets the value of the Preferred HTTP Host to the host value in the request. For example, suppose a user enters the string myweb2 in a URL:
http://myweb2
On the Web server, if one of the Web sites has a host named myweb2, the request is served by the matching virtual site.
On Apache-based servers, for example, Apache, Apache 2, IBM HTTP Server, Oracle HTTP Server, and so on, the Preferred HTTP Host value must be set to SERVER_NAME.
Note:
The SERVER_NAME value is not supported for any host other than an Apache-based server. If you set this value for a non-Apache-based server, users will be unable to access any resources that are protected by WebGate on that Web server. Users will, instead, receive an error that the WebGate configuration is incorrect.To configure a preferred HTTP host for a virtual Web server
Launch the Access System Console, click Access System Configuration, then click AccessGate Configuration.
The Search for AccessGates page appears.
Select the search attribute and condition from the lists, or select All to find all AccessGates.
See Table 3-2 for a description of searchable attributes. You can specify search criteria that are appropriate for the selected attribute.
Click Go.
The search results are displayed on the page.
Click the name of the AccessGate you want to modify.
The AccessGate Details page appears.
Click Modify.
The Modify AccessGate page appears.
In the Preferred HTTP Host field, enter the following:
On most Web servers, enter HTTP_HOST_HEADER.
On an Apache-based server, enter SERVER_NAME.
For IIS, to support virtual hosting, you also need to go to the IIS console and configure each virtual Web site to contain three fields:
Host Header Name
IP address
Port
See the following for details:
Access System default behavior is to allow access when a resource is not protected by a rule or policy. This is accomplished using one Boolean flag, DenyOnNotProtected, located in the AccessGate configuration page. The default setting is false, which means that access is allowed to resources not protected by a rule or policy.
When set to true, the DenyOnNotProtected parameter lets you establish the opposite behavior. When set to true, DenyOnNotProtected denies access to all resources to which access is not explicitly allowed by a rule or policy. This can limit the number of times the WebGate queries the Access Server, and can improve performance for large or busy policy domains.
Because different Web servers and Access Clients have different requirements, DenyOnNotProtected is implemented through WebGate. DenyOnNotProtected cannot be used with other types of AccessGates.
Important:
DenyOnNotProtected overrides Host Identifiers and Preferred Host. Oracle recommends setting DenyOnNotProtected to true. Setting DenyOnNotProtected to false can cause security holes in large installations with multiple Host Identifiers, virtual hosts, and other complex configurations.To deny access to all unprotected resources
From the Access System Console, click the tab for Access System Configuration.
Click AccessGate Configuration in the left navigation pane.
Find an AccessGate and click its link.
In the details page for this AccessGate, click Modify.
Change the DenyOnNotProtected setting to true to deny access to all unprotected resources.
Restart the WebGate to enable the change to take effect immediately.
If you have set DenyOnNotProtected to true, you must also protect Login.html with the Anonymous authentication scheme; otherwise, the page will not display when you access its associated resource.
Suppose you have a machine with IP addresses A and B associated with it, both on port 80, and using the same configuration file. For Netscape and iPlanet, this would be the obj.conf files. Both of these virtual servers are protected by the same AccessGate or WebGate.
The goal is to protect all content on both virtual servers without using a Preferred Host. To meet this goal, you may set up a host ID for all variations of A, and then protect some content on A by defining policies for specific URLs. You need not set a Preferred Host for either AccessGate A or B. You may also set the value of DenyOnNotProtected to true for the WebGate protecting the AccessGate, so by default all content is protected on A and B.
With this setup, when a user tries to access a URL on A, the policies are evaluated first and if no corresponding Access Policy is found, content is denied only for A.
When using an Apache reverse proxy for single sign-on, in the Apache httpd.config file you specify the Web sites to run on the Apache server. The settings can be global across all Web sites or local to a Web site. You can restrict the Oracle Access Manager loading references in the httpd.config file to be associated with a specified site, with virtual hosts, specific directories or even files.
To associate the WebGate with specific targets, you move the following directives the the http.conf file:
AuthType Oblix require valid-user
You can put these directives in a block that tells Apache to use WebGate for every request. You can also move the directives to a block that limits when the WebGate is called. The following is an example of putting the LocationMatch directive after a VirtualHost directive:
DocumentRoot /usr/local/apache/htdocs/myserver ServerName myserver.example.net AuthType Oblix require valid-user
After you move the LocationMatch block to the VirtualHost directive, the WebGate will only work for that virtual host. You can add the LocationMatch block to as many virtual hosts as you want. The following examples shows how you could protect one virtual server:
ServerAdmin webmaster@example.net
DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv"
ServerName apps.example.com
ProxyRequests On
SSLEngine on
SSLCACertificateFile Z:/Apps/sslcert_myapps_ptcweb32/intermediateca.cer
SSLCertificateFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.cer
SSLCertificateKeyFile Z:/Apps/sslcert_myapps_ptcweb32/sslcert_myapps_ptcweb32.key
ErrorLog logs/proxysite1_log
CustomLog logs/proxysite1_log common
ProxyPass / https://apps.example.com/
ProxyPassReverse / https://apps.example.com/
ProxyPass /bkcentral https://apps.example.com/bkcentral
ProxyPassReverse /bkcentral https://apps.example.com/bkcentral
ProxyPass /NR https://apps.example.com/NR
ProxyPassReverse /NR https://apps.example.com/NR
AuthType Oblix
require valid-user
#*** BEGIN Oracle Access Manager WebGate Specific ****
LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll
WebGateInstalldir Z:/apps/Oracle/WebComponent/access
WebGateMode PEER
SetHandler obwebgateerr
SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache none
SSLLog logs/SSL.log
SSLLogLevel info
# You can later change "info" to "warn" if everything is OK
When a user or an application, such as a .JSP or Java application, attempts to access an Identity System application or an Access System-protected Web resource, the login process is set in motion. This process varies depending on the following factors:
Is the resource protected, and by what authentication scheme?
If the resource is protected by a WebGate, the Access System challenges the user as specified by the challenge method configured in the authentication scheme.
If the resource is an unprotected Identity System application, for example, the User Manager, the Identity System uses its own login form to challenge the user for credentials.
Can the user be authenticated?
To ensure that the user is who he or she claims to be, WebGate challenges the user for credentials. If the user supplies appropriate credentials, the WebGate authenticates the user, generates the ObSSOCookie, and sets it in the user's browser.
For information on the ObSSOCookie, see "Cookies Generated During Login".
Have you configured single sign-on for the Access System?
The Access System's single sign-on capability enables users to access more than one protected URL or application with a single login. If single sign-on has been implemented in a domain, the user needs to authenticate only once to access multiple resources protected by an authentication scheme which has the same level or a lower level of security. The ObSSOCookie is passed from the user's browser to any WebGates configured for the domain.
When Access System single sign-on is implemented in a multi-domain environment, an authentication is honored by all the hosts in two or more domains.
See "Configuring Single Sign-On" for more information on configuring SSO for single- and multi-domain environments.
Is the user allowed to access the content, and what actions can he or she perform?
WebGate queries the Access Server to determine if the user is authorized to access the resource. Access Server performs the authorization. If the user is authorized, the Access Server checks for a policy that specifies the actions that the user is allowed perform.
The Access Server sends the information to WebGate, which then returns the requested resource to the user.
Figure 3-1 illustrates the Access System's authentication process.
Figure 3-2 illustrates the Access System's authorization process.
Figure 3-3 shows all of the processes involved in serving unprotected resources, verifying a user's identity for a protected resource, and authorizing the user and serving the protected resource.
Figure 3-3 Overall Process for Evaluating If a Resource is Protected, Authentication, Authorization, and Serving the Resource
Figure 3-3 illustrates the following:
An initial request is intercepted by a WebGate, which forwards the request to the Access Server.
Policies are retrieved from the directory server to determine if the resource is protected.
If the resource is not protected, it is served.
If the resource is protected, the WebGate prompts for credentials, and forwards them to the Access Server.
The Access Server matches the credentials with records in the directory.
If the authentication succeeds, a second round-trip is performed to check the authorization policies in the directory.
If the authorization rules permit, the resource is served.
This section describes different scenarios where a user attempts to access an Access System-protected resource.
Process overview: Access when an Identity System application is not protected by WebGate
A user attempts to access an Identity System application that is not protected by a WebGate.
The Identity System challenges the user for credentials such as user name and password.
If the user authenticates successfully, the Identity application generates the ObTEMC and the ObTEMP cookies.
See "Cookies Generated During Login" for information on cookies.
The Identity System then allows the user to access the Identity application. The user can perform specific actions in accordance with how the application is configured.
Process overview: Access when the resource is protected by WebGate
A user attempts to access a resource that is protected by a WebGate.
When the user attempts to access a Web resource or an application, WebGate intercepts the request and queries the Access Manager SDK caches to determine if the requested resource and the associated operations are protected.
If information on the requested resource is not in the cache, WebGate makes a request to the Access Server for the security policy to determine if the resource is protected by the Access System.
If the resource is an unprotected Identity System resource, WebGate forwards the request to the server storing the resource, and the Identity System application authenticates the user as in "Process overview: Access when an Identity System application is not protected by WebGate".
If the resource is protected, WebGate looks for the ObSSOCookie to determine whether the user has already been authenticated.
If the user is not authenticated, the server challenges the user for credentials. The challenge method varies depending on the authentication scheme used.
If a form-based authentication scheme is used, WebGate generates the ObFormLoginCookie. See "Cookies Generated During Login" for details.
If the user authenticates successfully, WebGate generates the ObSSOCookie and sets it for inclusion in the next response to the user's browser.
Depending on the actions specified for authentication success and authentication failure, the user may be redirected to a specific URL, or user information may be passed on to other applications through a header variable or a cookie value.
WebGate then queries the Access Server for information on authorization for the resource.
The Access Server queries and evaluates the appropriate authorization policies stored in the directory server, and passes on the information to WebGate.
For SSO to a an Identity System application, the authorization policy must set an action to set the HTTP_OBLIX_UID header to the user identity for the Identity System application. If this header is not set, the application authenticates the user as in "Process overview: Access when an Identity System application is not protected by WebGate".
If the user is authorized, access to the requested content is allowed, and the HTTP_OBLIX_UID header is set.
Depending on the authorization actions specified for authorization success and authorization failure, the user can be redirected to a specific URL, or user information can be passed on other applications through a header variable or a cookie value.
The Identity System application reads the HTTP_OBLIX_UID header variable to get the identity. The Identity System application determines the user's access rights from the identity.
Process overview: Identity resource protected by WebGate
A client application, such as a .jsp or a Java application, attempts to access a URL to a Identity resource that is protected by WebGate.
The client application uses Access Manager API to interface with the Access System's Authentication and Authorization services. The application supplies the client's user credentials to the Access Manager API.
The Access Server queries and evaluates the appropriate authentication rule.
The Access Manager API authenticates the user and creates a session token.
The Web application sets the ObSSOCookie with the session token for the domain containing the client application and sends the cookie along with the request to the client application.
The WebGate queries the Access Server for information on authorization for the client user.
The Access Server queries and evaluates the appropriate authorization policies stored in the directory server, and passes on the information to WebGate.
For SSO to an Identity System application, the authorization policy must set an action to set the HTTP_OBLIX_UID header. The header must set the user identity to be used by the Identity System application. If this header is not set, the application authenticates the client application itself, as in "Process overview: Access when an Identity System application is not protected by WebGate".
If the client application is authorized, access to the requested content is allowed and the HTTP_OBLIX_UID header is set.
Depending on the authorization actions specified for authorization success and authorization failure, the user may be redirected to a specific URL, or user information may be passed on other applications through a header variable or a cookie value.
Note:
If the client application is authorized, it is allowed to access the resource.Depending on the scenario, the Access System generates one or more cookies. Cookies contain information such as the user DN, the client's IP address, and the cookie expiry time.
The ObSSOCookie is an encrypted single sign-on cookie that is generated by the Access Server when a user authenticates successfully. The ObSSOCookie is a session-based cookie that stores user identity information. You can cache the information, if necessary.
See "Configuring Single Sign-On" for more information on the ObSSOCookie.
Some browsers, for example, Netscape, Mozilla, or Firefox share the session state among all open browser windows. If you log in to Oracle Access Manager and the browser stores the obSSOCookie, the same cookie is shared with all open browser windows. If you open another browser window and access a protected resource, you are automatically authenticated as the same user that has the current ObSSOCookie stored in the browser.
The only way to destroy the ObSSOCookie in these browsers is to delete or clear the ObSSOCookie, configure a Logout URL, or close all browser sessions on your desktop. See "Configuring Logout" for details.
The ObBasicAuthCookie is an HTTP basic method is used to protect a resource. See "Default Authentication Schemes" for details.
The ObFormLoginCookie is generated when a form-based authentication scheme is used to protect a Web resource. WebGate uses the ObFormLoginCookie to direct the user back to the requested resource after successful authentication.
The ObFormLoginCookie maintains the original request information. By default, this cookie is set when the browser is first redirected to the form. The ObFormLoginCookie contains the following information for the original request:
The requested URL
The requested operation
An authentication scheme
The host to return to URL
See "Form-Based Authentication" for more information.
The ObTEMC cookie, an encrypted session-based cookie, is generated by the Identity application when a user authenticates successfully. The ObTEMC cookie contains the following information:
User distinguished name (DN) and the original DN. Original DN information is stored only if the Identity Substitute Rights feature is used. For details about adding substitute administrators and substitution rights, see the Oracle Access Manager Administration Guide.
A flag specifying whether the user is a Master Administrator, an Identity Administrator, or an Access Administrator.
If single sign-on (SSO) has been implemented, the SSO Login ID.
The time stamp.
Every time a user performs an action, the time stamp is updated in the cookie to reflect the last time the session was used. If SSO has been implemented, however, the time stamp is ignored.
The IP address of the client machine.
The ObTEMP cookie is a session-based cookie that is generated by the Identity application when a user authenticates successfully. The ObTEMP cookie contains the following application information:
Login name
User type
Number of search-generated results (selector info)
Uncommitted changes in various configuration applets
