| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.3) Part Number E12495-01 |
|
|
View PDF |
Activities in this chapter should be performed after upgrading the schema and data, after upgrading Identity System components, after upgrading Access System components, after upgrading integration components, SDKs, and customizations. Unless explicitly stated, topics in this chapter apply equally to both upgrade methods. Topics in this chapter include:
Preparing Upgraded Environments for 10g (10.1.4.3) Language Packs
Restarting On-the-fly User Data Migration for In-place Upgrades
After upgrading, Oracle recommends that you perform tasks to validate that you can access and use the Identity System Console and applications. For more information about these tasks, see the Oracle Access Manager Identity and Common Administration Guide.
Note:
If you are using the zero downtime upgrade method, you will perform these tasks after upgrading the schema, the data, the clone system, and the original system. For more information, see "Validating Successful Operations in Your Environment".To validate your Identity System upgrade
Identify the COREid System applications and functions that are affected by your upgrade and develop a plan to test these.
Ensure that your Identity Server service and WebPass Web server instance are running.
Navigate to the Identity System Console from your browser by specifying the appropriate URL. For example:
http://hostname:port/identity/oblix
where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /identity/oblix connects to the Identity System Console.
The Oracle Access Manager landing page should appear.
Landing Page Does Not Appear: Confirm that you have specified information accurately. Look for troubleshooting tips in Appendix G.
Perform any of the tasks listed next to verify operations, and use your own test plan as a guide:
View the directory server profile for this Identity Server by selecting Identity System Console, System Configuration, Directory Profiles, link_to_this_profile
Set up panels in the User Manager, Group Manager, Organization Manager.
Set up object-based searchbases in the User Manager.
Set up access controls in the User Manager, Group Manager, or Organization. Manager.
Create workflow definitions.
Configure options such as the mail server and session settings.
You can complete any of the next steps to validate that the Access System schema and data upgrade have been successful. For more information, see Oracle Access Manager Access Administration Guide.
Note:
If you are using the zero downtime upgrade method, you will perform these tasks after upgrading the schema, the data, the clone system, and the original system. For more information, see "Validating Successful Operations in Your Environment".To verify a successful Access System upgrade
Identify the Access System functions that are affected by your upgrade and develop a plan to test these.
Ensure your Policy Manager Web server and WebPass Web server instance are running.
Navigate to the Access System Console from your browser by specifying the appropriate URL. For example:
http://hostname:port/access/oblix
where hostname refers to computer that hosts the Web server; port refers to the HTTP port number of the WebPass Web server instance; /access/oblix connects to the Access System Console.
The Oracle Access Manager landing page should appear.
Landing Page Does Not Appear: Confirm that you have specified information accurately. Look for troubleshooting tips in Appendix G.
Log in to the Policy Manager/Access System Console as a Master Administrator.
Complete the following tasks, and refer to your own test plan to ensure that the Access System is working properly. For example:
Display configuration details for an authentication scheme by clicking the link that corresponds to the scheme.
Define or modify a policy domain.
Explore the Access System Console.
Access a protected resource to confirm that login is working.
Log out, as usual.
After validating that everything in your upgraded environment is working properly, Oracle recommends that you apply the latest patch set, available on My Oracle Support (formerly Metalink).
Skip any steps that do not apply to you.
Task overview: Applying the latest patch set
Perform procedures in "Preparing Upgraded Environments for 10g (10.1.4.3) Language Packs", as needed for your environment.
See Obtaining Packages for Upgrades in Chapter 4 for details about the sequential application of patch sets and how to acquire them.
10g (10.1.4.0.1) Environment: Apply the 10g (10.1.4.2.0) patch set as described in the Oracle Access Manager Patchset Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems and then proceed to step 4.
10g (10.1.4.2.0) Environment: After applying the 10g (10.1.4.2.0) patch (or performing the zero downtime upgrade) apply the 10g (10.1.4.3) patch set as described in the Oracle Access Manager Patchset Notes Release 10.1.4 Patchset 2 (10.1.4.3.0) For All Supported Operating Systems.
To use NPTL after applying the 10g (10.1.4.3) patch set, see ""NPTL Requirements and Post-Installation Tasks".
Oracle Access Manager 10g (10.1.4.3) supports only 10g (10.1.4.3) Language Packs. A 10.1.4 environment includes at least the English language and perhaps one or more non-English Language Packs.
This section describes how to prepare a 10.1.4 environment before applying the 10g (10.1.4.3) patch. After upgrading to 10.1.4 using either method described in this book, you must remove 10g (10.1.4.0.1) Language Packs before applying the 10g (10.1.4.3) patch set. After applying the 10g (10.1.4.3) patch set you can install 10g (10.1.4.3) Language Packs.
Note:
To retain multi-language functionality from your earlier deployment during an upgrade to 10.1.4, see "Acquiring and Using Multiple Languages".For more information, see the following topics:
English is the Default Language in the Upgraded 10.1.4 Environment
Non-English Default Language in the Upgraded 10.1.4 Environment
Note:
Oracle Access Manager 10g (10.1.4.3) does not provide combination Policy Manager/WebGate packages (except for IIS Web servers). If you have a 10g (10.1.4.0.1) environment that includes combination Policy Manager/WebGate, you must first install separate 10g (10.1.4.0.1) Policy Manager and WebGate before applying 10g (10.1.4.2.0) and then 10g (10.1.4.3) patch sets.The following task overview describes how to proceed when English is the default language in your upgraded environment.
Task overview: Preparing an upgraded 10.1.4 environment with English as the default language
Remove any installed 10g (10.1.4.0.1) Language Packages using instructions in the chapter "Removing Oracle Access Manager" in the Oracle Access Manager Installation Guide.
Policy Manager and WebGate in Same Directory: If you have installed the same Language Pack twice (once for Policy Manager and once for WebGate in the same directory), you will have two uninstallers available. For example, if the Japanese Language Pack was installed twice, you will have _uninstAccessLP_ja-jp and _uninstAccessLP_ja-jp2 in the installation directory. In this case:
Back up the JVM directory related to Language Pack installation, for example, as _jvmAccessLP_ja-jp.
Uninstall the second installed Language Pack, for example as _uninstAccessLP_ja-jp2.
Restore the JVM directory related to Language Pack installation from the backup copy you made in Step a.
Uninstall the first installed Language Pack, for example as _uninstAccessLP_ja-jp.
10g (10.1.4.0.1) Environment: Perform the tasks below before proceding to Step 4.
Apply the 10g (10.1.4.2.0) patch according to instructions in the patch set notes on My Oracle Support (formerly Metalink).
Apply the 10g (10.1.4.3) patch; according to instructions in the patch set notes on My Oracle Support (formerly Metalink).
Policy Manager and WebGate in Same Directory: Apply the 10g (10.1.4.3) patch to Policy Manager and WebGate.
10g (10.1.4.2.0) Environment: Apply the 10g (10.1.4.3) patch according to instructions in the patch set notes on My Oracle Support (formerly Metalink) before proceding to Step 4.
Install required 10g (10.1.4.3) Language Packs using instructions in the chapter "Installing Language Packs Independently" in the Oracle Access Manager Installation Guide.
Policy Manager and WebGate in Same Directory: Install the required 10g (10.1.4.3) Language Packs one time only; this will apply to both Policy Manager and WebGate.
The following task overview describes how to proceed when a non-English language is the default in your upgraded environment.
Note:
Most steps here are the same as those in "English is the Default Language in the Upgraded 10.1.4 Environment", above. Differences occur in Step 4.Task overview: Preparing an upgraded 10.1.4 environment with a non-English default language
Remove installed 10g (10.1.4.0.1) Language Pack, including the default language using instructions in the chapter "Removing Oracle Access Manager" in the Oracle Access Manager Installation Guide.
Policy Manager and WebGate in Same Directory: If you have installed the same Language Pack twice (once for Policy Manager and once for WebGate in the same directory), you will have two uninstallers available. For example, if the Japanese Language Pack was installed twice, you will have _uninstAccessLP_ja-jp and _uninstAccessLP_ja-jp2 in the installation directory. In this case:
Back up the JVM directory related to Language Pack installation, for example, as _jvmAccessLP_ja-jp.
Uninstall the second installed Language Pack, for example as _uninstAccessLP_ja-jp2.
Restore the JVM directory related to Language Pack installation from the backup copy you made in Step a.
Uninstall the first installed Language Pack, for example as _uninstAccessLP_ja-jp.
10g (10.1.4.0.1) Environment: Perform the tasks below before proceding to Step 4.
Apply the 10g (10.1.4.2.0) patch according to instructions in the patch set notes on My Oracle Support (formerly Metalink).
Apply the 10g (10.1.4.3) patch according to instructions in the patch set notes on My Oracle Support (formerly Metalink).
Policy Manager and WebGate in Same Directory: Apply a 10g (10.1.4.3) patch to Policy Manager and WebGate.
10g (10.1.4.2.0) Environment: Apply the 10g (10.1.4.3) patch according to instructions in the patch set notes on My Oracle Support (formerly Metalink).
Proceed as follows to install required 10g (10.1.4.3) Language Packs:
Note:
Policy Manager and WebGate in Same Directory: Install the required 10g (10.1.4.3) Language Packs one time only; this will apply to both Policy Manager and WebGate.Install required 10g (10.1.4.3) Language Packs using instructions in the chapter "Installing Language Packs Independently" in the Oracle Access Manager Installation Guide.
Reinstate the Default Language:
Prepare an options.txt file with contents as shown in the following example, and store this file in the same directory as 10g (10.1.4.3) Language Pack installer. For example:
-W ObPropBean.defaultLocale="ja-jp"
Here "ja-jp" represents the default language for your deployment. The default language you choose might be different.
Start the 10g (10.1.4.3) Language Pack installer as follows to reinstate the default language:
Oracle_Access_Manager10_1_4_3_0_JA_Win32_LP_Identity_System.exe -options options.txt
You can skip this discussion if you performed a zero downtime upgrade, or if you did not halt on-the-fly user data migration during an in-place upgrade.
You use the procedure here to restart on-the-fly user data migration only if you performed an in-place upgrade and only:
When immediate (on-the-fly) user data migration was temporarily halted as described in Chapter 5. If on-the-fly user data migration was not halted, you can skip this procedure.
After validating that your upgraded deployment is operating as expected and that no rollback to the earlier release is needed
Note:
If you roll back to an earlier release after performing activities here, any user data that has been migrated will not be reverted.In the following procedure you must reconfigure the attributes used for challenge and response at both the tab level and the object class level.
Note:
If you performed an upgrade using the zero downtime method, skip this activity.To restart on-the-fly user data migration
Tab Level: Reconfigure the Challenge and Response semantic types at the tab level, as follows:
Click Identity System Console, then click User Manager Configuration, click Tabs.
Select Employees from the list, then click Modify Attributes to open the Modify Attributes page.
From the Attribute list select the attribute that is used for Challenge, set the Semantic Type to Challenge and the Display Type to Single Line Text, then click Save.
From the Attribute list select the attribute that is used for Response, set the Semantic Type to Response and the Display Type to Password, then click Save.
Click Done.
Object Class Level: Reconfigure the Challenge and Response semantic types at the object class level, as follows:
Click Identity System Console, then click Common Configuration, click Object Classes.
Select the person object class from the list, then click Modify Attributes to open the Modify Attributes page.
From the Attribute list select the attribute that is used for Challenge, set the Semantic Type to Challenge and the Display Type to Single Line Text, then click Save.
From the Attribute list select the attribute that is used for Response, set the Semantic Type to Response and the Display Type to Password, then click Save.
Click Done.
Set the obVer attribute for oblixConfig (the configuration data root node in the LDAP directory server) to 10.1.4.0 as follows:
Note:
With Oracle Internet Directory, Oracle recommends that you set the LDAP_PASSWORD_PROMPTONLY variable to TRUE or 1 to disable the options -w password and -P password whenever possible, and use -q (or -Q), the command to prompt you for the user password (or wallet password.ldapmodify.exe -h <Host> \ -p <Port> -D <Bind DN> -q <Bind Password> \ -f <ldif file containing attribute to be modified>
The format of LDIF file to be created is as follows. This example is for the Netscape Directory Server:
dn: o=oblix,<configuration DN>
changetype: modify
replace: obver
obver: 10.1.4.0
Restart all upgraded Identity Servers and Access Servers.
Regardless of the method you used for the Access System upgrade, an administrator created a temporary directory profile to grant the Access Server write access to policy data stored in the directory server. This temporary directory profile was required when the Access Server gathered configuration information stored in the WebGatestatic.lst file and updated the directory server during WebGate upgrades.
Note:
Do not perform this task until all earlier WebGates in your environment have been upgraded and verified to be working.After upgrading all earlier WebGates and confirming proper operation of the upgraded WebGates, you can delete the temporary directory server profile.
To delete the temporary directory server profile
From the Access System Console, click the System Configuration tab.
Click Server Settings.
In the Configure LDAP Directory Server Profiles section, click the check box for the profile that you want to delete.
Click Delete.
When all earlier custom plug-ins and WebGates have been successfully upgraded and backward compatibility is no longer needed, proceed to "Reverting Backward Compatibility" next.
Regardless of the upgrade method that you used, backward compatibility with earlier custom plug-ins (and WebGates/AccessGates) was enabled automatically during earlier Identity Server and Access Server upgrades.
After upgrading all older plug-ins, WebGates and AccessGates, and confirming that the entire system upgrade has been successful, Oracle recommends that you disable (revert) backward compatibility.
The steps you complete to revert backward compatibility are similar to those used to manually enable backward compatibility. For more information, see:
After extending your custom Identity plug-ins to support UTF-8, you perform the steps in this procedure on every Identity Server in your environment whether backward compatibility was enabled automatically or manually.
To revert backward compatibility on Identity Servers
Upgrade all Identity System customizations as described in Chapter 12.
Redeploy all upgraded Identity System customizations and verify that all are working as expected.
Locate and open the Identity Server oblixpppcatalog.lst file in IdentityServer_install_dir\identity\oblix\apps\common\bin\oblixpppcatalog.lst.
Set the encoding flag from Latin-1 to encoding after the ApiVersion flag (if there is one) to provide backward compatibility for Latin-1 data. For example:
From:
userservcenter_view_pre;lib;;..\..\..\unsupported\ppp\ppp_dll\
ppp_dll.dll;Publisher_USC_PreProcessingTest_PPP_Automation;;Latin-1
To:
userservcenter_view_pre;lib;;..\..\..\unsupported\ppp\ppp_dll\
ppp_dll.dll;Publisher_USC_PreProcessingTest_PPP_Automation;;encoding
Repeat as needed for entries in this file.
Save the file.
Restart the Identity Server service.
Repeat for each Identity Server in the upgraded environment to revert backward compatibility.
After verifying that your custom Access System plug-ins were redesigned to support UTF-8, and after upgrading all WebGates/AccessGates successfully, backward compatibility is no longer needed. In this case, Oracle recommends that you manually set "IsBackwardCompatible" Value="false" in all Access Server globalparams.xml files.
Whether backward compatibility was enabled automatically or manually, you perform the steps in this procedure on every Access Server in your environment.
To revert backward compatibility on Access Servers
Upgrade all Access System customizations as described in Chapter 13.
Redeploy all upgraded Access System customizations and verify that all are working as expected.
Locate and open the Access Server globalparams.xml file in AccessServer_install_dir\access\oblix\apps\common\bin\globalparams.xml.
Set "IsBackwardCompatible" Value="false". For example:
<SimpleList
<NameValPair
ParamName="IsBackwardCompatible"
Value="false">
</NameValPair>
</SimpleList>
Save the file.
Restart the Access Server service.
Repeat for each Access Server in the upgraded environment.
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|