|Oracle® Access Manager Installation Guide
The Access Server is a stand-alone component that provides dynamic policy evaluation services for both Web-based and non-Web resources and applications. The Access Server receives requests from an access client, either a WebGate or a custom AccessGate; queries your LDAP directory for authentication, authorization, and auditing rules; and validates credentials, authorizes users, and manages user sessions for Oracle Access Manager. For more information, see Oracle Access Manager Introduction.
Before you install the Access Server you need to create an instance for it within the Access System Console.
Create an Access Server instance in the Access System Console, as described in "Creating an Access Server Instance in the System Console".
Install the Access Server, as described in "Installing the Access Server".
Install additional Access Servers, if needed, as described in "About Installing Multiple Access Servers".
Add new Access Servers to an upgraded environment and be sure to manually set the appropriate parameter in the globalparams.xml file to ensure backward compatibility with older plugs-ins, as described in "Installing 10.1.4 Access Servers in an Upgraded Environment".
Installing the Access Server is similar to installing the Identity Server. You will specify directory server details during this installation and a default directory profile is created for this Access Server. The default profile is available after you create an Access Server instance; the completed profile is available after installation. There is no Web server involved in Access Server installation.
The following two installation packages are provided for the Access Server:
Again, platform-specific packages are available and installation is similar regardless of the platform or installation mode you choose. Information is saved at certain points. If you cancel the installation after being informed that the Access Server is being installed, you must uninstall the component as described in "Upgrading an Earlier Release". Any caveats are identified and may be skipped when they do not apply to your environment.
For more information, see "Access Server Guidelines".
Oracle recommends you install multiple Access Servers for failover and load balancing. The procedures to do this are similar to those for installing a single Access Server.
Create instances for each Access Server in the Access System Console, as described in "Creating an Access Server Instance in the System Console"
Do not install multiple Access Servers in the same directory.
Install the Access Server, as described in "Installing the Access Server", and specify a different installation directory for each Access Server.
You can replicate an existing installation using an options file, as described in "Replicating Components".
Install one or more AccessGates/WebGates and assign the Access Servers to them as either primary or secondary Access Servers, as described in "Installing the WebGate".
Refer to the Oracle Access Manager Access Administration Guide for complete instructions on how to enable these features.
The 10.1.4 Access Server uses UTF-8 encoding, and plug-in data will contain UTF-8 data. Earlier plug-ins send and receive data in Latin-1 encoding.
In releases before 10.1.4, cookie encryption and decryption was handled by WebGate/AccessGate. However, cookie encryption and decryption is now handled by the Access Server.
A freshly installed 10.1.4 Access Server does not automatically provide backward compatibility with older WebGates. If you install a 10.1.4 Access Server in an upgraded environment that includes older WebGates, you need to enable the Access Server to continue to send (and receive) data to earlier custom authentication and authorization plug-ins in Latin-1 encoding (and earlier custom plug-ins will set data in Latin-1 encoding). In addition, the Access Server must maintain backward compatibility with earlier WebGates and custom AccessGates that continue to encrypt/decrypt cookies. You accomplish backward compatibility by manually changing the parameter
"IsBackwardCompatible" Value="true" in the Access Server's globalparams.xml file after installation as described in the following procedure.
Before you add a 10g (10.1.4.3) Access Server to an upgraded environment, ensure that all Oracle Access Manager components are at release 10g (10.1.4.3). Earlier WebGates can co-exist when the Access Server is enabled for backward compatibility.
When all plug-ins and WebGates have been successfully upgraded, and backward compatibility is no longer needed, Oracle recommends that you manually set
"IsBackwardCompatible" Value="false" in all Access Server globalparams.xml files. For more information, see the Oracle Access Manager Upgrade Guide.
Upgrade the environment as described in the Oracle Access Manager Upgrade Guide.
Review details in "About Installing Multiple Access Servers".
Perform activities in "Creating an Access Server Instance in the System Console".
Add the new Access Server, as described in "Installing the Access Server".
"IsBackwardCompatible" Value="true". For example:
<SimpleList <NameValPair ParamName="IsBackwardCompatible" Value="true"> </NameValPair> </SimpleList>
Save the file.
Restart the Access Server service.
Before you begin installing the Access Server, confirm that you have completed the tasks inTable 8-1. Failure to complete all prerequisites may adversely affect your Oracle Access Manager installation.
|Checklist||Access Server Prerequisites|
Review and complete all prerequisites and requirements that apply to your environment, as described in Part I, "Installation Planning and Prerequisites".
Complete all activities in Part II, "Identity System Installation and Setup".
Install, set up, and confirm that you have a working Policy Manager, as described in Chapter 7, "Installing the Policy Manager".
Before you can install the Access Server you must create an instance for it within the Policy Manager, Access System Console. This can be accomplished by either the Master Administrator or the Master Access Administrator if one has been defined.
The Access Server ID you specify when you create the instance must be unique and cannot contain spaces, a colon ":", the pound sign "#", or non-English keyboard characters. On Windows systems, this Access Server ID will be used as the Windows Service name, with "NetPoint AAA Server" as a prefix.
Log in to the Access System Console. For example:
where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
The Access System main page appears.
Click the Access System Console link, then log in as a Master Administrator.
The Access System Console main page provides three tabs across the top and information about the functions in the center.
Click the Access System Configuration tab, then click Access Server Configuration when the side navigation bar appears.
If this is the first Access Server, the main page will inform you that no Access Servers were found in the directory server. Otherwise, Access Servers that have been added will be listed.
Click the Add button to display the Add a new Access Server page with some defaults.
You need only supply basic information to create the instance. After installation, you can complete additional configuration as discussed in the Oracle Access Manager Access Administration Guide. Online help is also provided.
Specify the following parameters for the Access Server you plan to install. For example:
Name: Descriptive name for the Access Server that is different from any others already in use on this directory server. Do not include spaces, a colon (":"), or the pound sign ("#") in the name.
Hostname: Name of the computer where the Access Server will be installed. The Access Server does not require a Web server instance.
Port: Port on which the Access Server will listen.
Transport Security: Transport security between all Access Servers and associated WebGates must match: either all open, all Simple mode, or all Cert.
The List All Access Servers page appears with a link to this instance.
Click the link to the Access Server instance, print the Details page for later reference, then click the Back button at the bottom of the page.
Click Logout, close the browser window, and continue with "Installing the Access Server"
Refer to your completed installation preparation worksheets as you install the Access Server. The following procedures must be completed for each Access Server:
Choosing the installation method and starting the process as described in "Starting the Installation"
Defining the transport security mode as discussed in "Specifying a Transport Security Mode"
Identifying directory server details as explained in "Specifying Directory Server and Communication Details"
Completing the process as discussed in "Finishing the Access Server Installation"
The Access Server installation sequence is similar to those you have performed for other Oracle Access Manager components.
Do not install the Access Server in the same directory as the Policy Manager. Do not install multiple Access Servers in the same directory.
Log in as a user with Administrator privileges.
Locate the Access Server installer (including any Access System Language Packs you want to install).
Launch the Access Server installer for your preferred platform and installation method.
Dismiss the Welcome screen by clicking Next
Respond to the question about administrator privileges based upon your platform. For example:
Identify the installation directory, then click Next.
Language Pack: Choose a Default Locale and any other Locales to install, then click Next.
Record the installation directory name, then click Next.
The Access Server is installed, which may take a few seconds. On Windows systems, a screen appears informing you that the Microsoft Managed Interfaces are being configured.
You are asked to specify the transport security mode.
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.
Choose a transport security mode: Open, Simple, or Cert.
Regardless of your transport security choice, you are asked to specify directory server details next.
During this sequence, you are asked to provide details about your environment and the Oracle Access Manager configuration and policy data directory servers. Oracle Access Manager adds additional configuration entries to the directory server.
Provide the information requested for the configuration data directory server, then click Next.
Open or SSL
Host computer: The DNS host name of the directory server with configuration data
Port number: Port on which the directory server with configuration data listens (for SSL connections, provide the encrypted port)
Root DN: Bind DN for the directory server with configuration data
Root Password: Bind DN password for the directory server with configuration data
Configuration Directory: Type of directory server with Oracle Access Manager configuration data. For example:
SSL Only: Enter the path to the SSL certificate.
You need to identity where Oracle Access Manager policy data is stored: either with Oracle Access Manager configuration data or in a separate directory server. For more information, see "Data Storage Requirements".
Identify where the Oracle Access Manager policy data is stored. For example:
If your policy data is stored separately, you need to provide information for the policy data directory server. The configuration DN and policy base must be unique. See "Data Storage Requirements".
You are now asked for the Access Server instance ID that you specified in the Access System Console and the configuration DN and policy base.
Enter the requested details, then click Next. For example:
Perform the following operations according to the transport security mode you chose earlier:
Specify and confirm the Pass Phrase, click Yes (or No) when asked to store the password in a file, click Next.
When you select No on Windows, you are prompted for the PEM phrase every time you start the Access Server. When you select No on UNIX, you must use the -P option to pass the password whenever you launch the start_access_server script.
Simple: Skip to "Finishing the Access Server Installation".
Certificate: Complete your certificate request and installation sequence, then continue with "Finishing the Access Server Installation".
If you requested certificates and they are not ready during this installation, the Access Server cannot be used until the you copy certificates to the \AccessServer_install_dir\access\oblix\config directory, and restart the Access Server.
You are informed that the Access Server is being configured, then ReadMe information appears.
You perform the following activities to finish the installation so that you can confirm that the Access Server is installed and operating properly. The ReadMe information provides details about documentation and contacting Oracle.
The Access Server service starts automatically by default. On Windows platforms, the Access Server ID that you specified in the Access System Console is used as the Service name (including an Oracle Access Manager prefix).
Review the ReadMe information, then click Next to dismiss it.
You are informed that the installation is complete and that you need to start your Access Server.
Click Finish to complete the sequence.
You need to start your Access Server, which confirms that the Access Server installation was successful and prepares for WebGate installation.
If you installed on Linux and intend to use the Native POSIX Thread Library, see "NPTL Requirements and Post-Installation Tasks".
Start your Access Server service so that you can confirm the Access Server is installed and operating properly:
Windows: Open the Windows Service window and confirm that the Access Server service is started (it starts automatically on Windows systems).
UNIX: Go to your /AccessServer_install_dir/access/oblix/apps/common/bin directory and execute ./start_access_server.
For installations that do not use a password file, you must start the Access Server locally. Attempting this remotely (through a terminal emulator such as NetMeeting or Windows 2000 remote service restart) will fail.
What you do next depends on your environment: