| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
This chapter introduces both the automated processes that are initiated when you start a component upgrade and manual tasks that you must perform. Unless explicitly stated, information in this chapter applies to both in-place upgrades and to zero downtime upgrades. Topics in this chapter include:
Note:
You cannot use 10g (10.1.4.3) packages for upgrading.All Oracle Access Manager releases support the following components:
Identity Server (formerly known as the COREid Server), WebPass, Policy Manager (formerly known as the Access Manager component), Access Server, WebGate, and Software Developer Kit
Note:
The Simple Network Management Protocol (SNMP) has not changed and does not require an upgrade.Oracle Access Manager applications, which are integral to components, include the Identity System Console, User Manager, Group Manager, Organization Manager, the Selector, the Access System Console, Policy Manager (formerly known as the Access Manager), and other applications
Integration components such as the Security Provider for WebLogic SSPI and Connector for WebSphere, as well as single sign-on (SSO), provisioning, portal and application server integrations are supported. Complete implementation details are described in the Oracle Access Manager Integration Guide
For information about system requirements and changes, see "Platform and SDK .NET Support".
This section provides the following topics:
When you upgrade each component, the newest product release is installed over an earlier product release in the same location. This section introduces the program-driven processes that occur during component upgrades. Unless explicitly stated, the information in this section applies equally to both methods (in-place and zero downtime methods).
Out-of-place (Zero Downtime Upgrade): This is initiated using the 10g (10.1.4.2.0) MigrateOAM script from a command-line. In this case, you must manually enter the mode for the operation, and other arguments and parameters that are then passed to the underlying utilities. For more information about automated processing for this method, see "Zero Downtime Upgrade Tools, Processes, and Logs". For details about source and destination creation and other preparation tasks for this method, see "Preparation Tasks for the Zero Downtime Method".
In-place Upgrade: This is initiated using the corresponding Oracle Access Manager 10g (10.1.4.0.1) installer. The arguments that are needed by the underlying utilities are gathered by the installer during processing. The program controls the sequence of events and messages automatically. The process requires very little input from you. After you start an upgrade and specify the file system directory where the component to be upgraded resides, you are asked if you want to upgrade the earlier version of the component. When you accept the upgrade option, the earlier source directory is renamed with the addition of a time stamp (yearmonthday_hourminutesecond). This time-stamped source contains earlier original files that are sometimes accessed to compare content or extract customized information.
Sample Time-Stamped File System Directory:
\IdentityServer_install_dir_20060422_141440\identity
After the source directory is renamed with a time stamp, the target directory is created and new files are extracted to the target. For example:
Sample Target File System Directory: \IdentityServer_install_dir\identity
If the target file system directory does not match the earlier component installation path, a component instance is installed (not upgraded).
All Upgrade Methods: You can choose to have individual upgrade events performed automatically or with your confirmation, as described in "Upgrade Event Modes".
New folders are created in the target file system path as needed. While the directory structure for Oracle Access Manager release 6.5, release 7.0, and 10.1.4 are the same, they differ from earlier releases. For details, see Appendix A.
Figure 3-1 and the process overview that follows it describe a typical in-place component upgrade. The processing that is required for each component is driven by the utilities that are called automatically during the process. There are slight variations, depending upon the method you are using:
In-place Method: As depicted in Figure 3-1, after you start the component installation program, you see a Welcome message and you are asked to provide specific input (such as the file system path to the component's installation directory). As automated processing continues, you are asked to accept an operational method (Automatic versus Confirmed), or simply acknowledge that you are ready to continue.
Zero Downtime Method: After you manually enter the command line containing arguments and specifications for the component instance, these are passed to the utilities that control the upgrade.
Note:
Starting with item 3 in Figure 3-1, internal processing is similar regardless of the method you are using. For more information about the zero downtime upgrade script and modes, see Chapter 15.Figure 3-1 Automated Program-Driven Events During an In-place Upgrade
If you are using the in-place method, processing starts when you launch the 10g (10.1.4.0.1) installer. If you are using the zero downtime method, processing starts with item 3, after you start the 10g (10.1.4.2.0) MigrateOAM script.
During each component upgrade, additions and changes (from each major release to the next major release to release 10.1.4) are implemented As a result, the sequence of events and messages will repeat automatically until all changes between your starting release and 10.1.4 are incorporated.
Note:
Process overviews, such as the one here, identify automated processes. After you initiate the process, you might be asked to accept or acknowledge certain events. Skipping or declining an event is sometimes an option.Process overview: During a component upgrade
In-place Method: After you launch the 10g (10.1.4.0.1) component installer, and an earlier source directory is detected in the same location, you are asked if you want to upgrade. When you accept the upgrade, the source directory is renamed with a time stamp.
In-place Method: The target directory is created and 10g (10.1.4.0.1) files are extracted into it. The English language is upgraded automatically. Other installed languages are upgraded when you include appropriate 10g (10.1.4.0.1) Language Packs for each installed language in the same directory as the 10g (10.1.4.0.1) component installer.
Note:
If you upgrade an existing multi-language implementation without 10g (10.1.4.0.1) Language Packs, you will lose multi-language functionality.Both Methods: A utility (obmigratenp) is called by the component installer to determine the release you are upgrading from as well as the release you are upgrading to. obmigratenp internally detects which features need to be upgraded for this particular component and which other utilities to use for those upgrades. When your installation includes multiple languages, obmigratenp migrates message catalogs.
Both Methods: A utility (obmigratefiles) is called to upgrade earlier program and library files.
Both Methods: A utility (obmigrateparamsg) is called to upgrade earlier message and parameter catalog files.
Schema and Data Upgrades Only: Two utilities (obmigrateds and obmigratedata) are called automatically to initiate Oracle Access Manager schema and data upgrades.
Zero Downtime Method: The schema and data are upgraded independently. For more information, see "Schema and Data Upgrades with the Zero Downtime Upgrade Method".
In-Place Method: The schema and data are upgraded together with the master Identity Server (and master Policy Manager when your installation includes the Access System). During subsequent Identity Server (and Policy Manager) upgrades, the initial schema and data upgrade is detected and this portion of the process is skipped. Oracle recommends that you upgrade the Oracle Access Manager schema and data automatically. These upgrades use LDIF files that are specific to your directory server. Each LDIF file includes only changes from one release of Oracle Access Manager to the next. As a result, the schema and data upgrade will repeat one time for each release from your starting release to 10g (10.1.4.0.1). For more information, see Part II.
Web Server Configuration Updates Only: A utility (obmigratews) is called to perform a selective Web server configuration file and filter upgrade, to accommodate changes for newer releases of Policy Manager, WebPass, and WebGate.
Both Methods: A component-specific utility is selected and run to make changes to related registry entries for Windows, plug-ins, and other files. The component's configuration files are updated. For more information, see "Component-Specific Upgrades".
During each component upgrade, one or more log files will be produced to inform you if any problem should arise. If a log file is created, a message during the upgrade process indicates the name and location of the file. In general, you can find upgrade log files in:
\Component_install_dir\identity|access\oblix\tools\migration_tools\toolname.log
where \Component_install_dir is the directory where the specific component is installed; identity|access represents the system to which the component belongs (Identity System or Access System, respectively); and toolname represents the name of the utility that produced the log.
Each log file contains information about a particular activity that occurs during the component upgrade. For example, a separate log file might be generated for file upgrades, or message and parameter upgrades, or the Oracle Access Manager schema upgrade to name a few. For information about specific log files and their content, see Appendix C.
In addition, the log files here are created to inform you of any ldap specific errors:
During Identity Server data migration, error_output_fromversion_to_toversion_osd.ldif file is created in the IdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedata directory.
During Policy Manager data migration, error_output_fromversion_to_toversion_psc.ldif file is created in the PolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedata directory
For the zero downtime upgrade, a new log file is also provided to log activities performed during the make branch (Mkbranch) operation of the MigrateOAM script. For details, see "Zero Downtime Upgrade Tools, Processes, and Logs".
For details about using log files, and other troubleshooting tips, see Appendix G.
Regardless of which methodology you choose, either in-place or zero downtime, the following items are upgraded during component upgrades:
The Oracle Access Manager schema and configuration and policy data are upgraded only with the master Identity Server and Policy Manager installed for this purpose
Web server configuration files and filters are upgraded only for Web components (WebPass, Policy Manager, WebGate)
Component-specific information, including component configuration files and system environment settings such as registry entries for Win32
Product and component names are changed as described in "Product and Component Name Changes"
Certain configuration files, including those for failover and the software developer kit (SDK) are upgraded as indicated in the following list:
Access Server: failover files
SDK Configuration: This upgrade is invoked automatically as the last step when upgrading the Identity Server (and integration components that rely on the Software Developer Kit libraries). Oracle recommends that you accept the automatic upgrade to preserve current configuration settings. Otherwise, you must reconfigure the SDK later using the configureAccessGate tool, as described in Chapter 11.
Note:
Independently Installed SDKsmust be upgraded manually, as described in Chapter 11.Only supported components can be upgraded.
See Also:
"Support Deprecated"The following information applies regardless of the upgrade methodology that you choose: either in-place or zero downtime.
Any names assigned by an administrator during product installation and configuration are retained during an upgrade (not changed). Therefore if you have named a service "COREid Identity Server" or "NetPoint Identity Server" these names will be the same in the upgraded environment.
Earlier authentication schemes and policy domains assigned by administrators are also retained during the upgrade. After the upgrade, these names are still available.
The items in the following list are preserved in the time-stamped directory and copied into the new target directory:
password.xml and .lst (.lst is converted to .xml for the Access System)
Starting with release 7.0 and continuing with 10g (10.1.4.0.1), the default certificate store format and name has changed to cert8.db from cert7.db. After the upgrade, the old certificate store is used. 10g (10.1.4.0.1) (and release 7.x) work with both the cert7.db (upgraded environments) and cert8.db (new installations) certificate store. See "Certificate Store and Localized Certificates".
For additional information, see the topics:
Note:
The following topics apply regardless of the upgrade methodology that you choose: either in-place or zero downtime. For more information about system behavior and backward compatibility, see Chapter 4.Starting with the Access System release 6.5, directory profiles are created during Policy Manager setup and are used by the Access System to access user directory data. These profiles replace the UserDB.lst and GroupDB.lst files and the UserDBFailover.lst and GroupDBFailover.lst configuration files that were used in earlier releases of the Access System.
During the Access System upgrade from release 6.1.1, new directory profiles are created based on the UserDB.lst and GroupDB.lst files and the UserDBFailover.lst and GroupDBFailover.lst configuration files.
Your earlier implementation might also include failover between an Identity Server and the directory server. The Identity Server failover configuration has resided in the directory server profiles since release 5.2. As a result, during the Identity Server upgrade there is no migration of parameters from failover configuration files to directory profiles. Although the schema itself has changed, migration of these changes is performed automatically during the upgrade.
Starting with release 6.5, the Access System began partially using directory profiles and database instances for accessing user data. Directory profiles replace the UserDB.lst, GroupDB.lst, UserDBFailover.lst, and GroupDBFailover.lst configuration files that were used in earlier Access System releases. During the incremental upgrade to release 6.5, directory profiles for the Access Server are automatically created and replace certain earlier configuration files where:
Primary directory server information was stored in: AccessServer_install_dir/access/oblix/config/UserDB.lst and GroupDB.lst
Information for all the failover and load-balancing directory servers (primary and secondary) was stored in: AccessServer_install_dir/access/oblix/config/UserDBFailover.lst and GroupDBFailover.lst
When creating the Directory Server Profile for the Policy Manager, directory server credentials are read from PolicyManager_install_dir/access/oblix/config/userDB.lst.
Note:
If the configuration tree is in the user directory server and under the user node, then the configuration directory profile is not created. Otherwise, a configuration directory profile is created using directory server information from PolicyManager_install_dir/oblix/config/ldap/configdb.lst and marked for use only by the Policy Manager.Profiles are not created for Policy Manager failover servers. In the case of release 6.1, if the policy tree was on a separate directory server a profile for policy data existed.
After upgrading the Identity System and Access System, it is a good idea to validate your failover and load balancing configurations and to test that these are still operating as expected. For details, see discussions in:
See also "Connection Pool Details" next.
As described in the Oracle Access Manager Deployment Guide, the number of connections opened to the directory is specified by the Initial Connections parameter in the Database Instance Profile. More connections are opened, as needed, until they equal the number specified by Maximum Connections parameter in the database instance profile. Connections remain open until the Identity or Access Server shuts down or the directory server stops responding. Those connections are then pooled and used by the Identity and Access Server.
Note:
Starting with Oracle Access Manager release 7.0, connection pooling was consolidated to support failover across the entire system. The directory connection pool does not depend on directory type.There might be some impact when upgrading the Access System, depending on the earlier configuration of Oracle Access Manager to each directory server used. For details, see "Confirming Access System Failover and Load Balancing".
See also the previous discussion on "Directory Server Failover".
There might be some impact when upgrading, depending on the earlier configuration of Oracle Access Manager to each directory server used. For instance:
Identity System Connection Pools: There is no impact. Initial Connections and Maximum Connections specified in the database instance profile are retained and will operate as they did previously.
Access System Connection Pools Before release 6.5: Values for the Initial Connections and Maximum Connections in the UserDB.lst and UserDBFailover.lst might not be retained. After upgrading Access System components, it is a good idea to verify the values in the database instance profile of the newly created directory server profile.
On NDS: For concurrent authentication requests on NDS directory servers, Oracle recommends that you increase the connection pool size to something higher than the default (1) for the user directory profile using the System Console.
The shared secret encryption algorithm is an Oracle Access Manager-wide setting. It affects all encrypted cookies. For example, the ObSSOCookie cookie is encrypted using a configurable encryption scheme known as a shared secret. During the upgrade, the earlier encryption scheme is retained.
In release 7.0.4 and earlier, WebGates/AccessGates handled encryption and decryption using the shared secret value. Starting in 10g (10.1.4.0.1), however, the Access Server handles encryption/decryption. As a result, the shared secret is no longer needed on WebGate.
Oracle recommends that you upgrade earlier WebGates. However, earlier WebGates can coexist with 10g (10.1.4.0.1) Access Servers when specific conditions are met. For more information on encryption schemes, the shared secret, Access Servers, and WebGates in Chapter 4.
The following topics apply regardless of the upgrade methodology you choose: in-place upgrades or zero downtime upgrades. Items that require you to perform manual upgrade tasks to ensure compatibility and proper operation with release 10g (10.1.4.0.1) include:
In addition to the topics in the preceding list, see details in:
Oracle Access Manager 10.1.4 supports the Unicode standard. To support all the languages available with Oracle Access Manager 10.1.4, the definitions of auditing and reporting tables have changed. Simply upgrading or altering existing database instances and tables is not supported and could result in permanent truncation and loss of existing data.
After upgrading the Identity System (and Access System), you need to create a new database instance to operate with 10.1.4. To upload the new Audit table schema to support the auditing of 10.1.4 UTF-8 data and writing this data to the new SQL Server instance, you must create a new oblix_audit_events table. This schema upgrade includes datatype changes within Audit table columns. Next you need to create tables for the reporting application (oblix_rpt_as_reports, oblix_rpt_as_resources, and oblix_rpt_as_users) in 10.1.4.
To query or generate any report that requires data from both the old and new database, you need to import data from the original instance into the new instance before you start auditing with 10.1.4. This is an optional step that might or might not be needed in your environment.
Note:
Retain the earlier database to preserve the original data. Importing earlier data can result in some data loss through truncation. However, if you do not import old data before you start auditing, you cannot generate any report that requires the data from both the old and new database.The steps you need to perform, even when you have an English only environment, depend on the type of database you are using. For details, see:
You will need to recompile C++ programs created with the Software Developer Kit and Oracle Access Manager APIs following that upgrade, for the reasons stated in "Plug-ins".
Note:
Oracle recommends that you begin migrating your earlier customizations in a test environment well before you begin upgrading components. This will help reduce system downtime when upgrading your production environment and redeploying customizations.For more information about C++ programs and upgrading these for the Identity and Access Systems, see Chapter 4, Chapter 12, and Chapter 13 respectively.
In earlier releases, the challenge phrase and response attributes were allowed on different panels of Profile pages. In 10.1.4, however, both the challenge phrase and response attributes must be on the same panel. In 10.1.4, challenge phrases and responses are displayed one after the other even though these are not configured one after the other in the panel.
For details about combining challenge and response attributes on a single panel, see "Combining Challenge and Response Attributes on a Panel".
Default product stylesheets are periodically updated by Oracle to instantiate improvements. For example, to support multiple languages, the location of java scripts, stylesheets, and images changed starting with Oracle Access Manager release 6.5. The directory structure introduced with release 6.5 continues with 10.1.4.
Upgraded functionality depends, in part, on stylesheet files in the new release \style0 and \shared directories.
Note:
If files in your earlier Oracle Access Manager \style0 directory were customized, you must manually edit the newer version files in \style0 and \shared directories after the upgrade.It is important to understand the new file hierarchy and stylesheet structure before you can successfully migrate custom images and stylesheets to 10.1.4. If you simply copy the old stylesheets, images, JavaScript files, and related items to the new release, Oracle Access Manager can experience problems.
The following files must be processed manually after the upgrade:
Note:
Oracle recommends that you begin migrating your earlier customizations in a test environment well before you begin upgrading components. This will help reduce system downtime when upgrading your production environment and redeploying customizations.For details about upgrading Identity System customizations, see Chapter 12. For details about the Oracle Access Manager directory structure, see Appendix A, "Oracle Access Manager Directory Structure Changes".
A 10g (10.1.4.3) environment supports only 10g (10.1.4.3) Language Packs. Using 10g (10.1.4.0.1) Language Packs is deprecated in release 10g (10.1.4.3).
Oracle recommends that you remove (uninstall) existing 10g (10.1.4.0.1) Language Packs after upgrading to either:
Oracle Access Manager 10g (10.1.4.0.1), with 10g (10.1.4.0.1) Language Packs installed
Oracle Access Manager 10g (10.1.4.2.0), with 10g (10.1.4.0.1) Language Packs installed
Note:
There are no 10g (10.1.4.2.0) Language Packs.For more information, see "Acquiring and Using Multiple Languages".
Plug-in behavior has changed in recent releases. Following are important details that you need to be aware of with regard to custom plug-ins.
All earlier plug-ins send and receive data using Latin-1 encoding. Starting with 10g (10.1.4.0.1), Oracle Access Manager components and plug-ins send and receive data in UTF-8 format. Identity and Access Servers that are upgraded to 10.1.4 provide backward compatibility with earlier plug-ins using Latin-1 encoding automatically. However, to send and receive internationalized data, earlier plug-ins should be redesigned to communicate using UTF-8 encoding. This includes Identity Event plug-ins and custom authentication and authorization plug-ins. For more information about globalization, see Chapter 4.
Starting with Oracle Access Manager release 7.0, components on Solaris and Linux are compiled using the GCC v3.3.2 C++ compiler to address multi-threading issues encountered with earlier compiler releases. As a result, after the upgrade you must recompile custom plug-ins from release 5.x or 6.x using GCC v3.3.2 C++ compiler. This includes Identity Event plug-ins and custom authentication and authorization plug-ins. You must use the GCC v3.3.2 compiler, regardless of the one that is provided by your Operating System.
Note:
Release 7.0 plug-ins as well as earlier plug-ins implemented as executables or those using a scripting language (such as perl) do not require recompiling after the upgrade. However, to send and receive internationalized data, earlier plug-ins should be redesigned to communicate using UTF-8 encoding.Identity Event API Plug-Ins: Some plug-ins are copied during the upgrade; however, Identity Event API plug-ins are not. After the upgrade you must move earlier Identity Event plug-ins. These plug-ins might also need to be re-compiled or re-designed. For more information, see "Migrating Custom Identity Event Plug-Ins".
Authentication and Authorization Plug-Ins: After the Access System upgrade, see "Recompiling and Redesigning Custom Authentication and Authorization Plug-Ins". Also, the Oracle Access Manager Access Administration Guide provides more information about:
Adding customized plug-ins and parameters to an authentication scheme to be used for any of the scheme's steps
Installing a custom authorization plug-in on application servers that you want to protect and creating custom schemes that include custom plug-ins to perform different (or additional) tasks from those of the default scheme
Note:
Oracle recommends that you begin migrating your earlier customizations in a test environment well before you begin upgrading components. This will help reduce system downtime when upgrading your production environment and redeploying customizations. For more information, see "Customization Upgrade Planning".Oracle recommends that you obtain and apply the latest patch sets to obtain the latest fixes to known issues. These are available on My Oracle Support (formerly MetaLink). Patch sets can include enhancements. For instance, Release 10.1.4 Patch Set 1 (10.1.4.2.0) includes new functionality that supports a zero downtime upgrade method.
Following are specific patch details for each upgrade method:
In-place Method: After upgrading to Oracle Access Manager 10g (10.1.4.0.1):
Apply 10g (10.1.4.2.0)
Apply 10g (10.1.4.3): The 10g (10.1.4.3) patch must be applied to a 10g (10.1.4.2.0) base.
Zero Downtime Method: In this case, each component instance is upgraded using the 10g (10.1.4.2.0) MigrateOAM script., as described in Part VI, "Upgrading Using the Zero Downtime Upgrade Method". After this upgrade, the instance is already at release 10g (10.1.4.2.0). In this case, you apply the 10g (10.1.4.3) patch set.
See Also:
"Obtaining Packages for Upgrades"
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|
