Skip Headers
Oracle® Access Manager Upgrade Guide
10g (10.1.4.0.1)

Part Number B25354-01
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

1 Upgrade Overview and Planning

This chapter provides an overview of the upgrade task and planning that you must perform to upgrade you existing Oracle Access Manager (formerly known as Oblix NetPoint or Oracle COREid) deployment to Oracle Access Manager 10g (10.1.4.0.1). Other chapters that provide additional information are referenced. The following topics are included:


Note:

This book primarily uses new product and component names. For details, see "What's New in Oracle Access Manager?". This book covers upgrades for Oracle Access Manager components only. For details about upgrading Oracle Application Server components, see Oracle Application Server Upgrade and Compatibility Guide.

1.1 Typical Deployment Scenarios

Oracle Access Manager deployments fall into two categories: Identity System only or joint deployments of both the Identity and Access Systems. The upgrade tasks that must be performed, and the sequence in which you perform these tasks, depend upon the type of deployment you have. For more information, see:


Note:

During component upgrades, the same kind of Oracle Access Manager information is upgraded for each component.

1.1.1 About Upgrading Identity System Only Deployments

Figure 1-1 illustrates a very simple Identity System-only deployment. Identified in the figure are the types of information that are upgraded for each Identity System component. As you can see, the Identity System schema and data are also upgraded.

Figure 1-1 Identity System Deployment Overview

Identity System-Only Deployment Overview
Description of "Figure 1-1 Identity System Deployment Overview "

The Oracle Access Manager schema and Identity System data reside in the directory server. Identity System schema and data upgrades are performed only once and require write access to information in the directory server.

Identity System Schema and Data Upgrades

Identity System schema and data upgrades include updating the following information types to meet requirements of the latest release:

  • Oracle Access Manager schema

  • Oracle Access Manager configuration data

  • Oracle Access Manager user and group data and runtime information

  • Oracle Access Manager workflow data

Component information resides in the installation directory of the specific Oracle Access Manager component. The type of information that is upgraded depends on the component type: Oracle Access Manager Server or Oracle Access Manager Web component. For example:

Identity Server Component Upgrades

Each Identity Server component upgrade brings the following information up to release 10g (10.1.4.0.1):

  • Program and library files, including message and parameter catalogs, are replaced with the latest versions

  • Configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest Identity Server release

Identity System Web Component Upgrades

WebPass is the Identity System Web component. Each WebPass component upgrade brings the following information up to release 10g (10.1.4.0.1):

  • Program and library files, including message and parameter catalogs, are replaced with the latest versions

  • WebPass configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest WebPass release

  • Configuration files and filters for the Web server hosting the WebPass plug-in are updated to accommodate requirements for the latest WebPass release

Figure 1-2 illustrates the sequence of upgrade tasks that you must perform when you have an Identity System-only deployment.

Figure 1-2 Identity System Only Upgrade Tasks and Sequence

Identity System-Only Upgrade Tasks
Description of "Figure 1-2 Identity System Only Upgrade Tasks and Sequence"

An introduction to each task is described in "About the Execution Stage"

1.1.2 About Upgrading Joint Identity System and Access System Deployments

Figure 1-3 illustrates a very simple joint deployment of both the Identity System and Access System. Identified in the figure are the types of information that are upgraded for each component. As you can see, both the Identity System and Access System schema and data are also upgraded.

Figure 1-3 Joint Identity and Access System Deployment Overview

Joint Identity and Access System Deployment Overview
Description of "Figure 1-3 Joint Identity and Access System Deployment Overview "

The Oracle Access Manager schema and Identity and Access System data reside in the directory server. Schema and data upgrades are performed as described next and require write access to information in the directory server.

Identity System Schema and Data Upgrades

Even in a joint Identity and Access System deployment, Identity System schema and data upgrades include updating the following information types to meet requirements of the latest release:

  • Oracle Access Manager schema

  • Oracle Access Manager configuration data

  • Oracle Access Manager user and group data and runtime information

  • Oracle Access Manager workflow data

Access System Schema and Data Upgrades

Access System schema and data upgrades include updating the following information types to meet requirements of the latest release:

  • Oracle Access Manager policy data

  • Additional schema updates are not typically required for the Access System unless you have directory instances configured for use by only the Access System

Component information resides in the installation directory of the specific Oracle Access Manager component. The type of information that is upgraded depends on the component type: Oracle Access Manager Server or Oracle Access Manager Web component. For example:

Identity Server and Access Server Upgrades

Each Identity Server and Access Server component upgrade brings the following information up to release 10g (10.1.4.0.1)

  • Program and library files, including message and parameter catalogs, are replaced with the latest versions

  • Configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest Identity Server release

Policy Manager, WebPass, and WebGate Upgrades

Each Oracle Access Manager Web component upgrade (Policy Manager, WebPass, and WebGate) brings the following information up to release 10g (10.1.4.0.1):

  • Program and library files, including message and parameter catalogs, are replaced with the latest versions

  • Configuration settings, as well as system environment settings (in the Windows registry, for example), are updated to comply with requirements for the latest WebPass release

  • Configuration files and filters for the Web server hosting the Web component plug-in are updated to accommodate requirements for the latest release

A WebPass must also be installed with each Policy Manager on the same Web server instance, at the same directory level.

Figure 1-4 illustrates the sequence of upgrade tasks that you must perform when you have joint Identity and Access System deployment.

Figure 1-4 Upgrade Tasks and Sequence in Joint Identity and Access System Deployments

Joint Identity and Access System Upgrade Tasks and Sequence
Description of "Figure 1-4 Upgrade Tasks and Sequence in Joint Identity and Access System Deployments"

An introduction to each task is described in "About the Execution Stage".

1.2 Upgrade Task Overview

This discussion provides a very high level introduction to the sequence of tasks that you must perform. This is only a starting point in your planning. You perform the entire upgrade task in a sequential order in relation to the deployment approach adopted in your organization: Identity System only or Joint Identity and Access System deployment.

Figure 1-5 provides a high-level view of the upgrade tasks that you need to complete in each of your deployment environments, and the order in which these tasks must be performed. Additional information is provided in "About the Execution Stage".

Figure 1-5 High-Level Upgrade Task Overview

Upgrade Task Overview
Description of "Figure 1-5 High-Level Upgrade Task Overview"

1.2.1 About the Planning Stage

Before you start any upgrade activities, it is important to read through this entire chapter. In addition you need to collect and record specific details about your existing deployment.

For more information and specific details about planning, see "Upgrade Planning and Deliverables".

For downtime assessment planning, see "Planning Considerations for System Downtime".

Worksheets that you can use to record details about your existing deployment are provided in Appendix E, "Planning Worksheets and Tracking Checklists".

1.2.2 About the Execution Stage

This stage is illustrated in Figure 1-5 and outlined next. The sequence of tasks that you must complete is critical to your success. Checklists that can help you track the progress of upgrade tasks in your environment are provided in Appendix E, "Planning Worksheets and Tracking Checklists".


Note:

Task overviews like the one here outline the tasks that you must perform and provide a pointer to the discussion that provides the information you need to perform the task.

Task overview: Performing the upgrade includes

  1. Planning: Develop a planning document that defines a detailed approach for each of your installed environments is described in:.

  2. Upgrading the Schema and Data: Prepare for and upgrade the earlier Oracle Access Manager schema and data as described in:

  3. Preparing Remaining Components: After the schema and data upgrade, you must prepare other components for the upgrade as described in Chapter 8, "Preparing Components for the Upgrade".

  4. Upgrading Identity System Components: Perform Identity System component upgrades as described in Chapter 9, "Upgrading Remaining Identity System Components" and outlined in the following list:

  5. Upgrading Access System Components: Perform Access System component upgrade as described in Chapter 10, "Upgrading Access System Components" and outlined in the following list:

  6. Upgrading Third-Party Integration Connectors: Upgrade any Oracle Access Manager connectors for third-party integration components and for the J2EE Application Server (if any are being used) as described.

  7. Upgrading Independently Installed Software Developer Kits: Perform this upgrade to ensure the older APIs are upgraded (and ensure that any plug-ins developed using those APIs are compatible and working properly in the upgraded environment) as described.

  8. Upgrading Customizations: This task can be started well in advance of other tasks and performed in a separate environment to reduce the amount of system downtime as described in:

  9. Validating the Upgrade: After all other work is completed, you may verify system operation as described in Chapter 14, "Validating the Entire System Upgrade".

1.3 Upgrade Planning and Deliverables

Oracle strongly recommends that before starting any upgrade task, you and your team become familiar with all topics suggested in Figure 1-6, and the overview that follows the figure.

Figure 1-6 Upgrade Planning Overview

Upgrade Planning Overview
Description of "Figure 1-6 Upgrade Planning Overview"

Task overview: Planning for your upgrade

  1. Review the following information in this chapter to get a high-level overview of the upgrade task, considerations, planning deliverables, deployment scenarios, and starting points. For more information, see:

  2. Review Chapter 2, "Upgrade Concepts and Methods" to gain a deeper understanding of the methods and strategies you will use, and to learn about any applications and components that have been deprecated (no longer officially supported).

  3. Review Chapter 3, "About Automated Processes and Manual Tasks" to learn about the sequence of events that occur during the program-driven component upgrade, as well as what is preserved and what requires manual handling by you.

  4. Investigate the functional differences between earlier releases and Oracle Access Manager 10g (10.1.4.0.1) in the centralized summary provided in Chapter 4, "System Behavior and Backward Compatibility".


    Note:

    During component upgrades, backward compatibility with earlier plug-ins and WebGates is automatically enabled. However, the system may behave differently than in earlier releases.

1.3.1 Planning Considerations

As you begin to plan for the upgrade in your environment, be sure to take the following considerations in to account:

  • Deployment Scenarios: The upgrade task should be performed in a sequential order in relation to the deployment approach adopted in your organization: Identity System only versus Joint Identity and Access System; intranet versus extranet; number and type of installed environments.

    For example, if your earlier Identity System-only release is deployed only in an intranet environment with in three environments (Development, Test/Demonstration, and Production), the upgrade process should be performed and fine tuned in smaller environments before ultimately being performed in your production environment. For more information, see "Planning Considerations for Extranet and Intranet Deployments".

  • Stability: Each environment that you upgrade should currently be running a stable and appropriately installed release. In other words earlier Oracle Access Manager configurations in each existing environment must be confirmed to be stable and complete before you start upgrading.

    A good approach to validate that the existing environment is stable is to develop a deterministic test script and run it both before and after the upgrade. For example, the script could exercise a full end-to-end transaction by requesting a single page that requires authentication and authorization and a workflow request (all triggered by a single page request).

  • Administrative Access: Schema upgrade operations (as well as other upgrade operations) require administrative access with write permissions to the directory server and Oracle Access Manager files.

  • Schema and Data Upgrades: Preparing an earlier master Identity System (formerly known as the COREid System) and Policy Manager (formerly known as the Access Manager component) is a critical first step to performing a schema and data upgrade. For more information, see "Schema and Data Upgrade Planning".

  • Customization Upgrades: This is primarily a manual process. Oracle recommends that you complete any testing and alterations in a development environment before redeploying these in a shared or production environment. For more information, see "Customization Upgrade Planning".

1.3.2 Schema and Data Upgrade Planning

The schema and data upgrade must be performed by someone with administrator privileges that include write access to the directory and files. The sequence of tasks you must perform to upgrade your earlier Oracle Access Manager schema and data to 10g (10.1.4.0.1) depend on the type of deployment you have (Identity System only or both the Identity and Access Systems).

The methodology for upgrading the schema and data is new and designed to help you ensure that the schema and data are properly upgraded before you start upgrading other components.

When you have only the Identity System deployed (with one or more Identity Servers and WebPass instances), you perform the schema and data upgrade, then complete other upgrade tasks as indicated in the next overview.

Task overview: Upgrading the schema and data when you have only an Identity System installed

  1. Prepare and backup directory instances and data for the Identity System as described in Chapter 5, "Preparing for Schema and Data Upgrades".

  2. Add an earlier instance of the following components to create a master environment for the schema and data upgrade:

    • One earlier Identity Server instance (formerly known as the NetPoint or COREid Server) as a secondary server for your original master read/write directory server instances. The directory server administrator will use this instance as the Master Identity Server when upgrading the schema and data.

    • One earlier WebPass to communicate with the master Identity Server you added

      For more information, see "Adding An Earlier Identity System to Use as a Master".

  3. Upgrade the added master Identity System components and accept the automatic schema and data upgrade in the sequence in the following list:

    • Upgrade the master Identity Server, schema, and data (then upload directory index files).

    • Upgrade the master WebPass (there is no schema nor data upgrade here).

    • Validate the Identity System schema and data upgrade.

      For more information, see Chapter 6, "Upgrading Identity System Schema and Data".

  4. Prepare, then upgrade (and verify) remaining Identity System components, then integration components, then independently installed SDKs, and redeploy upgraded Identity System customizations in the sequence shown in Figure 1-5, "High-Level Upgrade Task Overview".

When your installation includes both the Identity and Access Systems, the overall process is a bit different as outlined in the next overview. In both cases, the directory server administrator will use the master environment that is added before upgrading the Identity and Access System schema and data. However, the sequence differs after that.

Task overview: Upgrading both the Identity and Access System schema and data

  1. Prepare and backup directory instances and data for both the Identity and Access System as described in Chapter 5, "Preparing for Schema and Data Upgrades"

  2. Add an earlier instance of the following components:

    • One earlier Identity Server instance (formerly known as the NetPoint or COREid Server) as a secondary server for your original master read/write directory server instances.

    • One earlier WebPass to communicate with the master Identity Server you added

      For more information, see "Adding An Earlier Identity System to Use as a Master".

    • One earlier Policy Manager instance (formerly known as the Access Manager component) as a secondary server for your original master read/write directory server instances. For more information, see "Adding an Earlier Access Manager to Use as a Master".

  3. Upgrade Identity Schema and Data: Upgrade the added master components and accept the automatic schema and data upgrade in the sequence in the following list:

    • Upgrade the master Identity Server, schema, and data (then upload directory index files).

    • Upgrade the master WebPass (there is no schema nor data upgrade here).

    • Validate the Identity System schema and data upgrade.

      For more information, see Chapter 6, "Upgrading Identity System Schema and Data".

  4. Upgrade Access System Schema and Data: Upgrade the added master component and accept the automatic Access System schema and data upgrade in the following sequence:

  5. Access System: Create a temporary directory profile to provide write access to policy data by the Access Server for later WebGate upgrades, as described in "Creating a Temporary Directory Profile For Access System Upgrades"

  6. Prepare, then upgrade (and verify) remaining Identity components, then Access System components, then integration components, then independently installed SDKs, and redeploy Identity System customizations then Access System customizations, as shown in Figure 1-5, "High-Level Upgrade Task Overview".

1.3.3 Customization Upgrade Planning

Customized configurations built around your earlier Oracle Access Manager installation must be manually tested for compatibility and upgraded for 10g (10.1.4.0.1). These include front-end customizations created using IdentityXML, PresentationXML, and the Access Manager API (formerly known as the Access Server API or simply as the Access API). Also included are back-end customizations created with the Identity Event API, Authentication API, Authorization API (including AccessGates and plug-ins).

Testing and upgrading earlier customizations is primarily a manual process that may take some development time. It is important to plan ahead to ensure that your customizations can be redeployed into a shared environment quickly (for example, for QA, Integration, or Production).

Recommendation: Upgrading customizations and plug-ins

  1. Start well in advance of other upgrades and review customization considerations in "Planning Considerations for System Downtime".

  2. Develop deterministic test scripts to run both before and after the upgrade to exercise a full end-to-end transaction.

    For example, the script could request a single page that requires authentication and authorization and a workflow request (all triggered by a single page request). Test scripts that verify the behavior of your earlier customizations help you ensure that these work as expected and produce the same result, both before and after the upgrade. Your test scripts will depend on the specific customization being exercised.

  3. Compile and test the code, and the instructions you developed to explain how to configure the customization in a given environment.

  4. In your existing environment, test the earlier customization (styles, AccessGates, or plug-ins for example) to ensure it is working as expected.

  5. Install 10g (10.1.4.0.1) in a small development environment (ideally a sandbox-type setting) where the dependency on the overall Oracle Access Manager deployment is minimal. For details, see the Oracle Access Manager Installation Guide.

  6. In the 10g (10.1.4.0.1) sandbox, test the earlier customization and perform any manual steps needed to upgrade the customization to operate with 10g (10.1.4.0.1) functionality.

  7. Upgrade Oracle Access Manager in the test or development environment, as described in "Upgrade Task Overview".

  8. When the test or development environment upgrade is successful, you can redeploy the compiled binaries and custom components, then upgrade your production environment.

For information about specific customizations, see:

1.3.4 Planning Deliverables

Planning deliverables include preparing a document where you define and record a detailed plan that identifies how the upgrade tasks will be performed within each environment. You can reduce the amount of system downtime by fine tuning the plan and tasks to meet the specific needs of each environment and to take into account the number of servers, downtime windows, and the like.

In addition, Oracle recommends that you prepare a detailed inventory of all earlier components and customizations. The details that you need to record for each component and the environment are described next. Planning worksheets that you can copy and fill in are provided in Appendix E, "Planning Worksheets and Tracking Checklists".

Task overview: Developing your planning deliverables

  1. Create a Planning Document: Define and record a detailed plan identifying how the upgrade process will be performed for each environment. For more information, see also:

  2. Take Inventory of the Earlier Environment: If you have not already recorded the exact details of the earlier environment, do so now and include both Access and Identity components, directory servers, Web servers, and applications as indicated next. Planning worksheets that you can copy and fill in are provided in Appendix E, "Planning Worksheets and Tracking Checklists".

    • Environment Details:


      Transport security mode; Simple, Cert, or Open
      Root CA details if certificate mode is used
      Any host definition type entries relevant to NetPoint (for example, /etc/host)

      Identity Server Inventory:
      Workflows, search bases and ACLs
      Object definition details for all objects managed through NetPoint, if possible
      Auditing configuration details
      Password policy configuration

      Access Server Inventory:
      Policy domains, authentication schemes, resource definitions, host identifiers
      Auditing configuration
      Directory profile information

    • Application Tier Details that will be impacted by the upgrade. For example:


      WebGate protected integration that uses Cookies or header variables
      (the impact on these should be minimal).
      Custom AccessGate integration created using the API, which may have a
      more noticeable impact.
      Applications exposing Oracle Access Manager Identity Portal Inserts
      (such as portals).
      Look carefully at these to ensure that "service temporary unavailable"
      pages can be displayed during the upgrade process when access to
      workflows is unavailable.
      Applications relying on IdentityXML have the highest impact,
      because the IdentityXML service may be unavailable altogether
      (it could be complicated to separate read-only calls from write calls
      and might be best to disable the entire application during the
      upgrade process)

    • Administration and Presentation tier details for each WebGate, WebPass, and Web server:


      Web server type, version, operating system,
      WebPass or WebGate identifier and exact patch version of the binary (for
      example, 6.1.1.19 or 7.0.4.2)
      Exact Oracle Access Manager patch version (for example, 6.1.1.19 or 7.0.4.2)
      WebPass or WebGate installation directory
      Connection information between the component and corresponding
      Oracle Access Manager Server, including primary or secondary status
      and number of connections

    • Details for each and every AccessGate, WebGate, Policy Manager (Policy Manager was formerly known as the Access Manager component), application server integration (such as WebLogic SSPI, WebSphere, and Oracle OC4J to name a few) such as:


      HTTP Cookie domain, preferred host name, cache timeout and size,
      failover threshold
      Inventory any IdentityXML client that has been custom developed
      Inventory any virtual IP and DNS aliases used to reference the WebPass or
      Web server farm protected with WebGate, such that it would be feasible to
      alter their definition in cases where staged upgrade of the web server
      components (WebPass and WebGate be planned/required)

    • Oracle Access Manager Server Tier (for each Identity and Access Server):


      Exact patch level (6.1.1.19 or 7.0.4.2, for example)
      Installation directory for the Identity or Access Server
      Installation directory for the associated WebPass or WebGate
      TCP port number for the service for example, port 6021)
      Host name (DNS) and Identity (formerly COREid) Server identifier
      For the Access Server note the status of the Access Management flag (on or
      off)
      Inventory any customizations performed
      Identify any Identity Event plug-ins
      For the Access Server, note any customized authentication or authorization
      plug-ins
      Record any PresentationXML and XSL stylesheet customizations
      Record any file-based changes such as changes in globalparams.xml or .lst files
      Are the Identity Server (and Access Server) configured to audit to files or a
      database
      For Unix systems, record the user name and group membership for the
      Identity Server (formerly known as the COREid Server)

    • Directory Server Tier:


      Exact directory server version and patch level for example, Sun ONE v5.2 SP2)
      Directory server DNS name and Port
      Transport security mode: LDAP, LDAPS, ADSI
      Binding credentials used by Oracle Access Manager
      DIT and schema objects used in Oracle Access Manager
      Master/replica configuration details For more information, see "Schema and Data Upgrade Planning"

  3. Customization Assessment and Planning: You must ensure that any custom developed plug-ins, Access Manager API clients, IdentityXML clients, PresentationXML customizations, Portal Inserts, and customized styles are compatible with Oracle Access Manager 10g (10.1.4.0.1). This is primarily a manual process. For more information, see:

1.4 Planning Considerations for System Downtime

During an upgrade in any environment, system downtime is inevitable. Oracle recommends that you pay special attention to planning and coordinating with any external party that may be directly or indirectly impacted during the upgrade.

Most Oracle Access Manager deployments provide a mission-critical element of the enterprise infrastructure by supporting applications. For example, suppose Oracle Access Manager is protecting access to an employee portal, and providing a registration service for new users. During the upgrade, new users may not be able to register. Moreover, there could be a window of time during which access to the portal and any of the protected applications is not available. This may present significant impact to end users.

This discussion provides information to help you determine the amount of downtime required for the upgrade process and manual upgrade tasks in your environment. There will be some disruption to the services provided by Oracle Access Manager during some portion of the process. However, you can take steps to minimize the overall amount of service downtime. For example, if Oracle Access Manager is deployed in three environments: Development, Test/Demonstration, and Production, then upgrade tasks should be first tried in Development and fine tuned before ultimately being performed in production.

Recommendation: Upgrading each deployment in your environment

  1. Perform the entire upgrade task, illustrated next, in your Development environment.

  2. When your Development environment is successfully upgraded and confirmed to be running properly, perform the entire upgrade task again in your Test/Demonstration environment.

  3. When your Test/Demonstration environment upgrade is successfully completed and running properly, you perform the entire upgrade task in your Production environment.

This approach helps you gauge the time it takes to perform the upgrade in your environment and ensure that all customizations and plug-ins are working properly before you start upgrading in a production environment. This also helps ensure that your production environment upgrade will go smoothly and quickly with fewer service interruptions.

The emphasis is on reducing the impact on availability of Oracle Access Manager (formerly Oblix NetPoint or Oracle COREid) service during the upgrade. One goal of this approach is to identify tactics that can help reduce overall upgrade time and minimize service impact. As you perform upgrade tasks within each environment, you can develop strategies and optimizations that significantly streamline the overall task.

Oracle recommends careful planning to minimize the operational impact of upgrading your earlier environment. Oracle cannot guarantee that a service outage is not required to complete the upgrade.

When planning the upgrade for each environment, it is important to take into account the criticality and number of applications that depend on Oracle Access Manager. This may increase with each environment. Pay special attention to coordinating the change process that the upgrade represents to the environment as a whole. It is important to work with the application owners to ensure that end user impact is properly managed. Standard procedures such as a change control process, scheduled maintenance windows, off hours operation windows, and others should be considered when planning the Oracle Access Manager upgrade.

When assessing the impact of the Oracle Access Manager upgrade, take inventory and categorize the various applications that depend on Oracle Access Manager. This can include applications protected by the Access System, or applications that leverage the Identity System for identity administration functions, as well as the impact on the underlying directory environments. Directory environments are particularly important because the upgrade process requires a directory schema update. In many environments, upgrading the directory schema is a highly privileged operation handled by a directory administration group.

As you take inventory and categorize the various applications, be sure to estimate potential outage windows for each application. This will help set and manage end-user expectations. The estimated duration of outage windows will vary depending on the type of application (whether it is Access System or Identity System dependent) and the estimated duration of the upgrade tasks. For the production environment, estimates can be extrapolated from the experience gained when performing upgrade tasks and fine tuning in your Development and Testing/Demonstration environments.

For more information, see:

1.4.1 Minimizing Downtime During the Upgrade

The upgrade process will require some downtime of enterprise applications that rely on Oracle Access Manager for identity administration, authentication, and authorization. There are a few upgrade tasks that can occur without impacting these applications. Table 1-1 outlines lists the upgrade tasks, their downtime impact, and planning considerations to minimize downtime where applicable.

Table 1-1 Minimizing Downtime

Upgrade Task Downtime Impact Steps to Reduce Downtime

Upgrade Planning

None

N/A. Review the planning chapters, fill in the worksheets as you take inventory of your environment to reduce the probability of human errors, use the checklists to track progress as you complete upgrade tasks.

Preparing for Schema and Data upgrades

None

N/A

Upgrading the Schema and Data

All Oracle Access Manager servers are down and all consumers of Oracle Access Manager are impacted.

Make backups and be prepared with recovery procedures in case of problems. Validate the process in stage environment before trying in production.

Upgrading Oracle Access Manager components

All Oracle Access Manager servers are down and all consumers of Oracle Access Manager are impacted.

Make backups and be prepared with recovery procedures in case of problems. Validate the process in stage environment before trying in production.Validate the upgrade in a staging environment before upgrading in production.

Upgrading Third-Party Integration Connectors

Only those third-party environments in which the deployment has chosen to upgrade the connectors.

Validate the upgrade in a staging environment before upgrading in production. Consider that Oracle Access Manager is backward compatible with earlier environments, as described in Chapter 4, which may be exploited to minimize downtime.

Upgrading Independently Installed SDKs

Only those environments where an independently installed SDK must be upgraded are impacted.

Validate the upgrade in a staging environment before upgrading in production. Consider that Oracle Access Manager is backward compatible with earlier environments, as described in Chapter 4, which may be exploited to minimize downtime.

Upgrading Customizations

Deployment services that rely on Identity or Access System customizations are impacted.

Apply customizations in a staging environment first, to resolve issues. Then apply them in a production environment.

Validating the Upgrade

None

N/A


1.4.2 Downtime Assessments

Perhaps the greatest amount of time spent in upgrading occurs during the planning process, which occurs offline. Careful planning can help reduce the overall amount of downtime needed to upgrade each environment in your enterprise.

The second greatest amount of time spent in the upgrade task occurs when preparing for the schema and data upgrade.

Less time will be spent actually upgrading components. Depending on your deployment and the amount of customization, some time must be allotted for any manual tasks needed to ensure that your earlier customizations are compatible with 10g (10.1.4.0.1) and are successfully redeployed. However, customizations can be handled outside the shared environment and have minimal impact on system downtime.

The following considerations are provided to help you understand the overall upgrade impact and downtime in your environment. Additional information is provided in "Downtime Assessment Example".

  • Planning and taking inventory of your existing environment, as discussed in this chapter and other chapters in Part I, "Introduction", is a zero downtime activity. Careful planning can actually help reduce the amount of system downtime during actual upgrade tasks.

  • Schema and data upgrades (introduced in "Schema and Data Upgrade Planning" and described in Part II, "Upgrading the Schema and Data") will take the greatest amount of time, and includes:

    • Preparing your LDAP directory instances and data

    • Making backup copies of all data, installation directories, and Windows registry entries that include Oracle Access Manager information before the upgrade

    • Preparing a master system to use during the actual schema upgrade

    • Performing the actual schema upgrade

    • Performing the actual data upgrade, which depends upon the number of workflows and workflow steps and the number of access policies, domains, and protected resources

    • Verifying that the schema and data upgrade was successful

  • Preparing and upgrading all other Oracle Access Manager components, and Web server configuration upgrades, as described in Part III, "Upgrading Components", for the most part does not require system downtime.

  • Manually processing customized stylesheets, plug-ins, forms-based authentication, audit to database implementations, and the like, as described in Part IV, "Upgrading Your Customizations", can be performed outside the shared environment (which greatly reduces the amount of system downtime required)

  • Verifying that the upgrade was a success, as discussed in Part V, "Validating the Upgrade" does not result in system downtime.

1.4.3 Downtime Assessment Example

The following estimates are provided to give you an idea of the amount of time it takes to upgrade an earlier deployment that includes approximately 100 workflows, 500 policy domains, 2500 access policies, and 1700 protected resources.

Identity System Downtime Assessment

Access System Downtime Assessment

Therefore, to upgrade both the Identity and Access Systems in this environment will take about 11 hours for tasks that require system downtime.

1.5 Planning Considerations for Extranet and Intranet Deployments

Existing earlier Oracle Access Manager deployments can be classified into two primary categories: Extranet (B2B,G2C, B2C) and Intranet (B2E, G2E) deployments. These are, of course, generic categories. However, for the purposes of understanding deployment demographics these should provide relevant patterns.

For more information, see the topics:

1.5.1 Extranet Deployments

Extranet deployments are those where you have:

  • A relatively large user population (over 20 thousand users)

  • The user population is being served through a relatively small number of applications (less than 20)

  • The applications are integrated with NetPoint (Oracle Access Manager), and are typically consolidated in a portal

The most typical characteristics for extranet deployments include:

  • A higher complexity on the Identity System deployment relative to the Access System

  • A large number of workflows (self-registration, self-service, delegated administration) typically involving Identity Event plug-ins (customizations)

  • Sophisticated delegated administration requirements, often involving various user types (at a minimum four levels of administrative roles/access) and reliance on ACLs, groups, and other objects.

  • User interface customizations (accomplished using XSL stylesheets, PresentationXML, and IdentityXML) because the majority of the requirements center on identity administration of a large number of users and ease of use is a paramount driver. The majority of implementations will exhibit front end user interfaces built on top of IdentityXML.

  • Features such as lost password management are very commonly configured.

  • A relatively small software footprint (for example, only a handful of servers—2 to 4 servers at each tier—often distributed between a few data centers), and a very low tolerance for downtime because the applications that rely on Oracle Access Manager are often business critical.

  • Commonly the directory environment is dedicated to Oracle Access Manager and the applications it supports. Therefore, there is a bit more control over the directory service in conjunction with Oracle Access Manager from an operational perspective. There are a relatively small number of stakeholders from the application side (typically belonging to a common line of business.)

Performing the upgrade to 10g (10.1.4.0.1) with minimal service disruption in such a highly complex environment can be challenging.

1.5.2 Intranet Deployments

Intranet deployment environments are typically:

  • Internal facing portals with a relatively small user population (less than 20 thousand users)

  • The user population is being served through a relatively large number of applications (more than 20) integrated with NetPoint (also known as Oracle Access Manager)

The most typical characteristics for intranet deployments include:

  • A greater prevalence of the Access System customizations, if any, are typically:

    • On the front-end at the login page (or login front-end)

    • Or using custom built AccessGates

    • Or on the back-end using customized authentication or authorization plug-ins developed with the APIs

  • A relatively large number of applications (over 20) being protected where the emphasis is primarily on authentication and single-sign on (SSO), with a significant number of application-level integrations.

  • A high number of BEA WebLogic and IBM WebSphere Application Server integrations using Oracle Access Manager connectors for these servers.

  • Often the Identity System is either not widely deployed, or deployed only to an administrator user community (for example, the help desk, IT department, or system administrators).

  • Password management features are not typically configured or used, because Oracle Access Manager often relies on the same back end store as the NOS (AD), and it is rare to see self-registration workflows.

  • These environments tend to have a broad footprint, especially at the WebGate/AccessGate tier, with a high number of Web servers and Application servers with WebGate to Access Server ratios in the range of 10:1.

  • On the Access Server tier, intranet deployments tend to be global and geographically distributed, with a handful of servers deployed in each location.

  • The directory environment is often shared, because it is the employee directory or even the NOS directory (AD). Therefore, the number of dependencies associated to the directory is high (meta-directories, provisioning solutions, NOS logon, white pages, and the like). As a result, changes and operational impact to the directory is very rigorously managed. Many stakeholders need to be coordinated with in a change-control process, and tight operational windows are allowed. On the application front, there tends to be more flexibility on server availability, and applications tend to be "clustered" by line of business, geography, or security requirements. Therefore, the impact can be segregated.

1.6 Upgrade Paths

This discussion introduces the paths available when upgrading from an earlier release to Oracle Access Manager 10g (10.1.4.0.1). The path available to you depends upon your starting release (the release from which you are starting the upgrade) as described in:

1.6.1 Direct Upgrade Paths

There are several direct paths available to bring an earlier release up to Oracle Access Manager 10g (10.1.4.0.1), as described in following discussions:

1.6.1.1 From Release 6.1.1 to Oracle Access Manager 10g (10.1.4.0.1)

Release 6.1.1 deployments are typically large in terms of the number of components deployed at each tier of the architecture, as well as other systems and applications. Oracle Access Manager 6.1.1 is an English only release.

If you are upgrading from release 6.1.1, you may use the Oracle Access Manager 10g (10.1.4.0.1) installers to perform a direct upgrade. During the upgrade, each component installer automatically implements product changes for each release between release 6.1.1 and Oracle Access Manager 10g (10.1.4.0.1). This includes automatically enabling the multi-language capability available in Oracle Access Manager 10g (10.1.4.0.1).

Every environment requires some preparation before starting the upgrade, as discussed in Chapter 5, "Preparing for Schema and Data Upgrades" and Chapter 8, "Preparing Components for the Upgrade". There are no additional caveats and conditions when upgrading directly from release 6.1.1.

1.6.1.2 From Release 6.5 to Oracle Access Manager 10g (10.1.4.0.1)

Release 6.5.0 introduced multi-language support for French and German in addition to providing and enabling English language messages. When you have any Oracle Access Manager 6.5 release, you use the Oracle Access Manager 10g (10.1.4.0.1) installers to upgrade directly as described in this manual.

Table 1-2 discusses the various 6.5 releases.During the direct upgrade from any Oracle Access Manager 6.5.x release, each component installer automatically implements product changes for each release between release 6.5.0 and Oracle Access Manager 10g (10.1.4.0.1).

To retain earlier multi-language functionality, you must include 10g (10.1.4.0.1) Language Packs in the same directory as the 10g (10.1.4.0.1) installation package that you use to upgrade the component. Otherwise, only the English language is used. You may install additional supported languages after the upgrade, as described in the Oracle Access Manager Installation Guide.

Table 1-2 Upgrade Paths from Oracle Access Manager 6.5 Releases

Starting From Upgrading To Caveat

6.5.0.x is an international release (English, German, French)

10g (10.1.4.0.1)


Before the upgrade, complete activities in "Adding Packages for Release 6.5.0.x". See also, "Preparing Multi-Language Installations".

6.5.1 is an English-only release that introduced support for Active Directory Application Mode (ADAM) as a back end directory.

10g (10.1.4.0.1)


No caveats or special requirements. Upgrade as described in this guide.

6.5.2.x is an English-only release

10g (10.1.4.0.1)


Before upgrading an installation patched to 6.5.2, complete activities in "Adding Packages for Release 6.5.2.x Patch".

6.5.3.x is an English-only WebGate release

Use 10g (10.1.4.0.1)

No caveats. Upgrade as described in this guide.


1.6.1.3 From Release 7.x to Oracle Access Manager 10g (10.1.4.0.1)

With the exception of release 7.0.4 (which is an international release that was available as part of Oracle Application Server 10g Release 2 (10.1.2)), all 7.x releases are English only. Typically, NetPoint 7.x environments are newer and less complex than NetPoint 6.5 or 6.1.1 environments.

Table 1-3 provides a brief overview of 7.x releases. During the direct upgrade from any 7.x release, each component installer automatically implements product changes for each release between 7.0 and Oracle Access Manager 10g (10.1.4.0.1) and enables multi-language capability. To retain earlier multi-language functionality (or to install new languages), you can include 10g (10.1.4.0.1) Language Packs in the same directory as the 10g (10.1.4.0.1) installation package. Otherwise, only the English language is used.

Table 1-3 Upgrade Paths from Series 7.x Releases

Starting From Upgrading To Caveat

Release 7.0

10g (10.1.4.0.1)


No caveats. Upgrade as described in this guide and include Language Packs if desired to upgrade languages.

Release 7.0.1, and later, provide additional platform certifications and parameter and message updates. Going forward, new GIFs, XSL, HTML, images, or similar files can be included in a patch release.

10g (10.1.4.0.1)


No caveats. Upgrade as described in this guide and include Language Packs if desired to upgrade languages.


1.6.2 Indirect Upgrade Paths

If you are upgrading from any Oracle Access Manager release earlier than 6.1.1, no direct upgrade path is available to Oracle Access Manager 10g (10.1.4.0.1). In this case, an intermediate upgrade from your earlier release to release 6.1.1 is required. From release 6.1.1, you can upgrade directly to Oracle Access Manager 10g (10.1.4.0.1).

Table 1-4 lists the various starting point scenarios and associated caveats for an intermediate upgrade.

Table 1-4 Upgrade Paths from Release 5.x through 6.1

Starting From Upgrading To Caveats and Conditions

Release 5.2

Release 6.1

Release 6.1.1

Oracle Access Manager 10g (10.1.4.0.1)

To retain Publisher, you can upgrade only to Oracle Access Manager 6.1.

If you abandon Publisher you may complete an intermediate upgrade to 6.1.1.

From release 6.1.1 you may upgrade directly to Oracle Access Manager 10g (10.1.4.0.1).

For information on the intermediate upgrade, contact Oracle Support at http://www.oracle.com/support/contact.html.

Release 6.0

Release 6.1

Release 6.1.1

Oracle Access Manager 10g (10.1.4.0.1)

To retain Publisher, you can upgrade only to Oracle Access Manager 6.1.

If you abandon Publisher you may complete an intermediate upgrade to 6.1.1.

From release 6.1.1 you may upgrade directly to Oracle Access Manager 10g (10.1.4.0.1).

For information on the intermediate upgrade, contact Oracle Support at http://www.oracle.com/support/contact.html.

Release 6.1

Release 6.1

Release 6.1.1

Oracle Access Manager 10g (10.1.4.0.1)

To retain Publisher, no further upgrade is possible.

If you abandon Publisher you may complete an intermediate upgrade to 6.1.1.

From release 6.1.1 you may upgrade directly to Oracle Access Manager 10g (10.1.4.0.1).

For information on the intermediate upgrade, contact Oracle Support at http://www.oracle.com/support/contact.html.


Specific details of the intermediate upgrade from earlier releases to release 6.1.1 are outside the scope of this manual. Before you start upgrading from a release earlier than 6.1.1, contact Oracle Support at:

http://www.oracle.com/support/contact.html