Oracle® Access Manager Upgrade Guide 10g (10.1.4.0.1) Part Number B25354-01 |
|
|
View PDF |
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. |
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. |
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
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:
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
An introduction to each task is described in "About the Execution Stage"
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
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:
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
An introduction to each task is described in "About the Execution Stage".
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
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".
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
Planning: Develop a planning document that defines a detailed approach for each of your installed environments is described in:.
Upgrade Planning and Deliverables outline details you need to record for all earlier installed Identity and Access System components, directory servers, Web servers, and applications
Schema and Data Upgrade Planning introduces considerations and sequences for schema and data upgrades
Customization Upgrade Planning discusses considerations and sequences to upgrade earlier customizations
Planning Considerations for System Downtime introduces strategies to minimize system downtime during the entire upgrade procedure
Planning Considerations for Extranet and Intranet Deployments are described
Upgrade Paths outlines starting releases and strategies for each one
Upgrading the Schema and Data: Prepare for and upgrade the earlier Oracle Access Manager schema and data as described in:
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".
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:
Upgrading Remaining Identity Servers, one by one, as described
Note: When you have auditing and access reporting configured for a database in the earlier environment, immediately following each Identity Server upgrade you must import earlier Identity Server auditing data to a new database instance, as discussed in "Upgrading Auditing and Access Reporting for the Identity System". |
Upgrading Remaining WebPass Instances, one by one,
Upgrading Access System Components: Perform Access System component upgrade as described in Chapter 10, "Upgrading Access System Components" and outlined in the following list:
Creating a Temporary Directory Profile For Access System Upgrades must be performed after upgrading the Access System schema and data and before upgrading any other Access System components as described
Upgrading Remaining Policy Managers, one by one, as described
Note: When you have auditing and access reporting configured for a database in the earlier environment, immediately following each Identity Server upgrade you must import earlier Identity Server auditing data to a new database instance, as discussed in "Upgrading Auditing and Reporting for the Access Server". |
Upgraded Access Servers are automatically backward compatible with earlier WebGates. For more information, see Chapter 4, "System Behavior and Backward Compatibility".
Upgrading WebGates can be staggered and performed gradually over time, as discussed in.
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.
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.
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:
Validating the Upgrade: After all other work is completed, you may verify system operation as described in Chapter 14, "Validating the Entire System Upgrade".
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.
Task overview: Planning for your upgrade
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:
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).
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.
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. |
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".
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
Prepare and backup directory instances and data for the Identity System as described in Chapter 5, "Preparing for Schema and Data Upgrades".
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".
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".
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
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"
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".
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".
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:
Upgrade the master Policy Manager, Access System schema and policy data, then upload directory index files.
Validate the Access System schema and data upgrade.
For more information, see Chapter 7, "Upgrading Access System Schema and Data".
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"
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".
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
Start well in advance of other upgrades and review customization considerations in "Planning Considerations for System Downtime".
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.
Compile and test the code, and the instructions you developed to explain how to configure the customization in a given environment.
In your existing environment, test the earlier customization (styles, AccessGates, or plug-ins for example) to ensure it is working as expected.
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.
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.
Upgrade Oracle Access Manager in the test or development environment, as described in "Upgrade Task Overview".
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:
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
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:
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".
Application Tier Details that will be impacted by the upgrade. For example:
Administration and Presentation tier details for each WebGate, WebPass, and Web server:
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:
Oracle Access Manager Server Tier (for each Identity and Access Server):
Directory Server Tier:
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:
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
Perform the entire upgrade task, illustrated next, in your Development environment.
When your Development environment is successfully upgraded and confirmed to be running properly, perform the entire upgrade task again in your Test/Demonstration environment.
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:
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 |
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.
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
Planning and Taking Inventory (of the currently installed environment): Zero downtime. This task is performed outside the environment, before the upgrade. For more information, see "Planning Deliverables".
Preparing for the Schema and Data Upgrade: ~1 hour and includes:
Directory Server Backups: ~15 to 30 minutes For more information, see "Backup and Recovery Strategies".
File system Backups: ~15 minutes. For more information, see "Backup and Recovery Strategies".
Schema Upgrade: ~20 minutes
Data Upgrade: ~1.5 hours
Identity System Component Upgrades: ~5 minutes for each component (Identity Server and WebPass) instance, which includes parameter/message upgrades and Web server configuration upgrades.
Identity System Customization Upgrades (Zero Downtime): The following manual tasks can be performed ahead of the production environment upgrade and outside the shared environment. As a result, there is no system downtime for these activities:
Install and set up a fresh 10g (10.1.4.0.1) Identity System to use when testing and upgrading customizations, as described in the Oracle Access Manager Installation Guide.
Auditing and Access Reporting: Create a new database instance for use with 10g (10.1.4.0.1), as described in "Upgrading Auditing and Access Reporting for the Identity System".
Portal Inserts: "Ensuring Compatibility with Earlier Portal Inserts".
Custom Identity Event Plug-ins: Redesign and recompile custom plug-ins as described in "Migrating Custom Identity Event Plug-Ins".
Styles: Incorporate stylesheet/javascript/msgcatalog/gif customizations from prior releases, as described in Chapter 12, "Upgrading Your Identity System Customizations".
Validation: Use procedures in "Validating Identity System Customization Upgrades".
Identity System Customization Redeployment: ~30 minutes. If you perform the manual customization tasks in the preceding list before upgrading, you need only copy the required files to appropriate directories after upgrading components. This should significantly reduce the amount of downtime during the production environment upgrade.
Identity System Customization After Upgrading: ~1 hour:
Identity System, Total Downtime: ~5 hours
Access System Downtime Assessment
Planning and Taking Inventory (of the current installed environment): Zero downtime. This task is performed outside the environment, before the upgrade. For more information, see "Planning Deliverables".
Preparing for the Access System Schema and Data Upgrade: ~1 hour and includes:
Directory Server Backups: ~15 to 30 minutes. For more information, see "Backup and Recovery Strategies".
File system Backups: ~15 minutes. For more information, see "Backup and Recovery Strategies".
Access System Schema Upgrade: ~20 minutes
Access System Data Upgrade: ~2 hours
Access System Component Upgrades: ~5 minutes for each component instance (Policy Manager, Access Server, WebGate), which includes parameter/message upgrades and Web server configuration upgrades.
Access System Customization Upgrades (Zero Downtime): Several manual tasks can be performed ahead of the production environment upgrade and outside the shared environment. As a result, there is no system downtime for these activities:
Install and set up a fresh 10g (10.1.4.0.1) Access System to use when testing upgraded customizations, as described in the in the Oracle Access Manager Installation Guide.
Auditing and Access Reporting: Complete this task for the Access Server, as described in "Upgrading Auditing and Reporting for the Access Server".
Forms-based Authentication: Perform activities in "Upgrading Forms-based Authentication".
Custom Authentication and Authorization Plug-ins: "Recompiling and Redesigning Custom Authentication and Authorization Plug-Ins" is described.
Updating the ObAMMasterAuditRule_getEscapeCharacter in Custom C Code is described.
Validation: Validating Access System Customization Upgrades is described.
Access System Customization Redeployment: ~30 minutes. If you perform the manual customization tasks in the preceding list before upgrading, you need only copy the required files to appropriate directories after upgrading components. This should significantly reduce the amount of downtime during the production environment upgrade.
Access System Customization After Upgrading: ~1 hour:
Access System Total: ~5.5 hours of downtime
Therefore, to upgrade both the Identity and Access Systems in this environment will take about 11 hours for tasks that require system downtime.
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:
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.
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.
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:
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:
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.
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. |
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. |
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 |
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 |
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 |
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: