| Oracle® Access Manager Installation Guide 10g (10.1.4.3) E12493-02 |
|
 Previous |
 Next |
| Oracle® Access Manager Installation Guide 10g (10.1.4.3) E12493-02 |
|
Previous |
Next |
This chapter provides important information you need to prepare your environment before starting the installation process for Oracle Access Manager components. Failure to complete all prerequisites may adversely affect your installation. Topics include:
For an overview of Oracle Access Manager components, features, functions, audiences, and manuals, see the Oracle Access Manager Introduction.
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 the Oracle Access Manager Deployment Guide to gain an understanding of the characteristics of various deployment types and scenarios, as well as capacity planning and performance tuning recommendations.
Review "About Installation Packages, Patch Sets, Bundle Patches, and Newly Certified Agents" to ensure that you have the correct packages to perform a full, fresh Oracle Access Manager installation.
Review "About the Installation Task, Options, and Methods" and decide which installation options are best for your environment.
Synchronize the host clocks if you are installing across multiple computers, 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 Certification 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 computer running a non-English (American) language or territory operating system, see Chapter 3 for details about multi-language environments and complete any activities needed.
Oracle Access Manager relies on synchronized time clocks and each host computers' Operating System to correctly manage time. Access Server clocks can be ahead of WebGates by no more than 60 seconds. Webgate clocks should never be ahead of Access Server clocks.
When the Operating System time clock is operating properly, Oracle Access Manager operates properly. Usually, network time protocol (NTP) is used to manage and synchronize Operating System time clocks.
If you plan to install Oracle Access Manager components across multiple computers, 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. This can cause login events to fail. When running in Simple or Cert mode, time stamps may become out of sync, or the client certificate may appear to be invalid.
For successful operation:
Ensure all computer 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 computer 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 computer running the WebPass is not running ahead of the Identity Servers and Policy Managers with which it is associated.
|
Note: Time management includes changes for daylight savings time. Daylight savings time changes have no impact on Oracle Access Manager. |
USA 2007 Daylight Saving Time (DST) Compliance for Oracle Database and Oracle Fusion Middleware Products: In calendar year 2007, the effective dates for daylight savings are going to change. In the United States, the Energy Policy Act of 2005 was signed into law to extend daylight saving time. Under the new rules, DST in the U.S. will start on the second Sunday in March and end the first Sunday in November. In the past, daylight savings time started on the first Sunday in April and ended the last Sunday in October.
This change also affects Canada. Unless the required patches are applied, the database may report incorrect time zone data between March 11, 2007 and April 1, 2007 and between October 28, 2007 and November 4, 2007 (and on different dates in subsequent years). Mexico is still using the old DST rules.
For more information about the impact of USA 2007 DST compliance for Oracle Database and Oracle Fusion Middleware products, see Note: 397281.1 on My Oracle Support (formerly MetaLink) Web site: https://metalink.oracle.com.
USA 2007 Daylight Saving Time (DST) Compliance for Oracle Access Manager Products: Follow the recommendations of Operating System vendors for any required DST changes. In addition, ensure that system clocks of computers hosting Oracle Access Manager components are synchronized, as discussed earlier in this section.
|
Note: Only Oracle Access Manager patches are required for the Identity Server or Access Server. However, Oracle Access Manager interacts with other components that may be impacted by DST changes such as Web servers, applications servers, LDAP directories and databases. Check your vendor documentation and ensure that any required patches are applied to other affected components. |
US 2007 DST Changes For Oracle Internet Directory and Oracle Application Server: Only the database has potential DST issues with the 2007 DST change, and then only if timezones are set up. A compliant Operating System is needed. For more information, review the following notes at My Oracle Support (formerly MetaLink).
Note 357056.1—Impact of changes to daylight saving time (DST) rules on the Oracle database
Note 359145.1—Impact of 2007 USA daylight saving changes on the Oracle database
Note 360803.1—AU Timezone Database and Fusion Middleware Recommendations
Note 397281.1—USA 2007 Daylight Saving Time (DST) Compliance for Database and Fusion Middleware
Note 401010.1—Western Australia Daylight Saving Time Changes Database and Fusion Middleware Recommendations
To locate knowledge base articles on My Oracle Support (formerly MetaLink)
Go to My Oracle Support at https://metalink.oracle.com.
Log in as directed.
Click the Knowledge tab.
From the Quick Find list, choose Knowledge Base, enter the number of the note, click the Go button.
From the results list, click the name of the note you want to view.
To synchronize Oracle Access Manager components across geographically diverse time zones, you can use the Network Time Protocol (NTP). NTP can synchronize the time on computers 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
UNIX computers use UTC (also known as GMT) internally and convert to the local time that is needed on the display. Windows computers 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 computers 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 computer for each component, as described in "Confirming Certification Requirements".
The account that performs component installation must have administration privileges. Oracle recommends that you create a username and a group specifically for installing and configuring Oracle Access Manager components. In addition, consider the following:
.NET on Windows: On Windows platforms, you must have the .NET Framework installed before installing Oracle Access Manager components. Otherwise, Oracle Access Manager servers will fail on start up. For more information, see "Preparing Windows for the .NET Runtime".
Administrative Requirements for Command-line Tools: If the product is installed as one specific user, all command line utilities and tools must run as the user who installed the product. Oracle recommends that you do not attempt to change ownership or permissions on files after installation.
Administrative Rights: 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 Linux Platforms: You can create a user and a group account after component installation.
Do not to use username "nobody" and group "nobody."
Do not use "root" for anything related to the installation and administration of Oracle Access Manager components.
On UNIX Platforms—During component installation, you are asked to specify the username and group that the Oracle Access Manager component will use. Oracle recommends against using username "nobody" and group "nobody." For HP-UX, the defaults are "WWW" (username) and "others" (group).
Confirm that the right commands are installed and verify the username 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 anything. To determine the Web server user and group, check your Web server configuration files or by run the Web server's administration console and view server settings.
|
Note: WebPass, Policy Manager, and WebGate should be installed using the same user and group as the Web server. The account that is used to install the WebGate is not the account that runs the WebGate. |
Computers Must be Online: Before installation, you must be able to ping the computer on which each component will run. Also, during installation you will be asked to supply the DNS host name of the computer on which the Identity Server and Access Server are installed.
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".
GCC Runtime Libraries for Linux and Solaris: Before installing components on Linux computers, 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 and Solaris Host Computers".
LinuxThreads versus NPTL: Red Hat Linux v4 (and earlier releases) used an implementation of the Posix 1003.1c thread package for Linux (called LinuxThreads) that runs with kernel 2.0.0 or later. Earlier releases of Oracle Access Manager for Linux used the LinuxThreads library only. This required that you set the environment variable LD_ASSUME_KERNEL, which is used by the dynamic linker to decide what implementation of libraries is used. When you set LD_ASSUME_KERNEL to 2.4.19 the libraries in /lib/i686 are used dynamically.
Red Hat Linux v5 and later releases support only Native POSIX Thread Library (NPTL), not LinuxThreads. To accommodate this change, Oracle Access Manager 10g (10.1.4.3) has been enhanced to comply with NPTL specifications. However, LinuxThreads is used by default.
Oracle Access Manager 10g (10.1.4.3) enables you to use NPTL in other supported Linux environments that comply with NPTL specifications. With NPTL there is no requirement to set the environment variable LD_ASSUME_KERNEL to 2.4.19. However, some WebGate packages still require the LD_ASSUME_KERNEL set to 2.4.19. For more information, see "Confirming Certification Requirements".
|
Note: LinuxThreads is used by default with Oracle Access Manager 10g (10.1.4.3), as before. However, with NPTL there is no requirement to set the manually environment variable LD_ASSUME_KERNEL to 2.4.19. Also there are script changes that you need to be aware of and some that you need to make. For more information, see "NPTL Requirements and Post-Installation Tasks". |
Security-Enhanced Linux (SELinux): Is delivered with Oracle Enterprise Linux. SELinux modifications provide a variety of security policies through the use of Linux Security Modules (LSM) within the Linux kernel. SELinux requires performing additional steps after installing Oracle Access Manager Web components and before starting the associated Web server. This applies to all supported Linux versions that have SELinux.
Cancel Installation: If you need to cancel an installation or remove an installed component, see "Uninstalling Oracle Access Manager Components".
Multi-Language Environments: Use the latest 10g (10.1.4.3) Language Pack installers and take the following guidelines into account.
If you are installing on a computer with an operating system that is non-English (AMERICAN) language or locale, you may set the LANG 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_3_0_FR_sparc-s2_LP_Identity_System" chmod +x "Oracle_Access_Manager10_1_4_3_0_FR_sparc-s2_LP_Access_System"
|
Note: Messages added for minor releases (10g (10.1.4.2.0) and 10g (10.1.4.3) as a result of new functionality might not be translated and can appear in only English. |
For more information, see Chapter 3, "About Multi-Language Environments".
During installation of Oracle Access Manager components on a Linux or Solaris computer, you are asked to specify the location of additional GCC runtime libraries.
Linux: Oracle Access Manager requires libgcc_s.so.1 and libstdc++.so.5, which should be compatible with GCC 3.3.2.
Solaris: Oracle Access Manager installers search for a hard coded filename of libstdc++.so.5. Even if the Solaris library (libstdc++.s0.6) is copied to libstdc++.so.5, the installer will halt later during installation. Oracle provides libgcc-3.3-sol10-sparc-local, which will be consumed by Oracle Access Manager without issue.
Oracle does not ship GCC runtime libraries for Linux and Solaris; however, these are available on Oracle Technology Network.
|
Note: Identity Server and WebPass installers for Red Hat Linux AS 3.0 can hang after launching the installer, and supplying the installation path, and then pressing |
To install GCC runtime libraries on Linux or Solaris hosts
Obtain GCC runtime libraries from your platform vendor or Oracle Technology Network. For example:
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
Locate the row named GCC Libraries for Oracle Access Manager.
From the appropriate column for the host computer, click the CD for either Linux or Solaris. For example:
Solaris 10: CD1
Linux: CD1
From the zip file, extract and store the following files on the local computer on which you will install one or more Oracle Access Manager components. For example:
Solaris 10: libgcc-3.3-sol10-sparc-local
Linux:
During Oracle Access Manager installation, specify the location of the libraries on the local computer when asked and continue the installation.
On Windows platforms, you must have the .NET runtime installed before installing Oracle Access Manager components. Otherwise, Oracle Access Manager servers will fail on start up.
|
Note: .NET 1.1 support is required for the standard Access Manager SDK. In addition, if you choose to install the optional SDK with .NET 2 support for custom AccessGates, you need .NET 2 on the host computer. |
To verify .NET runtime availability
In the Internet Explorer address field, enter the following and review .NET details in the pop-up that appears:
javascript:alert(navigator.userAgent)
Open Windows Registry, browse to the following and view the list of all available .NET versions on the host.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\
|
See Also: Oracle Access Manager Developer Guide for details about the partial SDK for .NET 2 custom AccessGates |
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 computers. 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".
Oracle recommends that you create a user and a group specifically for installing and configuring Oracle Access Manager components. The WebPass instance should be installed using the same user and group as the Web server for which it is configured.
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".
Oracle recommends that you create a user and a group specifically for installing and configuring Oracle Access Manager components. WebPass, Policy Manager, and WebGate should be installed using the same user and group as the Web server. The account that is used to install the WebGate is not the account that runs the WebGate.
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 supports 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 computers. 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 computer on which you will install the Access Server with a firewall.
Upgraded Environments: If you install a 10.1.4 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 after installation. A freshly installed 10.1.4 Access Server does not automatically provide backward compatibility with older WebGates. However, upgraded Access Servers do automatically provide backward compatibility with older WebGates. 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".
This topic provides some specific guidelines for WebGate installation.
Identity or Access System Protection: The WebGate must be installed on a computer hosting a Web server. To protect the Identity or Access System, you must install WebGate on each computer that is hosting WebPass and Policy Manager, using the same Web server instance as WebPass or Policy Manager.
Installation Path: You can install the WebGate in nearly any directory that your Web server can access. In general, Oracle recommends that you install a WebGate in a different directory than WebPass or Policy Manager. Consider the following additional installation path guidelines:
Microsoft IIS Web Server, Form-based authentication and single sign-on (SSO): WebGate must be installed in the same directory as the Policy Manager and at the same-directory level as WebPass.
Microsoft IIS Web Server, Basic-over-LDAP authentication: WebGate can be installed a different path outside the Policy Manager directory, and can be installed at any directory level.
All Other Web Servers, regardless of the authentication method: WebGate can be installed a different path outside the Policy Manager directory. and can be installed at any directory level.
|
Note: Only with Microsoft IIS Web server, and form-based authentication and SSO, should WebGate be installed in the same directory as Policy Manager. |
Root Level or Site Level: The WebGate can 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.
Computer Level or Virtual Web Server Level: The WebGate can be configured to run at either the computer level or the virtual Web server level. However, do not install at both the computer level and the virtual Web server levels. See also "Synchronizing System Clocks".
Guidelines for Earlier WebGates: Earlier WebGates can coexist with 10.1.4 Access Servers. In this case, you need to consider the following encryption scheme guidelines:
Use RC4 as the encryption scheme if you have Release 5.x and 10.1.4 WebGates co-existing in the same system.
Use RC6 as the encryption scheme if you have Release 6.x and 10.1.4 WebGates co-existing in the same system.
Use the AES encryption scheme if you have only Release 7.0 or 10.1.4 WebGates co-existing in the same system.
With earlier WebGates in a deployment, you must set the Access Server for backward compatibility with older WebGates. For more information, see the Oracle Access Manager Upgrade Guide.
Environmental Guidelines: 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. For more information, see Chapter 16 and Chapter 17.
IBM HTTP Server (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 lock down 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 lock down.
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 computer 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 computer 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.
|
Note: The 10g (10.1.4.3) ISAPI WebGate will not be available with the initial release. It will be available at a later date. |
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.
Oracle HTTP Server Web Server: Oracle Access Manager Web components for Oracle HTTP Server are based on open source Apache.
You need to ensure that your host computer provides enough free disk space for the component that you are installing. The component installation program will inform you about the amount of free disk space that is needed before the files are laid down.
Table 2-1 provides some general estimates regarding the free disk space needed for each component are provided for your convenience. These are provided as an example only. The actual space that is required will differ depending upon your platform and the languages that you are installing, and other factors.
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.
When changing the default names provided automatically, Oracle recommends that you use consistent naming conventions regardless of your platform. For example, you can use an underscore rather than a space in names on Windows platforms to provide consistent naming on both Windows and UNIX-based platforms. Typically, the default installation directory for Oracle Access Manager is as follows:
Windows Platforms: \Program Files\NetPoint\
UNIX Platforms: /opt/netpoint/ (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 and Policy Manager. WebGate path names vary depending on your platform and Web server type.
WebGate path names vary depending on your platform and Web server type. For example, you must install WebGate in the same directory as the Policy Manager \webcomponent\access (may contain a WebGate stored at the same directory level as the Policy Manager)
Table 2-2 Default Directory Path Names
| Component | Installation Directory |
|---|---|
|
Identity Server |
Windows: \Program Files\NetPoint\identity UNIX: /opt/netpoint/identity In This Guide: \IdentityServer_install_dir\identity |
|
WebPass |
Windows: \Program Files\NetPoint\WebComponent\identity UNIX: /opt/netpoint/webcomponent/identity In This Guide: \WebPass_install_dir\identity |
|
Access Server |
Windows: \Program Files\NetPoint\access UNIX: /opt/netpoint/access In This Guide: \AccessServer_install_dir\access |
|
Policy Manager |
Windows: \Program Files\NetPoint\WebComponent\access UNIX: /opt/netpoint/webcomponent/access In This Guide: \PolicyManager_install_dir\access |
|
WebGate |
The default WebGate installation directory path name varies depending upon your platform and Web server type. For example: Win32 ISAPI WebGate: \Program Files\NetPoint\Webgate Win32 OHS2 WebGate: \Program Files\NetPoint\WebComponent Win32 NSAPI WebGate: \Program Files\NetPoint\WebGate Linux Apache2 WebGate: /opt/netpoint/webgate Linux OHS2 WebGates: /opt/netpoint/webgate Note: To protect a Policy Manager and WebPass, the WebGate must be installed as described in "WebGate Guidelines". In This Guide: \WebGate_install_dir\access refers to the WebGate installation directory. |
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_3_0_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"
For cache flush operations following installation and setup, Oracle Access Manager enables you to use "Mixed-Mode Communication for Cache Flush Operations"
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.
When installing and configuring Oracle Access Manager, specific transport security guidelines must be observed, as described in previous topics. After installation and setup, you can choose to use mixed-mode communication for cache flush operations.
Oracle Access Manager 10g (10.1.4.2.0) provided a method that enabled you to use Open mode communication for cache flush requests between the Identity and Access Server while retaining Simple or Cert mode for all other requests. This type of configuration is known as mixed security mode (or mixed transport security mode) communication. Oracle Access Manager 10g (10.1.4.3) provides a streamlined method to implement mixed-mode communication for cache flush requests.
For more information, see the chapter on caching and cloning in theOracle Access Manager Deployment 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 computer, the installation destination for WebPass cannot be the same as for Identity Server.
When you install Policy Manager and WebPass on the same computer, you must place them at the same level. For example, if C:\OracleAccessManager\WebComponent is the WebPass installation path, the Policy Manager installation path on the same computer should be the same:
\identity is automatically appended to the WebPass installation path
\access is automatically appended to the Policy Manager installation path
Be sure that your Web server meets all requirements before you being installation. For details, see:
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), using steps in "Confirming Certification Requirements".
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 component installation destination, and record details on "Installation Preparation Checklists".
For more information, see:
Separate Web server-specific packages are provided for Oracle Access Manager Web components: WebPass, Policy Manager, and WebGate. Be sure to choose the appropriate package for your Web server and platform.
The initial 10g (10.1.4.3) release will not include Web components for all supported Web servers. For more information, see "Confirming Certification Requirements" and "Obtaining the Latest Installers, Patch Set, Bundle Patch, and Certified Agents".
The following naming conventions are used for Oracle Access Manager Web component packages:
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). For more information about IIS Web servers and Oracle Access Manager, see Chapter 19.
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.
|
Note : NSAPI Policy Manager for Solaris: SSL-enabled communication is supported for Policy Manager to directory server. |
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 Certification 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 provides a single package for components that support Apache with or without SSL enabled. For example:
The APACHE_WebGate supports v1.3.x with or without SSL, as described in Chapter 16.
The APACHE2_WebGate supports v2 with or without SSL (and with or without reverse proxy enabled on Solaris and Linux). See also Chapter 17
The APACHE22_WebGate supports v2.2 with or without SSL (and with or without reverse proxy enabled on Solaris and Linux). See also Chapter 17.
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:
IHS2_WebGate is powered by Apache v2 on IBM-AIX: See Chapter 17.
|
Note: Web components for IHS based on Apache v1.3 are not supported. |
OHS is an Internet Web server extension that identifies Oracle Access Manager Web components that communicate with the Oracle HTTP Server (OHS) based on open source Apache.
Oracle Access Manager package names are OHS11g (based on Apache v2.2), OHS2 (based on Apache v2), and OHS (based on Apache v1.3):
OHS11g WebGate can be used as any other WebGate and is required to support enterprise-level SSO with Oracle Fusion Middleware 11g, as described in the Oracle Fusion Middleware Security Guide 11g Release 1 (11.1.1).
OHS or OHS2 WebGate must be installed with the Oracle Application Server to enable 10g single sign-on, as described in the Oracle Access Manager Integration Guide.
OHS or OHS2 WebPass and Policy Manager can be used with the Oracle Application Server. However, WebPass and Policy Manager for Apache Web servers are also supported for this application.
See Chapter 16 and Chapter 17 for details. For version support, see the Oracle Technology Network as described in "Confirming Certification Requirements".
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. For version support, see the Oracle Technology Network as described in "Confirming Certification Requirements":
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:\OracleAccessManager\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 computer. \identity is appended to the WebPass installation directory and \access is appended to the Policy Manager installation directory.
A Web server that passes credentials (username and password) to an Oracle Access Manager Web component should have SSL enabled. Other Web servers need not be SSL-enabled. The username and password are sent in HTTP POST data from the browser to the Web server. If the Web server does not have SSL-enabled, the username and password appear in clear text in the HTTP header. With an SSL-enabled Web server, data in the HTTP POST is more secure.
During WebPass, Policy Manager, and WebGate installation, your Web server must be configured to work with each Oracle Access Manager Web component. 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.
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 Oracle HTTP Server 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.
For additional WebGate Web server guidelines, see "WebGate Guidelines".
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.
For more information about installing Oracle Access Manager with Active Directory (or ADAM), see Appendix A (or Appendix B).
Task overview: Preparing your directory server
Ensure the directory server is on the list of supported platforms, as described "Confirming Certification Requirements".
|
Note: The Siemens DirX directory is not supported. However, the installation screen might 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 "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 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.
Sun One Directory Server v5.1 or v5.2: Oracle Access Manager servers might not be able to fulfill requests when is SSL-enabled. To avoid this issue, see "Sun One Directory Server v5 SSL Issues".
Task overview: Defining directory server communication security
Before Oracle Access Manager installation, review all directory server requirements, 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.
inetOrgPerson and groupOfUniqueNames for user and group object classes are required when Oracle Access Manager is configured for Oracle Virtual Directory.
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.
Sun Java System Directory Server 6.0 and Installation of Identity Server: Certification of the Sun Java Directory Server 6.0 with Oracle Access Manager occurred after 10g (10.1.4.0.1) was released. As a result, during Identity Server installation there is no option to select Sun Java Directory Server 6.0. If Sun Directory Server 5.x is selected, the configuration fails when performing an automatic schema update. For more information, see "Sun Java System Directory Server 6.0 and Installation of Identity Server".
Sun One Directory Server v5 requires patches to overcome issues. The structure of the node that Oracle Access Manager uses has changed with Sun One Directory Server v6.3. For more information, see troubleshooting tips in:
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: By default, the Oracle schema for Novell eDirectory does not support creating the oblix node (o=oblix,<config-dn>) under a domain node (for example, dc=us,dc=oracle,dc=com) during browser-based Identity System setup. This means that you cannot use a domain node as the configuration base during the browser-based Identity System setup. A workaround is provided in "Novell eDirectory Issues".
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 in which two group objects appear 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
|
Note: inetOrgPerson and groupOfUniqueNames are required for user and group object classes, respectively when Oracle Access Manager is configured for Oracle Virtual Directory. |
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 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.
To download release notes, white papers, or other collateral, the latest support and certification information, and details about each CD in the Oracle Access Manager release, please visit the Oracle Technology Network (OTN).
You must register online before downloading software. Registration is free and can be accomplished at the following site:
https://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:
https://www.oracle.com/technology/documentation/
For the latest Oracle Access Manager certification information, see Oracle Technology Network at:
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/pdf/oracle_access_manager_certification_10.1.4_r3_matrix.xls
This section provides the following topics:
You can acquire Oracle Media Packs on physical CDs or DVDs or download virtual CDs and Media Packs as follows:
Oracle Media Pack
Physical Media Packs are available to any customer working with a Sales Representative when you request the "EPD Plus Media Pack" order type. In this case, a physical Media Pack will ship when the contract is booked and signed. In addition, you can order a physical Media Pack from the Oracle store. Shop online at:
http://oracle.com
Oracle Technology Network (OTN): Each Oracle Access Manager Readme link provides information about the contents of every download link on the site, as well as how to find relevant documentation, and more. Look for these links:
Oracle Access Manager Core Components Readme
Review this Readme to the find the location of Identity Server, WebPass, Policy Manager, Access Server, SNMP Agent, Software Developer Kit components.
Oracle Access Manager WebGate Readme
Review this Readme to locate WebGates including those for Oracle HTTP Server 11g, and Oracle Access Manager Web components and connectors for third party products are identified.
Oracle Access Manager NLS Readme
Review this to locate various Language Pack installers.
Oracle edelivery: Provides access to virtual Media Packs for Oracle Fusion Middleware products, including Oracle Access Manager.
The installers you need will depend on the task you are performing. For instance, to perform an:
10g (10.1.4.3) installation: Acquire 10g (10.1.4.3) installers as described in either of the following procedures:
Upgrade from an Existing 6.x or 7.x Deployment: Acquire the 10g (10.1.4.0.1) installers from Oracle edelivery or OTN, as described in the :
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
Perform a Zero Downtime Upgrade: Aacquire the 10g (10.1.4.0.1) installers from Oracle edelivery or OTN and the 10g (10.1.4.2.0) patch set as described in "Obtaining the Latest Patch Set".
To obtain the latest installers from OTN
Go to Oracle Technology Network (OTN) and log in as usual:
10g (10.1.4.3) Installers
http://www.oracle.com/technology/software/products/ias/htdocs/idm_11g.html
From the Oracle Access Manager section of the table on OTN, click Readme.
|
Note: Oracle Access Manager WebGates are listed separately from core components. Look for other packages for 3rd party applications are listed under Oracle Access Manager - 3rd Party Integration in the table. Click Readme for details. |
Print and review details in the Readme to:
Locate the appropriate CD links in the table.
Locate the documentation library for download.
Download Packages: Locate and click the CD link for the package you want to download.
Get Documentation: Use instructions in the Readme to obtain the relevant documentation and Release Notes, including additional documents that might be available with certain components.
Install Component: Use instructions in the Oracle Access Manager Installation Guide to install and set up the component.
Apply the latest patch set or bundle patch, as needed:
To obtain the latest installers from Oracle edelivery
Go to edelivery site and log in as usual:
http://edelivery.oracle.com/EPD/Search/get_form
Enter the following information when prompted:
Full Name (First Last)
Company Name
E-mail address
Country
Click the following options to continue:
YES, I accept the Trial License Terms and Export Restrictions and I acknowledge that I have reviewed and understood the agreement and agree to use the language I selected in entering into this agreement.
OR, I have already obtained a license from Oracle which governs my use of the software
YES, I accept these Export Restrictions
Continue
On the Media Pack Search page, select from the lists to specify a product and platform, and then click Go. For example:
Select a Product Pack Oracle Fusion Middleware
Platform desired_platform
Go
In the Results table, locate and click the appropriate listing for your needs:
Oracle Access Manager 10g (10.1.4.3) for a fresh installation
Oracle® Fusion Middleware 11g R1 Media Pack for platform
Oracle Access Manager 10g (10.1.4.0.1) to upgrade an earlier release:
Oracle® Application Server 10g Release 3 (10.1.3) Media Pack for platform
Download Packages: Locate and click the Download button beside each Media Pack you need for the desired release, and specify a destination for the zip file. For example:
10g (10.1.4.0.1):
Oracle Access Manager (10.1.4.0.1) for platform (DVD n of n) (Part n of n)
10g (10.1.4.3):
Oracle Access Manager 10g (10.1.4.3) for platform (DVD n of n) (Part n of n)
Repeat these steps to download all needed packages for the desired release.
Get Documentation: Unzip the files you downloaded to locate the documentation.
Install Component: Use instructions in the Oracle Access Manager Installation Guide to install and set up the component.
Upgrade Earlier Components: Use instructions in the Oracle Access Manager Upgrade Guide to install and set up the component.
Apply the latest patch set or bundle patch, as needed:
The latest patch set is available from My Oracle Support (formerly MetaLink). Your starting Oracle Access Manager deployment determines the patch sets you need. For example, if your starting release is:
Release 10g (10.1.4.0.1): Perform both steps in the following procedure.
Release 10g (10.1.4.2.0): Skip Step 1 and apply only the 10g (10.1.4.3) patch.
To obtain the latest patch set
10g (10.1.4.2.0) Patch Download:
Go to My Oracle Support (formerly MetaLink) and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter 5957301, and then click Go.
On the Patch 5957301 page, click the Download button beside each zip file name.
Readme: Click the View Readme button to display the Release Notes, which you can print to review the list of bugs fixed, enhancements, and more.
Patch Installation: See the Readme for all prerequisites, patch install, and post-patching instructions: oam_101420_readme.pdf
10g (10.1.4.3) Patch Download:
Go to My Oracle Support (formerly MetaLink) and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter 8276055, and then click Go.
On the Patch 8276055 page, click the Download button beside each zip file name.
Readme: Click the View Readme button to display the Release Notes, which you can print to review the list of bugs fixed, enhancements, and more.
Patch Installation: See the 10g (10.1.4.3) Readme for all prerequisites, patch install, and post-patching instructions: oam_101430_readme.pdf.
Oracle releases bundle patches to correct any reported issues in your deployment. Oracle recommends that you obtain and apply the latest bundle patch.
Bundle patch documentation includes instructions to apply or remove the patch as well as a list of bugs fixed with the release. Bundle patch product packages and related documentation are available only through the My Oracle Support (formerly MetaLink) Web site:
https://metalink.oracle.com
|
See Also: OAM Bundle Patch Release History: Knowledge Base article #736372.1 on My Oracle Support. This document describes bundle patches and their numbering in more detail. |
To retrieve the latest bundle patch
Ensure that your system configuration meets all requirements, including .NET for Windows platforms.
On the machine that will host the bundle patch files, create a temporary directory to contain the platform-specific bundles that you will download. For example:
Go to My Oracle Support (formerly MetaLink) and login as usual:
https://metalink.oracle.com
On My Oracle Support (formerly MetaLink):
Click the Patches & Updates tab.
Click Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs.
In the Patch Sets for Product Bundles table on the Quick Links page, click Oracle Oblix COREid.
On the Advanced Search page that appears, click the Simple Search button.
On the Simple Search page, confirm that the following details are specified:
Search by: Product or Family Oracle Oblix COREid Family
Release: Oracle Access Manager 10g (10.1.4.3.0)
Patch Type: Patch
Platform or Language: Your_Platform
Click the Go button to display the Results Table.
In the Results table, Patch Column: Locate the latest bundle patch (top of the list) and click the corresponding number.
Patch Page: Click the Download button (or the View Readme button for general information; or the View Digest button to see the bundle name).
In the temporary directory where you stored the downloaded zip file, unzip to extract component-specific files.
|
Note: Any component-specific tar files are automatically unbundled when installed. |
Repeat these steps to retrieve the bundle patch for each platform that includes 10g (10.1.4.3) core components.
Follow installation instructions in the bundle patch documentation that accompanies the packages.
Oracle is continuously providing Oracle Access Manager packages for components on newly certified platforms. Documentation is included with some connectors to identify any prerequisites or post-installation configuration tasks.
Use the following procedure to obtain newly certified agent packages from the Oracle Technology Network (OTN).
To obtain newly certified agent packages
Go to Oracle Technology Network and log in as usual:
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
From the Oracle Access Manager - 3rd Party Integration section of the table, click Readme.
Print and review details in the Readme to:
Locate the appropriate third-party virtual CD links in the table on OTN.
Locate the documentation library for download.
Download Packages: Locate and click the CD link for the package you want to download.
Get Documentation: Use instructions in the Readme to obtain the relevant documentation and Release Notes.
Install Component: Use instructions in the Oracle Access Manager Installation Guide and the Readme to install and set up the component.
Oracle Access Manager installation media provides all product packages that you need to install Oracle Access Manager components, including Language Packs. Oracle recommends that you copy these packages into a temporary 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 can 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 22, "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 computer 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 computer 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 computer 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 computer 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 computer 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 computer 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 computer: |
|||
|
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 Basic Over LDAP - Oracle Access and Identity Basic Over LDAP for 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 computer: 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 path (can be same as WebPass installation path): |
|||
|
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 |
|
 Copyright © 2000, 2014, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|