| Oracle® Access Manager Installation Guide 10g (10.1.4.0.1) Part Number B25353-01 |
|
|
View PDF |
| Oracle® Access Manager Installation Guide 10g (10.1.4.0.1) Part Number B25353-01 |
|
|
View PDF |
This chapter provides important information you need to prepare your environment before starting the installation process for Oracle Access Manager components. Topics include:
|
Note: Failure to complete all prerequisites may adversely affect your 10g (10.1.4.0.1) installation. |
For an overview of Oracle Access Manager components, features, functions, audiences, and manuals, see the Oracle Access Manager Introduction. Upgrading to 10g (10.1.4.0.1) is described in the Oracle Access Manager Upgrade Guide.
You can help ensure a successful installation by completing the following prerequisites before you install Oracle Access Manager.
Task overview: Preparing to install Oracle Access Manager
Review Chapter 1, "About the Installation Task, Options, and Methods" and decide which installation options are best for your environment.
Follow a few best practices for security, as described in "Setting Secure Passwords and Permissions".
Synchronize the host clocks if you are installing across multiple machines, as described in "Synchronizing System Clocks".
Review all "Meeting Oracle Access Manager Requirements" and complete activities.
Create a Web server instance and refer to "Meeting Web Server Requirements".
Create a supported directory server instance, define at least one administrator-level user on your directory server (see your vendor documentation), and review all topics in "Meeting Directory Server Requirements" .
Ensure that your environment meets the platform and support requirements, as described in "Confirming Platform Requirements".
Obtain the software from the Oracle-provided installation media and prepare a temporary directory as described in "Preparing a Temporary Directory for Installers".
Collect and document information about your environment to provide during the installation process, as described in "Installation Preparation Checklists" .
If you are installing with an Oracle-provided Language Pack or on a machine running a non-English (American) language or territory operating system, see Chapter 3, "About Multi-Language Environments" and complete any activities needed.
The following are best practices for a secure installation:
On all platforms, create a temporary LDAP administrator password during installation and reset it after installing all components.
On Unix, if your installation computer allows access to untrusted users or groups, perform the installation with a user and group that are accessibly only to trusted user accounts.
Create a new user and group if necessary.
On Windows, if your installation computer allows access to untrusted users, configure all file security permissions to only allow access to trusted users.
If you plan to install Oracle Access Manager components across multiple machines, make sure all system clocks are synchronized. This is particularly important if you will be running the software in Cert or Simple mode.
For example, if the WebPass Web server system clock is set ahead of the Identity Server system clock, a login request sent from the WebPass plug-in on the Web server will contain a time that, to the Identity Server, has not yet occurred. The same is true for the Access System. If a Web server clock is ahead of the Access Server clock, a request sent from the Policy Manager to the Access Server will contain a time that, to the Access Server, has not yet occurred.
For successful operation:
Ensure all machine clocks are synchronized—There is no tolerance level. If, for example, the WebGate clock is even slightly ahead of the Access Server clock, a cookie generated by the WebGate will appear to be in the future and will cause problems in the Access Server.
Confirm that the clock on each machine running a WebGate is not running ahead of the Access Servers with which it is associated. The Access Server must be ahead of the WebGate clock by a maximum of 60 seconds.
Confirm that the clock on each machine running the WebPass is not running ahead of the Identity Servers and Policy Managers with which it is associated.
To synchronize 10g (10.1.4.0.1) components across geographically diverse time zones, you can use the Network Time Protocol (NTP). NTP can synchronize the time on machines to within a few milliseconds. For more information about time synchronization, go to the Web site:
and the comp.protocols.time.ntp news group.
An ntp.conf file at minimum would contain the following:
server <some NTP server name>.com
driftfile /etc/ntp.drift
Instructions for creating the ntp.conf file can be found at the following locations:
http://www.sun.com/products-n-solutions/hardware/docs/html/816-3626-10/after.html
http://inetsd01.boulder.ibm.com/pseries/fr_FR/files/aixfiles/ntp.conf.htm
http://www.developer.ibm.com/tech/faq/individual/0,,2:14789,00.html
Unix machines use UTC (also known as GMT) internally and convert to the local time that is needed on the display. Windows machines keep the clock in local time, but NTP synchronization programs compensate to ensure accurate times on Windows.
All Unix operating systems ship with a version of NTP. To configure NTP on Solaris, create an ntp.conf file. The name of the ntp.conf file to use the Solaris provided NTP daemon is /etc/inet/ntp.conf. Once this is created, xntp is started automatically when the operating system starts.
On AIX: Create an /etc/ntp.conf file and enable or create a start script.
For all Unix platforms: Get the current (and more secure) version of the NTP daemon from http://www.ntp.org/.
Windows machines synchronize their times automatically with their domain controller using a version of NTP. The domain controller needs to be configured to synchronize with a time source.
To obtain an official time for synchronization across your network many ISPs provide a time service for their customers.
NTP, which has a list of open stratum-1 servers available at http://www.ntp.org.
However, that this site may not be the most secure choice. For an example of a time-based attack, imagine unexpiring a cookie by spoofing the time to be earlier than the real time.
GPS-based clocks, which use satellite technology to provide very accurate time, are available.
These clocks can be used to set your whole network to the same time. GPS technology requires very accurate times; each satellite contains 3 atomic clocks with continuing corrections provided from the ground that compensate for relativistic effects. This means that an accurate estimate of the current time is developed as a side effect of figuring out where the GPS receiver is.
The following information is provided for your convenience.
You need a supported host machine for each component, which you can find as described in "Confirming Platform Requirements". In addition:
Administrative Rights: The account that performs component installation must have administration privileges. Both the Identity Server and Access Server run as services. The user account that is used to run the Identity Server and Access Server services must have the "Log on as a service" right, which can be set through Administrative Tools, Local Security Policy, Local Policies, User Rights Assignments, Log on as a service.
On Microsoft Windows—The user account that is used to run the Identity Server service must have the right to "Log on as a service". This can be set through Administrative Tools. For example:
Administrative Tools, Local Security Policy, Local Policies
User Rights Assignments, Log on as a service
On Unix Platforms—You will be asked to specify the username and group that the Identity Server will use: typically, the defaults are "nobody"; for HP-UX, the defaults are WWW (username) and others (group). Confirm that the right commands are installed and verify the user name under which your Web server runs. For example:
Locate the following commands (usually found in /usr/bin, /usr/sbin, or /usr/csb) and make sure their location is included in the search path:
sed, tar, cp, ls, mkdir, rmdir
The user name under which your Web server runs could be nobody, root, or some other user name, such as Web. You can determine this by checking your Web server configuration files or by running your Web server's administration console and looking under View Server Settings.
Machines Online: Before installation, you must be able to ping the machine on which each component will run. Also, during installation you will be asked to supply the DNS host name of the machine on which the Identity Server and Access Server are installed.
Linux Libraries: Before installing components on Linux machines, you need to install additional GCC runtime libraries (libgcc_s.so.1 and libstdc++.so.5) that are compatible with GCC 3.3.2. See "Preparing Linux Host Machines".
Component Security: During installation, you must specify the transport security mode for communication between Oracle Access Manager components. See "Securing Oracle Access Manager Component Communications".
Directory Security: During installation (Identity Server, Policy Manager, and Access Server), you must specify the hostname, DN, and transport security mode for the directory server with which the components will communicate. See "Meeting Directory Server Requirements" for this and other important information.
Existing Identity Server Name: If you want to reuse an existing Identity Server name, see "Recycling an Identity Server Instance Name".
Cancel Installation: If you need to cancel an installation or remove an installed component, see "Uninstalling Oracle Access Manager Components".
If you are installing on a machine with an operating system that is non-English (AMERICAN) language or locale, you may set theLANG environment variable or the optional NLS_LANG or COREID_NLS_LANG environment variables.
If you install an Identity Server with one or more Oracle-supplied Language Packs you must install WebPass with the same Language Packs (and install corresponding Access System Language Packs with all Access System components.
If you are installing components with a Language Pack on a Unix system, you must ensure that the Language Pack installer resides in the same directory as the component and that the Language Pack installer has execute permissions before launching the main installer. For example:
chmod +x "Oracle_Access_Manager10_1_4_0_1_FR_sparc-s2_LP_Identity_System" chmod +x "Oracle_Access_Manager10_1_4_0_1_FR_sparc-s2_LP_Access_System"
For more information, see Chapter 3, "About Multi-Language Environments".
During installation of Oracle Access Manager components on a Linux machine, you are asked to specify the location of additional GCC runtime libraries (libgcc_s.so.1 and libstdc++.so.5) that should be compatible with GCC 3.3.2. Oracle does not ship theses nor make these available for download from an Oracle Web site. If you need to obtain these libraries, contact your platform vendor.
To install libgcc_s.so.1 and libstdc++.so.5 on Linux hosts
Obtain the libgcc_s.so.1 and libstdc++.so.5 libraries from your platform vendor.
Store the following files on the local Linux machine on which you will install one or more Oracle Access Manager components:
During Oracle Access Manager installation, specify the location of the libraries on the local machine and continue the installation.
The Identity Server does not need to be on the same host system as any other Oracle Access Manager component or application. Oracle recommends you install the Identity Server and Access Server on different machines. Further, the Identity Server does not need to be on the same host system as any other Oracle Access Manager component or application. For details about installing one or more Identity Servers, see Chapter 4, "Installing the Identity Server".
Each Web server instance that communicates with the Identity Server must be configured with a WebPass. One WebPass can communicate with multiple Identity Servers. More than one WebPass can communicate with the same Identity Server, which is recommended for load balancing. See also "Synchronizing System Clocks".
The WebPass instance identifier that you specify during installation must be unique. The WebPass instance identifier is not validated until after the installation, when the Web server is started.
A WebPass must also be installed with each Policy Manager on the same Web server instance, at the same directory level.
For details about installing one or more WebPass instances, see Chapter 5, "Installing WebPass".
During Identity System setup, you need to define a user who will be granted access to all Oracle Access Manager functionality. This is the Master Administrator. For more information, see Chapter 6, "Setting Up the Identity System".
The following discussions outline Access System requirements and guidelines:
The Policy Manager must be installed on the same Web server instance as a WebPass, at the same directory level as a WebPass. See also "Synchronizing System Clocks".
Oracle recommends that you do not put a firewall between the Policy Manager and the directory server because no "health check" is performed. After a period of inactivity, the firewall may drop the Policy Manager connection without warning. To avoid such problems, either ensure the Policy Manager and directory server are on the same side of the fire wall or disable the firewall connection timeout between the Policy Manager and directory server, if possible. However, not all firewalls support this.
The NETWORK account must have Modify rights at the volume root.
Depending on the directory server you use with the Policy Manager, consider the following:
If you specify Active Directory on Windows Server 2003 as the directory server during Policy Manager installation, a new page appears asking if dynamic auxiliary classes are to be supported. If you are using ADSI, you need to set the IIS Web server Anonymous User Login Account to a Domain User after installation and before setting up the Policy Manager.
Oracle Access Manager does not support SSL-enabled communication between the directory server and Policy Manager when the Policy Manager is installed on Solaris with a Sun (formerly Netscape) Web server.
There are several considerations depending upon the Web server you are using for your Policy Manager installation:
Apache: Oracle Access Manager supports Apache with or without SSL enabled. For SSL-enabled communication, Oracle Access Manager supports Apache with mod_ssl only, not Apache-SSL. mod_ssl is a derivative of, and alternative to, Apache-SSL. configure in httpd.conf the user and group you want the Web Server to run as.
IIS: The Policy Manager installer cannot update multiple Web servers instances. If you have multiple IIS Web server instances installed, be sure to install a separate Policy Manager on each Web server instance.
When installing the Policy Manager on Windows 2000 with IIS, ensure that the group named Everyone has full access to the \temp directory and the drive (for example, C or D) to which the \temp directory belongs.
The TEMP variable needs to be set to point to a valid directory, either for the entire system or for the IIS user. Oracle recommends setting the TEMP variable for the entire system.
For details about installing one or more Policy Managers, see Chapter 7, "Installing the Policy Manager".
Oracle recommends you install the Identity Server and Access Server on different machines. The Identity Server does not need to be on the same host system as any other Oracle Access Manager component or application.
Do not install the Access Server in the same directory as the Policy Manager. Do not install multiple Access Servers in the same directory.
Failover and Load Balancing: Oracle recommends installing multiple Access Servers for failover and load balancing.
Firewall: Oracle recommends protecting the machine on which you will install the Access Server with a firewall.
If you install a 10g (10.1.4.0.1) Access Server in an upgraded environment that includes older WebGates, you must manually change "IsBackwardCompatible" Value="true" in the Access Server's globalparams.xml file. Upgraded Access Servers are backward compatible with older WebGates automatically. See the Oracle Access Manager Upgrade Guide for complete details.
For details about installing one or more Access Servers, see Chapter 8, "Installing the Access Server".
The WebGate must be installed on a machine hosting a Web server. You can install the WebGate in any directory that your Web server can access.
You should install a WebGate on any Web server that you want to protect with the Access System, including the Web server on which the Policy Manager is installed. If you install the WebGate to protect an Policy Manager and WebPass, the WebGate must be installed in the same directory as the Policy Manager and WebPass. For example, if the WebPass and Policy Manager are installed in \COREid\WebComponent, then the WebGate must also be installed there.
The WebGate may be installed at the root level or the site level. Installing WebGate on multiple virtual sites amounts to only one instance of WebGate. The WebGate can also be installed using a non-root user if the Web server process runs as a non-root user.
The WebGate may be configured to run at either the machine level or the virtual Web server level. However, do not install at both the machine level and the virtual Web server levels. See also "Synchronizing System Clocks".
Older WebGates may coexist with 10g (10.1.4.0.1) Access Servers. In this case, you need to:
Use RC4 as the encryption scheme if you have Release 5.x and 10g (10.1.4.0.1) WebGates co-existing in the same system.
Use RC6 as the encryption scheme if you have Release 6.x and 10g (10.1.4.0.1) WebGates co-existing in the same system.
Use the AES encryption scheme if you have only Release 7.0 or 10g (10.1.4.0.1) WebGates co-existing in the same system.
Also, for details about Access Server backward compatibility with older WebGates, see the Oracle Access Manager Upgrade Guide. For details about installing one or more WebGates, see Chapter 9, "Installing the WebGate".
Web server and operating system types are not factors in WebGate-to-Access Server communication. However, there are considerations for WebGates in various environments:
Unix WebGates: You may be logged in as root to install the WebGate. The WebGate can be installed using a non-root user if the Web server process runs as a non-root user.
Apache Web Servers: Oracle Access Manager supports Apache with or without SSL enabled. For SSL-enabled communication, Oracle Access Manager supports Apache with mod_ssl only, not Apache-SSL. mod_ssl is a derivative of, and alternative to, Apache-SSL.
IHS v2 Web Servers: Oracle Access Manager supports IHS v2 and IHS v2 Reverse Proxy servers with or without SSL enabled. For details, see "Updating Web Server Configuration for Oracle Access Manager Web Components" .
Domino Web Servers: Before you install the WebGate with a Domino Web server, you must have properly installed and set up the Domino Enterprise Server R5. For more information, see "Setting Up Lotus Domino Web Servers for WebGates"
IIS Web Servers: Before installing the WebGate, ensure that your IIS Web server is not in lockdown mode. Otherwise things will appear to be working until the server is rebooted and the metabase re-initialized, at which time IIS will disregard activity that occurred after the lockdown.
If you are using client certificate authentication, before enabling client certificates for the WebGate you must enable SSL on the IIS Web server hosting the WebGate.
Setting various permissions for the /access directory is required for IIS WebGates only when you are installing on a filesystem that supports NTFS . For example, suppose you install the ISAPI WebGate in Simple or Cert mode on a Windows 2000 machine running the FAT32 filesystem. The last installation panel provides instructions for manually setting various permissions that cannot be set on the FAT32 filesystem. In this case, these instructions may be ignored.
Each IIS Virtual Web server can have it's own WebGate.dll file installed at the virtual level, or can have one WebGate affecting all sites installed at the site level. Either install the WebGate.dll at the site level to control all virtual hosts or install the WebGate.dll for one or all virtual hosts.
You may also need to install the postgate.dll file at the machine level. The postgate.dll is located in the \WebGate_install_dir, as described in "Installing postgate.dll on IIS Web Servers". If you perform multiple installations, multiple versions of this file may be created which may cause unusual Oracle Access Manager behavior. In this case, you should verify that only one webgate.dll and one postgate.dll exist.
|
Note: The postgate.dll is always installed at the site level. If for some reason the WebGate is reinstalled, the postgate.dll is also reinstalled. In this case, ensure that only one copy of the postgate.dll exists at the site level. |
To fully remove a WebGate and related filters from IIS, you must do more than simply remove the filters from the list in IIS. IIS retains all of its settings in a metabase file. On Windows 2000 and later, this is an XML file that can be modified by hand. There is also a tool available, MetaEdit, to edit the metabase. MetaEdit looks like Regedit and has a consistency checker and a browser/editor. To fully remove a WebGate from IIS, use MetaEdit to edit the metabase.
ISA Proxy Servers—On the ISA proxy server, all ISAPI filters must be installed within the ISA installation directory. They can be anywhere within the ISA installation directory structure.
Before installing the WebGate on the ISA proxy server:
Check for general ISAPI filter with ISA instructions on:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/isa/isaisapi_5cq8.asp
Ensure that the internal and external communication layers are configured and working properly.
During installation you will asked if this is an ISA installation; be sure to:
Indicate that this is an ISA proxy server installation, when asked.
Specify the ISA installation directory path as the WebGate installation path.
Use the automatic Web server update feature to update the ISA proxy server during WebGate installation.
After WebGate installation, locate the file configureISA4webgate.bat, which calls a number of vbscripts and the process to configure the ISA server filters that must be added programmatically.
Table 2-1 provides estimates regarding the free disk space needed for each component are provided for your convenience.
You may install components in the default directory or in a directory of your choosing. When you change the path name, you may include any characters that are acceptable to your operating system. For example, you may include spaces on Windows systems but not on Unix systems.
Be sure that all file and path names include only English language characters. In file and path names, no international characters are allowed.
In any case, it is a good idea to use consistent naming regardless of platform. For example, you can use an underscore rather than a space in names on Windows platforms. Typically, the default installation directory for Oracle Access Manager is as follows:
Windows Platforms: \Program Files\COREid\
Unix Platforms: /opt/coreid/ (all lowercase)
Depending on the component you are installing, the path will vary slightly as shown in Table 2-2. For example:
\identity is appended automatically to all Identity component path names
\access is appended automatically to all Access component path names
\WebComponent is included automatically (along with either \identity or \access) in the default path name for WebPass, Policy Manager, and WebGate installations
Table 2-2 Installation Directory Path Names
| Component | Installation Directory |
|---|---|
|
Identity Server |
Windows: \Program Files\OracleAccessManager\identityUnix: /opt/oracleaccessmanager/identity In This Guide: \IdentityServer_install_dir\identity |
|
WebPass |
Windows: \Program Files\OracleAccessManager\WebComponent\identityUnix: /opt/oracleaccessmanager/WebComponent/identityIn This Guide: \WebPass_install_dir\identity |
|
Access Server |
Windows: \Program Files\OracleAccessManager\accessUnix: /opt/oracleaccessmanager/accessIn This Guide: \AccessServer_install_dir\access |
|
Policy Manager |
Windows: \Program Files\OracleAccessManager\WebComponent\accessUnix: /opt/oracleaccessmanager/WebComponent/accessIn This Guide: \PolicyManager_install_dir\access |
|
WebGate |
Windows: \Program Files\OracleAccessManager\WebComponent\accessUnix: /opt/oracleaccessmanager/WebComponent/accessIn This Guide: \WebGate_install_dir\access |
In this manual, the installation directory path for each Oracle Access Manager component will be expressed as \Component_install_dir followed by any suffix that is automatically appended to this path, as shown in Table 2-2. When the generic form is used, Component_install_dir, a generic suffix, identity|access, follows: for example, Component_install_dir/identity|access.
When launching a Oracle Access Manager installation on a Unix system, you can direct an installation to a directory with sufficient space using the -is:tempdir path parameter.
To specify a temporary directory on Unix systems
Use the -is:tempdir parameter in the following command. For example:
./ Oracle_Access_Manager10_1_4_0_1_sparc-s2_Identity_Server -is:tempdir /export/home/oblix/temp
The path must be an absolute path, not a relative path.
The path /export/home/oblix/temp should be replaced with a file system with sufficient space.
Before installation, you must decide which type of transport security you will use between components. Oracle Access Manager supports three types of transport security for communication that occurs between components:
Open: Allows unencrypted communication, see "Open Mode"
Simple: Supports encryption by Oracle, see "Simple Mode"
Cert: Requires a third-party certificate, see "Cert Mode"
The following guidelines should be observed when planning and implementing transport security between Oracle Access Manager components during installation. Specifically:
Transport security between all Identity System components (Identity Servers and WebPass instances) must match: either all open, all Simple mode, or all Cert.
Transport security between all Access System components (Policy Managers, Access Servers, and associated WebGates) must match: either all open, all Simple mode, or all Cert.
Caveats
When access cache flushing is enabled on the Identity Server, the Identity Server communicates with the Access Server. In this case, the transport security mode between all five of the following components must be in the same mode.
Identity Servers and WebPass instances
Policy Managers, Access Servers, and associated WebGates
Use Open mode if transport security is not an issue in your environment. In Open mode, there is no authentication or encryption between the AccessGate and Access Server. The AccessGate does not ask for proof of the Access Server's identity and the Access Server accepts connections from all AccessGates. Similarly, Identity Server does not require proof of identity from WebPass.
Use Simple mode if you have some security concerns, such as not wanting to transmit passwords as plain text, but you do not manage your own Certificate Authority (CA).
In Simple mode communications between Web clients (WebPass and Identity Server, Policy Manager and WebPass, and Access Server and WebGate are encrypted using TLS v1. In both Simple and Cert mode, Oracle Access Manager components use X.509 digital certificates only. This includes Cert Authentication between WebGates and the Access Server where the standard cert-decode plug-in decodes the certificate and passes certificate information to the standard credential_mapping authentication plug-in.
Oracle Access Manager ships a CA with its own private key that is installed across all AccessGates and Access Server components. Oracle Access Manager does an additional password check to prevent other customers from using the same CA.
For each public key there is a corresponding private key that Oracle Access Manager stores in the aaa_key.pem file (or ois_key.pem for Oracle Access Manager). A program named openSSL in the \tools subdirectory generates the private key. The openSSL program is called automatically during installation of each AccessGate and Access Server. Unlike Cert mode, Oracle Access Manager has already generated the private key. The key is presented automatically during installation.
In Simple mode, as in Cert mode, you secure the private key with a Privacy Enhanced Mail (PEM) pass phrase that you specify during installation of each component. During installation, the PEM pass phrase may also be referred to as the Global Access Protocol pass phrase. The generic term "pass phrase" is often used in this manual.
|
Note: Before an AccessGate or Access Server can use a private key, it must have the correct pass phrase. The pass phrase is stored in a nominally encrypted file called password.lst. For Simple mode, the PEM pass phrase is the same for each WebGate and Access Server instance. |
If you do not store the password in a file during Access Server installation:
On Windows, you are prompted for the pass phrase every time you start the Access Server.
On Unix, you must use the -P option to pass the password whenever you launch the start_access_server script.
Use Cert (SSL) mode if you have an internal Certificate Authority (CA) for processing server certificates. In Cert mode, communication between WebGate and Access Server, and Identity Server and WebPass are encrypted using Transport Layer Security, RFC 2246 (TLS v1). In both Simple and Cert mode, Oracle Access Manager components use X.509 digital certificates only. This includes Cert Authentication between WebGates and the Access Server where the standard cert-decode plug-in decodes the certificate and passes certificate information to the standard credential_mapping authentication plug-in.
For each public key there exists a corresponding private key that Oracle Access Manager stores in the aaa_key.pem file for the Access Server (or ois_key.pem for Identity Server).
A program named openSSL in the \tools subdirectory generates the private key. This program is called automatically during installation of each AccessGate and Access Server. During installation, you present a certificate obtained from a CA.
You secure the private key with a Privacy Enhanced Mail (PEM) pass phrase that you specify when you install each component. In this manual, the term pass phrase is used.
|
Note: Before a WebGate or Access Server can use a private key, it must have the correct PEM pass phrase. The PEM pass phrase is also referred to as WebGate Pass Phrase and Transport Password. It can be stored in a nominally encrypted file called password.lst (or password.xml for Oracle Access Manager). It can be different for each WebGate and Access Server. |
During Oracle Access Manager installation, if you do not yet have a certificate you may request one. In this case, you can complete installation despite the pending certificate status. However, the component or system cannot be setup until the certificates are issued and copied into the appropriate directory.
It is important to note, that if you generate a certificate request:
You may complete installation as usual but you cannot perform set up if a request is pending.
You must locate the request in the component installation directory. For example:
IdentityServer_install_dir\identity\oblix\config\ois_req.pem
Usually, the .pem file contains some extra data plus the encrypted string that represents the request.
You must copy the following information into a certificate request field from your chosen CA and send the request to your CA; Oracle does not do this:
*-----------Begin request--------------- A97C7u54Sd0000lotsofrandomstuff864Ouwst 89111mmmIyoSSTKHS9670sd *-----------End request-----------------
When the CA returns the certificate, you can copy the certificate files to the appropriate component installation directory, then restart the component server or service. For example:
\IdentityServer_install_dir\identity\oblix\config
See the Oracle Access Manager Identity and Common Administration Guide for details.
If you do not store the pass phrase or password in a file during Access Server installation:
On Windows: You are prompted for the pass phrase every time you start the Access Server.
On UNIX: You must use the -P option to pass the password whenever you launch the start_access_server script.
For more information on transport security modes, see the Oracle Access Manager Identity and Common Administration Guide.
You will need one or more Web servers to host WebPass, Policy Manager, and WebGate components. The Identity Server and Access Server do not require a Web server instance. If you install WebPass and the Identity Server on the same Web server, the installation destination for WebPass cannot be the same as for Identity Server. If you install Policy Manager and WebPass on the same Web server, you must place them at the same directory level. For example, if you specify C:\COREid\WebComponent as the WebPass installation directory, you must also specify this as the Policy Manager installation directory when the two components will reside on the same machine. \identity is appended to the WebPass installation directory and \access is appended to the Policy Manager installation directory.Be sure that your Web server meets all requirements before you being installation. See also "Synchronizing System Clocks".
Task overview: Preparing your Web server
Ensure your Web server version is on the list of supported platforms (Policy Manager and WebPass Web Server and WebGate Web Server), which you can find under the Certify tab on https://metalink.oracle.com:
Log in to MetaLink as directed.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Application Server and click Submit.
Create new instances of your Web server running with your data to make it easier to make changes without taking down the service for other applications. See your Web server documentation for details.
Plan the Web server installation destination, and record details on "Installation Preparation Checklists".
For more information, see:
Separate Web server-specific installation packages are provided for WebPass, Policy Manager, and WebGate components. Be sure to choose the appropriate installation package for your Web server and platform:
ISAPI: An Internet Web server extension that Oracle Access Manager uses to identify Web server components that communicate with the Microsoft Internet Information Server (IIS Web server for Windows environments).
NSAPI: An Internet Web server extension that Oracle Access Manager uses to identify Web components that communicate with the Sun (formerly Netscape/iPlanet) Web servers running on either Windows or Solaris.
Apache: An Internet Web server extension that Oracle Access Manager uses to identify Web components that communicate with the Apache Web servers running on various platforms including Windows, Solaris, and Linux. For details, see "Confirming Platform Requirements"
|
Note: Oracle Access Manager supports Apache with or without SSL enabled. For SSL-enabled communication, Apache with mod_ssl only is supported, not Apache-SSL. mod_ssl is a derivative of, and alternative to, Apache-SSL. |
Oracle Access Manager 10g (10.1.4.0.1) provide a single package for components that supports Apache with or without SSL enabled. For example:
The APACHE_WebGate supports v1.3.x with or without SSL, as described in Chapter 16, "Configuring the Apache v1.3 and Oracle HTTP Server Web Servers".
The APACHE2_WebGate supports v2 with or without SSL (and with or without reverse proxy enabled on Solaris and Linux). See also Chapter 17, "Configuring Apache v2, IHS, and OHS Web Servers for Oracle Access Manager".
IHS: An Internet Web server extension that identifies Oracle Access Manager Web components that communicate with the IBM HTTP (IHS) Web servers powered by Apache running on various platforms. For example:
IHS_WebGate powered by Apache v.1.3.x on Solaris, Linux, and Windows
IHS2_WebGate powered by Apache v2 on IBM-AIX: See Chapter 17, "Configuring Apache v2, IHS, and OHS Web Servers for Oracle Access Manager".
OHS: An Internet Web server extension that identifies Oracle Access Manager Web components that communicate with the Oracle HTTP Server (OHS). Oracle provides OHS Web components based on open source Apache v1.3 (named OHS_...) and v2 (named OHS2_...). 10g (10.1.4.0.1) provides WebPass, Policy Manager, and WebGate components that can be installed on a standalone Oracle HTTP Server on Linux and Windows platforms.
An OHS or OHS2 WebGate must be installed on the Oracle Application Server to enable integration with Oracle single sign-on as described in the Oracle Access Manager Access Administration Guide.
OHS or OHS2 WebPass and "Access Manager" (original name represents the Policy Manager Web component) may be used with the Oracle Application Server. However, Apache WebPass and Access Manager (Policy Manager) Web components are also supported for this application.
See Chapter 16, "Configuring the Apache v1.3 and Oracle HTTP Server Web Servers" and Chapter 17, "Configuring Apache v2, IHS, and OHS Web Servers for Oracle Access Manager" for details. For version support, see the Certify tab on https://metalink.oracle.com.
Domino: An Internet Web server extension that Oracle Access Manager uses to identify Web components that communicate with Lotus Domino Web servers running on various platforms.
See Chapter 18, "Setting Up Lotus Domino Web Servers for WebGates". For version support, see the Certify tab on https://metalink.oracle.com.
It's a good idea to familiarize yourself with the following general considerations for Web servers in Oracle Access Manager installations:
Each instance of the Identity Server communicates with a Web server through a WebPass plug-in that must be installed on a Web server host.
If you install Policy Manager and WebPass on the same Web server, you must place them at the same directory level. For example, if you specify C:\COREid\WebComponent as the WebPass installation directory, you must also specify this as the Policy Manager installation directory when the two components will reside on the same machine. \identity is appended to the WebPass installation directory and \access is appended to the Policy Manager installation directory.
During WebPass, Policy Manager, and WebGate installation, your Web server must be configured to work with Oracle Access Manager. You can direct this Web server configuration update to occur either automatically or manually.
|
Note: Oracle recommends that you use the automatic configuration option to streamline the Web server update process and avoid errors. |
When accessing the Identity System or Policy Manager, you must specify the hostname of the Web server for the WebPass instance that connects to the targeted Identity System or Policy Manager and the HTTP port of the WebPass Web server instance.
Additional guidelines for WebGate Web servers are discussed in "WebGate Guidelines".
On a Unix system during WebPass, Policy Manager, and WebGate installation, you must specify the user name and group that the Web server will use. Typically, the defaults are nobody. For HP-UX, the defaults are WWW (username) and others (group).
On Linux systems, when installing Oracle Access Manager Web components with Apache and OHS you are prompted to install as the same user under which the Web server is running. This information is located in the httpd.conf file in the User and Group directive entries.
Your installation requires one or more directory servers. You need to ensure that your directory server meets requirements for Oracle Access Manager and is properly prepared before starting the installation.
|
Note: See also Appendix A, "Installing Oracle Access Manager with Active Directory" and Appendix B, "Installing Oracle Access Manager with ADAM", if needed. |
Task overview: Preparing your directory server
Ensure the directory server is on the list of supported platforms, as described under the Certify tab at https://metalink.oracle.com.
Log in to MetaLink as directed.
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Application Server and click Submit.
|
Note: The Siemens DirX directory is not supported in 10g (10.1.4.0.1). Although the installation screen may still display DirX as a possible option. |
Identify at least one person in your directory to use as the Master Administrator to complete installation and setup, as described in "Assigning a Bind DN" .
Estimate and ensure that you have adequate directory server space, as described in "Assessing Directory Server Space".
Determine how you will secure directory server communication with Oracle Access Manager components, as described in "Securing Directory Server Communications".
Ensure that one or more directory server instances are available for Oracle Access Manager installation and decide if you want to store user data separately from configuration and policy data, as described in "Data Storage Requirements".
Establish a searchbase, configuration DN, and policy base for data, as described in:
Record your Person and Group object classes, as described in "About Person and Group Object Classes".
Record directory server details, as described in "Installation Preparation Checklists", including:
Host name and IP address, network port, and Root DN of each directory server.
User logon id and password for the directory server.
Decide how you plan to update the schema (automatically or manually), as described in "Updating the Schema and Attributes Automatically Versus Manually".
See the Oracle Access Manager Identity and Common Administration Guide for details about making schema data available to Oracle Access Manager.
The inheritance of all objects is based on the premise of a common super class for both the structural object class and the auxiliary class. Otherwise, object class extension is not feasible.
During installation and setup of the Identity Server and Policy Manager, you are asked to provide a bind DN (also known as Root DN in Oracle Access Manager). The directory account that Oracle Access Manager binds to should have Read, Write, Add, Delete, Search, Compare, and Selfwrite permissions. The method to create a user with these privileges varies among directory vendors. See your directory documentation for details.
Be sure that the native directory access control instructions (ACIs) and access control lists (ACLs) do not restrict the Oracle Access Manager bind DN account access to the user and configuration branches. Otherwise, the Oracle Access Manager bind DN may be affected by native directory server constraints such as password policies.
In addition, the user you create as the bind DN must have access to the schema when Oracle Access Manager software upgrades are performed, because the schema may be modified during the upgrade. If the schema is not accessible to the bind DN, the upgrade will fail, then manual action will be required to complete the upgrade. This includes having the ACLs modify directory schema entries.
Take the following guidelines into account:
Oracle Internet Directory: When installing the Identity Server with Oracle Internet Directory, you must designate the Root DN as the super user cn=orcladmin (not the fully qualified DN cn=orcladmin,cn=users,dc=us,dc=mycompany,dc=com.
Sun (formerly iPlanet): Oracle recommends that the bind DN user is not Directory Manager. Instead, create another user as a bind DN. The Directory Manager account will ignore your directory server's size and timeout limits. As a result, large searches could tie up the directory server.
For more information, see also "User Data and the Searchbase".
The directory server should have at least 1 KB of RAM for each user object. Each Oracle object should have at least 16 KB of RAM. The following information is provided to help you calculate the space that will be required for your installation:
A directory server with 250,000 user objects requires ~250 MB of RAM.
A directory of this size may have 5,000 Oracle objects (a high estimate for 250,000 user entries), which would require an additional 80 MB.
The indexes for this amount of data would require about twice the space of Oracle objects, approximately 160 MB.
The Identity Server, Policy Manager, and Access Server communicate with the directory server. During Oracle Access Manager installation and setup, default directory profiles are created for the components that communicate with the directory server. Each directory profile includes a database (DB) instance profile where the directory server communication method is indicated, among other things. Two communication methods are available between Oracle Access Manager and the directory server: unsecured or secured. Secure communication between Oracle Access Manager and the directory server is also known as SSL-enabled. Unsecured communication is also referred to as Open.
Oracle Access Manager supports CA certificates in base64 format. SSL-enabled communication requires a signer's certificate (root CA certificate) from a third-party Certificate Authority in base64 format. For example, if you want to use SSL between a Identity Server and directory server, you will be prompted to provide the path to the certificate to establish SSL-enabled communication during Identity Server installation. In this case, a certificate must be installed on your directory server according to the instructions for the directory server. The directory server should not require client authentication (see the directory server documentation for instructions).
When configuring SSL for the directory server, note that Oracle Access Manager supports server authentication only. Client authentication is not supported. Oracle Access Manager verifies the server certificate against the Root CA certificate that you imported during product setup.
When planning and configuring communication between Oracle Access Manager and the directory server, the following guidelines apply:
Communication between Identity Servers and the directory server may differ.
Communication between Access Servers and the directory server may differ.
Communication between all Policy Managers and the directory server must be consistent: all SSL-enabled or all open.
|
Note: When storing user data on a different directory server type than configuration and policy data, multiple root CA certificates are supported. When storing user data, configuration data, and policy data on directory server types, each can use a separate root CA. For more information, see "Data Storage Requirements". |
SSL-enabled communication with the directory server is not supported when the Policy Manager is installed on Solaris with a Sun (previously Netscape) Web server. In a heterogeneous environment that includes an Policy Manager on Solaris, be sure to specify open communication between the directory server and all Policy Managers you install.
Oracle Access Manager components can share a DB profile even when components were not installed to use the same communication mode with the directory server. For example, suppose the Identity Server and Access Server were installed in open mode and the Policy Manager was installed with SSL enabled. In this case, the cert8.db and key3.db files must exist for each Oracle Access Manager component that communicates with the directory server and must reside in the Oracle Access Manager Component_install_dir\identity|access\oblix\config directory. You may either copy these files from other Oracle Access Manager component directories or run genCert (Policy Manager) or other utilities to generate them.
|
Note: Oracle Access Manager 10g (10.1.4.0.1) works with both the cert7.db (upgraded environments) and cert8.db (new installations) certificate store. For details about upgraded environments, see the Oracle Access Manager Upgrade Guide. |
All Directory Servers: When configuring SSL for any directory server, be aware that Oracle Access Manager supports server authentication only. Client authentication is not supported. Oracle Access Manager verifies the server certificate against the Root CA certificate that you imported during product setup.
Task overview: Defining directory server communication security
Before Oracle Access Manager installation, review all directory server requirements for 10g (10.1.4.0.1), as described here and in "Meeting Directory Server Requirements".
Before Oracle Access Manager installation, enable SSL on your directory server, if desired, as described in the documentation for your directory server vendors and certificate. For example:
Create a directory server instance if you do not have one.
Apply to your CA for a certificate for that instance.
Install the certificate to encrypt your directory server instance and restart the directory server.
|
Note: When storing user data on a different directory server type than configuration and policy data, multiple root CA certificates are supported. |
During Identity Server installation, choose the appropriate communication between the directory server and the Identity Server, as described in "Securing Directory Server Communications".
During Identity System setup, choose the appropriate communication between the directory server and the Identity System, as described here and in Chapter 6, "Setting Up the Identity System".
|
Note: When using certificates generated by a subordinate CA, the root CA's certificate must be present in the xxx_chain.pem along with the subordinate CA certificate. Both certificates must be present to ensure appropriate verification and successful Identity System setup. |
During Policy Manager installation and setup, choose the appropriate communication between the directory server and the Policy Manager, as described in "Securing Directory Server Communications".
During Access Server installation, choose the appropriate communication between the directory server and the Access Server, as described in "Securing Directory Server Communications".
After installation, you may change the communication mode between Oracle Access Manager and the directory server, as described in the Oracle Access Manager Identity and Common Administration Guide.
This discussion provides details about data storage options and requirements. This information affects the Identity Server, Policy Manager, and Access Server.
All Directory Server Types: Oracle Access Manager supports storing user data, Oracle Access Manager configuration data, and policy data on a single directory server. In addition, you can store user data separately on one directory server type and Oracle Access Manager configuration and policy data on a different type of directory server. For example, you may store user data in Active Directory and Oracle Access Manager configuration and policy data on ADAM (or Oracle Internet Directory). When storing user data on a separate directory server type from configuration and policy data:
All user data must be stored on the same directory server type.
Configuration and policy data must be stored on the same type of directory server.
With SSL, separate root CA's are supported.
Figure 2-1 illustrates storing user data in a separate directory server type from configuration and policy data.
Figure 2-1 User Data in a Separate Directory Server Type
If the data is stored in different directory types, the user data searchbase, configuration DN, and policy base, should be unique.
During Oracle Access Manager installation and setup, you need to select proper user and configuration directory server types for your environment.
When you have configuration and policy data stored together in a different directory server type from user data, the following file comes into play:
IdentityServer_install_dir\identity\oblix\data\common\ldaposdreferentialintegrityparams.xml
This is because the "referential_integrity_using" Value="oblix" in the ldapreferentialintegrityparams.xml file does not apply when configuration and policy data are stored on a different directory server type from user data
Also, in this case, the following files are used by the Identity System and Access System to map servers to DB profiles rather than the original exclude_attrs files:
IdentityServer_install_dir\identity\oblix\data\common\
PolicyManager_install_dir\access\oblix\data\common\
AccessServer_install_dir\access\oblix\data\common\
exclude_oblix_attrs.lst
All parameters for the user data directory server are read using the DB profile. For the configuration data directory server, the DB subtype is read from:
Component_install_dir\identity|access\oblix\config\ldap\*DB.xml
Data Anywhere: This directory server option is available for only the user data directory server and implementation with Oracle Virtual Directory described in Chapter 10, "Setting Up Oracle Access Manager with Oracle Virtual Directory".Data Anywhere is a data management layer that aggregates and consolidates user data from multiple sources (including RDBMS and LDAP directories) into a virtual LDAP tree that can be managed by the Identity System and used to support authentication and authorization using the Access System. The LDAP directory branches containing Oracle Access Manager configuration and policy data must reside on one or more directory servers other than the one hosting VDS or user data. Oracle Access Manager applications only recognize configuration and policy information that resides outside the VDS virtual directory.
|
WARNING: Before you install Oracle Access Manager for use with Data Anywhere, read Chapter 10, "Setting Up Oracle Access Manager with Oracle Virtual Directory" and complete activities as specified. |
IBM Directory Server (formerly SecureWay): See preceding details for all directory server types.
Oracle Internet Directory, and Sun: Oracle Access Manager supports storing user data separately from configuration and policy data with Oracle Internet Directory (multiple realms), and Sun directory servers. With these directory servers, you can store data either together on the same directory server or on different directory servers of the same type. For example:
User data may be stored either separately or with configuration data.
Configuration data may be stored separately or with user data.
Policy data may either be stored separately or with user data.
If data is stored in different directories, the user data searchbase, configuration DN, and policy base should be disjoint. In other words, these DNs must be unique if you are storing your policy and configuration data in different Sun directories, or multiple Oracle Internet Directory realms.
|
Note: With Oracle Internet Directory, the configuration DN value is populated from the context of the identity management realm (cn=OracleContext). Also by default, the searchbase is the same as the configuration DN. |
If you intend to have more than one user data directory and searchbase, be sure to specify the main user data directory and searchbase during installation and setup.
Active Directory, ADAM, and Novell eDirectory Caveats
Due to the strict adherence to referential integrity by Novell's eDirectory, Active Directory, and Active Directory Application Mode (ADAM), Oracle Access Manager configuration data and policy data must be stored under a common directory environment. Novell eDirectory, Active Directory, and ADAM are more rigid in the implementation of LDAP and will enforce referential integrity. These directory servers will not allow data in two separate trees/forests with cross references [like DN references] to each other.With Oracle Access Manager, what is meant by having separate directories for user versus product configuration data and policy data is that you can have separate LDAP [disjoint] trees on different servers all of which happen to be in the same Novell directory server tree or Active Directory forest. Oracle Access Manager configuration data and policy data can be stored in separate parts of the overall directory environment, which does allow for a level of segregation of the Oracle Access Manager-specific information away from your user data.
On Active Directory: In an Active Directory environment you may store Oracle Access Manager configuration data on one specific domain controller and policy data on another. The policy data and configuration data domain controllers should be in the same forest. user data may reside in a different forest. It is important that replication be either avoided, or very well understood. For more information, see Appendix A, "Installing Oracle Access Manager with Active Directory".
When storing user data on a separate directory server type from configuration and policy data, auxiliary class support should match. Oracle Access Manager does not support a mixed mode for dynamic-auxiliary support. You can connect to either the user data directory server or configuration data directory server using ADSI, if they are in separate forests. ADSI does not allow a bind against both forests at the same time. With ADSI enabled for:
The User Data Directory Server—During Identity Server and Policy Manager setup, if ADSI is selected for the user data directory server type then the ADSI checkbox is not available when choosing configuration directory server type details.
The Configuration Data Server—When this directory type is ADSI enabled:
In the globalparams.xml file on the Identity Server, the parameter "IsADSIEnabled" and value "true" should appear.
In the globalparams.lst file on the Policy Manager, the parameter "adsiEnabled"=true appears.
The dbSubType "adsiEnabled" flags for Active Directory are read using the DB profile. Its value is ADSI when ADSI is enabled for the user data directory server. The ActiveDirectory and ADAM flags are removed from the globalparams.xml files.
See Appendix A, "Installing Oracle Access Manager with Active Directory" for more information.
If the user data directory server type is Active Directory, content of exclude_attrs-ad.xml are copied to:
IdentityServer_install_dir\identity\oblix\data\common\exclude_user_attrs.xml
If the configuration and policy data directory type is Active Directory, content of exclude_attrs-ad.xml .lst are copied to the following locations:
IdentityServer_install_dir\identity\oblix\data\common\exclude_oblix_attrs.xml
PolicyManager_install_dir \access\oblix\data\common\exclude_oblix_attrs.lst
AccessServer_install_dir\access\oblix\data\common\exclude_oblix_attrs.lst
|
Note: The ActiveDirectory flag longer appears in globalparams.xml. |
With ADAM: Data can be stored as follows:
User data may be stored on a different partition from configuration and policy data.
User data may be stored on a separate directory server type from configuration and policy data.
Oracle Access Manager requires a node with the object class attribute value of organizationalUnit (ou) for the configuration and policy DNs.
Configuration and policy data can share the same ADAM instance or be stored on different ADAM instances.
For more information, see Appendix B, "Installing Oracle Access Manager with ADAM".
Novell eDirectory: To avoid problems with GroupOfUniqueNames, change the class mapping for Groups in the LDAP Group object to reference GroupOfUniqueNames instead of groupOfNames (the default). Otherwise, each time you save any attribute, the schema may be violated and your groups may not work correctly. For example, for NDS the "groupOfUniqueNames" LDAP group object should be listed before the "groupOfNames" object.
To change the order using the NDS Console1
Expand the NDS tree.
For the NDS node in the left pane, right-click the "LDAP Group" object in the right pane and select Properties, Class Map tab.
Change the order in which the two group objects appear.
See your Novell eDirectory documentation for details about adding this mapping.
User data consists of user directory entries managed by the Identity System. This data includes the information related to users, groups, locations, and other generic objects managed by the Identity System.
When installing Oracle Access Manager, you need to provide the following information to set up the main directory server profile:
Bind information, including the DNS host name, port, user name (bind DN), password
Searchbase, to identify the node in the directory information tree (DIT) under which this data is stored and the highest possible base for all user data searches
Master Administrators (one or more)
Automatically updating the directory during setup is recommended to load Oracle Access Manager schema classes with configuration information.
Be sure to observe the following guidelines apply:
Oracle Internet Directory: When installing the Identity Server with Oracle Internet Directory, you must designate the Root DN as the super user cn=orcladmin, not the fully qualified DN (for example, not cn=orcladmin,cn=users,dc=us,dc=mycompany,dc=com).
Sun (formerly iPlanet): Oracle recommends that the bind DN user is not Directory Manager. Instead, create another user as a bind DN. The Directory Manager account will ignore your directory server's size and timeout limits. As a result, large searches could tie up the directory server.
For more information, see "Data Storage Requirements".
Configuration data (Oracle Access Manager configuration details), are stored in the directory. This data includes workflow and configuration information that governs the appearance and functionality of the Identity System and Access System. Configuration data is managed by the Identity System.
When installing Oracle Access Manager, you need to provide details for the directory server where you plan to store configuration data. If you store configuration data and user data together, this information will be the same. The following caveats apply:
The bind DN for configuration data may be anywhere except at the base suffix.
A bind DN for configuration data (known as the configuration DN) is similar to the searchbase for user data and must be specified to identify the node in the DIT under which the Oracle Access Manager schema and all configuration data is stored for the Identity and Access Systems.
Additional caveats may apply, as described under "Data Storage Requirements".
|
Note: With Oracle Internet Directory, the configuration DN value is populated from the context of the identity management realm (cn=OracleContext). Also by default, the searchbase is the same as the configuration DN. |
Again, automatically updating the directory during setup is recommended to load Oracle Access Manager schema classes with configuration information.
Oracle Internet Directory: With Oracle Internet Directory, the configuration DN value is populated from the context of the identity management realm (cn=OracleContext). Also by default, the searchbase is the same as the configuration DN. For multiple realm installations, see the Oracle Access Manager Identity and Common Administration Guide for details about setting up a disjoint searchbase after installing and setting up the Identity System.
Policy data consists of policy definitions and rules that govern access to resources. This data is maintained in the directory server by the Policy Manager.
When installing Oracle Access Manager, you need to provide details for the directory server where you plan to install policy data. If you store policy data separately from user data, directory server details will differ from those specified for user or configuration data. For more information, see "Data Storage Requirements".
During Policy Manager setup, you must also provide the policy base to identify the location in the DIT under which all Oracle Access Manager policy data is stored and the highest possible base for all policy searches. Accepting the default "/" as the policy domain when setting up the Policy Manager protects the entire Web server.
Oracle Access Manager supports User and Group as standard Person and Group object classes, respectively. In addition, Oracle Access Manager supports User and Group.
The Person object class defines the user's profile information. If you do not have a specific object class to use, Oracle Access Manager can automatically configure commonly found Person object class definitions.
User: Active Directory
InetOrgPerson: ADAM, Data Anywhere (Oracle Virtual Directory), IBM, Oracle Internet Directory, and Sun directory servers
The Group object class defines group attributes. If you do not have a specific object class to use, Oracle Access Manager can automatically configure commonly found Group object class definitions as follows:
Oracle Access Manager 10g (10.1.4.0.1) supports a variety of operating systems, directory servers, Web servers, compilers, and browsers, and integration with a number of application servers, portal servers, system management products, and packaged applications.
For the latest support information, see details under the Certify tab on:
http://metalink.oracle.com
To use MetaLink
Navigate to http://metalink.oracle.com.
Log in to MetaLink as directed
Click the Certify tab.
Click View Certifications by Product.
Select the Application Server option and click Submit.
Choose Oracle Application Server and click Submit.
To download free release notes, white papers, or other collateral, please visit the Oracle Technology Network (OTN). You must register online before using OTN. Registration is free and can be accomplished at the following site:
http://www.oracle.com/technology/membership/
If you already have a user name and password for OTN, you can go directly to the documentation section of the OTN Web site at:
http://www.oracle.com/technology/documentation/
Oracle Access Manager installation media provides all product packages that you need to install Oracle Access Manager components, including Language Packs. It is a good idea to copy these packages into a temporary installation directory that differs from the any directory where you plan to install Oracle Access Manager components. If you plan to install Oracle Access Manager components with one or more Language Packs, you must copy the needed Language packages into the same temporary directory as the component installer. Otherwise, the component installer cannot detect the Language Packs and offer these for installation. If you are not installing any Language Packs, you may install the desired Oracle Access Manager component directly from the installation media.
To store Oracle Access Manager installers for installation
Create a temporary directory in which to store Oracle Access Manager component installers, including all needed Language Pack installers for the Identity System and Access System.
Copy the Oracle Access Manager packages from the installation media into the temporary directory from which you can install the component and any Language Packs together, at the same time.
During component installation: Run the installer from the temporary directory as instructed in appropriate chapters of this manual.
During Oracle Access Manager component installation, information is saved after certain operations. Until information is saved, you may return and restate details. However, after you are informed that a component is being installed, Oracle Access Manager files are added to the file system.
Some changes made for Oracle Access Manager are not handled automatically and must be manually removed when the Uninstaller program finishes. For details about removing Oracle Access Manager components, see Chapter 20, "Removing Oracle Access Manager".
Under certain circumstances, you may want to reuse an existing Identity Server name. If you do not delete the original Identity Server name from the System Console, a login following the set up of a new instance may result in the message "Application has not been set up". Special steps must be taken to ensure you can set up the application and login when recycling an Identity Server name. For details, see "Recycling an Identity Server Instance Name".
Installation of Oracle Access Manager requires some planning and the checklists in this discussion are provided for your convenience. For example, the checklists in Table 2-3:
Provide a space where you can map out and record your environment.
Help you prepare to answer prompts during Oracle Access Manager installation and setup.
Are organized according to the recommended component installation sequence described under "About the Installation Task", and the installation process for each component.
Provide a reference to a specific page number in this manual where you will find additional information.
Table 2-3 Installation Preparation Checklists
| Task | Subtask | Checklist: Prepare for Oracle Access Manager Installation and Setup | Reference |
|---|---|---|---|
|
1 to 3 |
Prepare for Identity System Installation and Setup |
||
|
1 |
Prepare for Identity Server Installation |
||
|
1.1 |
Default Locale (Administrator Language) |
||
|
Languages Language Packs |
|||
|
1.2 |
Transport security mode between the Identity Server and WebPass:
|
See "Securing Oracle Access Manager Component Communications" |
|
|
1.3 |
Unique Identity Server ID to be used within Oracle Access Manager to identify this Identity Server instance: |
||
|
Host name of the machine where the Identity Server is to be installed: |
|||
|
Port number for Identity Server/WebPass communication: |
|||
|
Is this the first Identity Server installed for this directory server?
|
|||
|
1.4 |
Security mode between directory server and Identity Server:
|
||
|
If SSL, path to the Root CA certificate: |
|||
|
Simple mode onlyGlobal Access Protocol pass phrase |
|||
|
Cert Mode OnlyCertificate PEM pass phrase: |
|||
|
Path of the certificate request file (Cert request only): |
|||
|
Path of the certificate file (Cert mode only): |
|||
|
Path of the key file (Cert mode only): |
|||
|
Path of the chain file (Cert mode only): |
|||
|
1.5 |
Prepare directory server detailsLocation of configuration data in the directory server:
|
||
|
Directory server type:
Note: Data Anywhere (Oracle Virtual Directory Server) is available only for the user data directory server. Configuration and policy data must be stored in a native directory. |
Before you install Oracle Access Manager with Data Anywhere, see Chapter 10, "Setting Up Oracle Access Manager with Oracle Virtual Directory". |
||
|
Directory server host machine name or IP address: |
|||
|
Directory server port #: |
|||
|
Directory server bind DN: |
|||
|
Directory server administration password: |
|||
|
1.6 |
(Windows only) Unique Identity Server service name that will differentiate this instance in the Services window if you install several instances of Identity Server): |
||
|
2 |
Prepare to install WebPass. Decide on the following: |
||
|
2.1 |
Default Locale (Administrator Language) |
||
|
Languages Language Packs Same Language Packs as the Identity Server |
|||
|
Web server user name (Unix only): |
|||
|
Web server group (Unix only): |
|||
|
WebPass installation directory. If installing on the same machine as the Identity Server, this cannot be the same as the Identity Server installation directory: |
|||
|
2.2 |
Transport security mode between the Identity Server and WebPass: |
See task 1, this table See Securing Oracle Access Manager Component Communications. |
|
|
WebPass ID used by Oracle Access Manager to identify the WebPass instance: |
|||
|
2.3 |
WebPass host name: |
||
|
Port # for Identity Server/WebPass communication: |
See task 1, this table |
||
|
Simple mode onlyGlobal Access Protocol pass phrase |
See task 1, this table |
||
|
Cert mode onlyCertificate PEM phrase: |
|||
|
Path of the certificate request file (Cert request only): |
|||
|
Path of the certificate file (Cert mode only): |
|||
|
Path of the key file (Cert mode only): |
|||
|
Path of the chain file (Cert mode only): |
|||
|
2.4 |
Automatically update your Web server with WebPass information?
|
||
|
If Yes, absolute path of the Web server configuration directory containing the obj.conf file (or the httpd.conf file on Apache): |
|||
|
3 |
Prepare for Identity System Setup Decide on the following: |
||
|
3.1 |
Directory server type: |
See task 1, this table |
|
|
Directory server host machine name or IP address: |
See task 1, this table |
||
|
Directory server port #: |
See task 1, this table |
||
|
Directory server bind DN: |
See task 1, this table |
||
|
Directory server administration password: |
See task 1, this table |
||
|
Security mode between directory server and Identity Server: |
See task 1, this table |
||
|
Is the configuration data stored in the user data directory server? |
See task 1, this table |
||
|
Configuration DN: |
|||
|
Directory searchbase where user data is stored: |
|||
|
3.2 |
Person object class: |
||
|
Auto-configure the Person object class?
|
|||
|
Group object class: |
|||
|
Auto-configure the Group object class?
|
|||
|
Configure the Person object class (manual process is optional). Configure the following attributes if you chose not to auto-configure your Person object class: |
|||
|
User full name attribute: |
|||
|
User login ID attribute: |
|||
|
Password attribute: |
|||
|
3.3 |
Configure the Group object class (manual process is optional). Configure the following attributes if you chose not to auto-configure your Group object class: |
||
|
Group name attribute: |
|||
|
3.4 |
Prepare to define Master Administrators |
||
|
Master Administrators (The Master Administrator): |
|||
|
4 to 8 |
Prepare for Access System Installation and Setup |
||
|
4 |
Prepare to install the Policy Manager.Decide on the following: |
||
|
4.1 |
Install a WebPass for this Policy Manager, as described in Chapter 5, "Installing WebPass" and:
|
||
|
4.2 |
Default Locale (Administrator Language) |
||
|
Languages Language Packs Same Language Packs as Identity System |
See task 1, this table |
||
|
Web server user name (Unix only): |
See task 2, this table. |
||
|
Web server group (Unix only): |
See task 2, this table. |
||
|
WebPass installation directory: |
See task 2, this table. |
||
|
4.3 |
Directory server type:
Note: Data Anywhere (Oracle Virtual Directory Server) is available only for the user data directory server and is not an option for the Policy Manager or Access Server. |
Configuration and policy data must be stored in a native directory, as described in Chapter 10, "Setting Up Oracle Access Manager with Oracle Virtual Directory". |
|
|
Are you storing your policy data separate from your user data directory server?
|
|||
|
4.4 |
Transport security mode between the Policy Manager and Access Servers:
|
See Securing Oracle Access Manager Component Communications. |
|
|
Simple mode onlyGlobal Access Protocol pass phrase: |
|||
|
Cert mode onlyCertificate PEM pass phrase: |
|||
|
Path of the certificate request file (Cert mode only): |
|||
|
Path of the certificate file (Cert mode only): |
|||
|
Path of the key file (Cert mode only): |
|||
|
Path of the chain file (Cert mode only): |
|||
|
4.5 |
Automatically update the Web server configuration file with Access System information? - Yes - No |
||
|
If Yes, absolute path of the Web server configuration directory containing the obj.conf file (or the httpd.conf file on Apache): |
See task 2 |
||
|
5 |
Prepare to set up the Policy Manager. Fill in the following based on this Policy Manager installation: |
||
|
5.1 |
Directory server type: |
See task 4. |
|
|
Directory server host machine name or IP address: |
See task 4. |
||
|
Directory server port #: |
See task 4. |
||
|
Directory server bind DN: |
See task 4. |
||
|
Directory server administration password: |
See task 4. |
||
|
Security mode between the directory server and the Policy Manager: - Open - SSL |
|||
|
If SSL, path to the SSL certificate: |
|||
|
Location of configuration data in the directory server: - User data directory server - Separate directory server |
|||
|
If on separate directory server, the directory server host machine name or IP address: |
|||
|
If on separate directory server, the directory server port #: |
|||
|
If on separate directory server, the directory server bind DN: |
|||
|
If on separate directory server, the directory server administration password: |
|||
|
If on separate directory server, the security mode between the directory server and the Policy Manager: - Open - SSL |
|||
|
If SSL, path to the SSL certificate: |
|||
|
Location of policy data in the directory server: - User data directory server- Configuration data directory server- Separate directory server |
|||
|
If on separate directory server, the directory server host machine: |
|||
|
If on separate directory server, the directory server port #: |
|||
|
If on separate directory server, the directory server bind DN: |
|||
|
If on separate directory server, the directory server administration password: |
|||
|
If on separate directory server, the security mode between the directory server and the Policy Manager: - Open - SSL |
|||
|
If SSL, path to the SSL certificate: |
|||
|
Directory searchbase where user data is stored: |
See task 3. |
||
|
Configuration DN: |
See task 3. |
||
|
Policy base: |
|||
|
Person object class name: |
See task 3. |
||
|
Policy Manager policy domain root: |
|||
|
5.2 |
Configure authentication schemes? - Yes - No |
||
|
If Yes, select authentication scheme or schemes: Configure Oracle Access Manager-related authentication schemes and policy domains Authentication Schemes - Basic Over LDAP - Client Certificate - Anonymous - Oracle Access and Identity - Oracle Access and Identityfor AD Forests Policy Domains - Identity Domain - Access Domain |
|||
|
Configure policies to protect Oracle Access Manager-related URLs? - Yes - No |
|||
|
6 |
Prepare to Create an Access Server Instance in the Access System Console Before you continue, you must decide on the following: |
||
|
6.1 |
Access Server name (do not include spaces): |
||
|
Access Server host name: |
|||
|
Port # the Access Server listens to: |
|||
|
Transport security mode between the Access Server and WebGate: - Open - Simple - Cert |
See Securing Oracle Access Manager Component Communications. |
||
|
6.2 |
Create an Access Server instance in the Access System Console |
See "Creating an Access Server Instance in the System Console" |
|
|
7 |
Prepare to Install the Access Server. |
||
|
7.1 |
Default Locale (Administrator Language) |
||
|
Languages Language Packs Same Language Packs as Policy Manager |
|||
|
Web server user name (Unix only): |
|||
|
Web server group (Unix only): |
|||
|
Access Server installation directory: |
|||
|
7.2 |
Transport security mode between the Access Server and the WebGate/AccessGate: |
See task 6 |
|
|
7.3 |
Security mode between the configuration data directory server and the Access Server: - Open - SSL |
||
|
Configuration Data Directory Server host machine: Same as Policy Manager DS? --Yes --No |
|||
|
Configuration Data Directory server port #: Same as Policy Manager DS? --Yes --No |
|||
|
Configuration Data Directory server bind DN: Same as Policy Manager DS? --Yes --No |
|||
|
Configuration Data Directory server administration password: Same as Policy Manager DS? --Yes --No |
|||
|
Configuration Data Directory server type: - Sun Directory Server 5.x - NDS - Active Directory - Active Directory Application Mode - IBM Directory Server Note: You will be asked about Active Directory using ADSI whenever the Access Server installation occurs on a Windows platform. |
|||
|
Which directory server stores the configuration data? |
See task 1. |
||
|
Which directory server stores the policy data? |
See task 1. |
||
|
Access Server name: |
See task 6. |
||
|
Configuration DN: |
See task 3. |
||
|
Policy Base: |
See task 4. |
||
|
Simple mode onlyGlobal Access Protocol pass phrase: |
See task 4. |
||
|
Cert mode onlyCertificate PEM phrase: |
|||
|
Save PEM phrase in a password file? (Simple and Cert modes only): - Yes - No |
|||
|
Path of the certificate request file (Cert mode only): |
|||
|
Path of the certificate file (Cert mode only): |
|||
|
Path of the key file (Cert mode only): |
|||
|
Path of the chain file (Cert mode only): |
|||
|
8 |
Prepare to Create a WebGate instance in the Access System Console.Before you continue, you must decide on the following: |
||
|
8.1 |
WebGate name (do not include spaces): |
||
|
WebGate host name: |
|||
|
Web server port #: |
|||
|
WebGate password/confirm password: |
|||
|
Transport security mode between the Access Server and WebGate: |
See task 6. |
||
|
8.2 |
Define a WebGate instance in the Access System Console |
||
|
8.3 |
Associate the WebGate with an Access Server |
||
|
9 |
Prepare to install the WebGate.Before you continue, you must decide on the following: |
||
|
9.1 |
Default Locale (Administrator Language) |
||
|
Languages Language Packs Same Language Packs as Policy Manager and Access Server |
|||
|
Web server user name (Unix only): |
|||
|
Web server group (Unix only): |
|||
|
WebGate installation directory (can be same as WebPass installation directory): |
|||
|
9.2 |
Transport security mode between the Access Server and the WebGate: |
See task 6. |
|
|
9.3 |
WebGate ID: |
See task 8. |
|
|
WebGate password: |
See task 8. |
||
|
Access Server ID: |
See task 6. |
||
|
Access Server host name: |
See task 6. |
||
|
Access Server port #: |
See task 6. |
||
|
Simple mode only Global Access Protocol pass phrase: |
See task 6. |
||
|
Cert mode only Certificate PEM phrase: |
|||
|
Path of the certificate request file (Cert mode only): |
|||
|
Path of the certificate file (Cert mode only): |
|||
|
Path of the key file (Cert mode only): |
|||
|
Path of the chain file (Cert mode only): |
|||
|
9.5 |
Automatically update the Web server configuration file? - Yes - No |
||
|
If Yes, absolute path of the Web server configuration directory containing the obj.conf file (or the httpd.conf file on Apache): |
|||
|
10 to 14 |
Intended Optional Components |
||
|
10 |
Oracle Virtual Directory Server (Data Anywhere components) - Yes - No |
See Chapter 10, "Setting Up Oracle Access Manager with Oracle Virtual Directory" |
|
|
11 |
SNMP Agent (optional) - Yes - No |
||
|
12 |
Audit-to-database components - Yes - No |
See Chapter 13, "About Installing Audit-to-Database Components" |
|
|
13 |
Language Packs, Independent Installation (optional) - Yes - No |
||
|
14 |
Software Developer Kit (SDK) is optional. - Yes - No |
