This chapter provides a centralized summary of expected system behaviors and changes between Oracle Access Manager 10.1.4 and earlier releases. Unless explicitly stated, all 10.1.4 releases operate in the same way. Behaviors that have not changed are, for the most part, not included in this chapter.
Note: Unless explicitly stated, 10g (10.1.4.0.1) refers to any Oracle Access Manager release in the 10.1.4 series. This includes base 10g (10.1.4.0.1) and 10g (10.1.4.3) installations and the 10g (10.1.4.2.0) patch set. |
This chapter provides the following topic categories:
About Installers, Patch Sets, Bundle Patches, and Newly Certified Components
Enhancements Included from Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Note: For a quick reference table of Oracle Access Manager 10.1.4 behaviors (as well as an overview of new functions and features), see the Oracle Access Manager Introduction. See also "Product and Component Name Changes". |
There are no significant changes in platform support between releases 7.0.4 (also available as part of Oracle Application Server 10g Release 2 (10.1.2)) and 10.1.4. However, there are significant differences in support prior to release 7.0.4 and 10.1.4.
Note: Oracle COREid 7.0.4 is also available as part of Oracle Application Server 10g Release 2 (10.1.2). |
10g (10.1.4.3) SDK with .NET 1 Support: Oracle Access Manager software developer kit (SDK) for Windows continues to support .NET Framework 1.1 and Microsoft Visual Studio 2002. AccessGates created using this SDK will continue this support.
10g (10.1.4.3) SDK with .NET 2 Support: A new and optional SDK for Windows is also provided which supports .NET version 2 and MSDE Visual Studio 2005. This is specific to only custom AccessGates. This SDK can be added to your deployment whether it is a fresh installation or an upgraded environment that includes the 10g (10.1.4.3) patch.
See Also: |
Oracle continually certifies Oracle Access Manager support with various third-party platforms, Web server releases, directory server releases, and applications. Certain Web server-pecific packages will be available some time after the initial release.
See Also: "Web Server-Specific Installation Packages" in the Oracle Access Manager Installation Guide |
For the latest support details, see the certification matrix that is available on the Oracle Technology Network as described in the following procedure.
To locate the latest certification details
Go to Oracle Technology Network:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
Locate Oracle Identity and Access Management, and then click the link for the latest release. For example:
System Requirements and Supported Platforms for Oracle Access Manager 10gR3 (xls)
For a quick reference table of components and third-party products that are no longer supported, see the Oracle Access Manager Upgrade Guide.
This section includes the following sections:
Installers: Oracle provides installers for a fresh installation. With a major release, installation packages can also be used to upgrade earlier instances. For example, 10g (10.1.4.0.1) installers can be used for in-place component upgrades. However, 10g (10.1.4.3) installers can be used for only a fresh installation, not an upgrade.
Patch Sets: A patch set is a mechanism for delivering fully tested and integrated product fixes. Each patch set release updates specific software and configuration files in your installation. Patch sets can include new functionality.
Bundle Patches: A bundle patch is an official Oracle patch for Oracle Access Manager components on baseline platforms. Bundle patches are available following one release or patch set and before the next.
Newly Certified Components: Oracle provides Oracle Access Manager full installers and patch packages for components on newly certified platforms. These packages are available under the Oracle Access Manager 3rd Party Integration link on the Oracle Technology Network (OTN):
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
For more information, see "Package Types".
The required base release for 10g (10.1.4.3) is 10g (10.1.4.2.0). Oracle Access Manager 10g (10.1.4.3) packages cannot be used to upgrade an earlier Oracle Access Manager release. However, 10g (10.1.4.3) patch packages are available to apply to 10g (10.1.4.2.0) instances.
To upgrade earlier Oracle Access Manager instances (6.x or 7.x) to 10.1.4, you must use either:
In-Place Upgrade Method: 10g (10.1.4.0.1) installers must be used to perform an in-place component upgrade. After upgrading, you can apply the 10g (10.1.4.2.0) patch and then apply the 10g (10.1.4.3) patch.
or
Zero Downtime Method: 10g (10.1.4.2.0) packages provide the tools you need to perform a zero downtime upgrade. After upgrading you can apply the 10g (10.1.4.3) patch.
Note: Both 10g (10.1.4.0.1) installers and 10g (10.1.4.2.0) patch packages are required for the zero downtime upgrade method. |
For more information, see "Obtaining Packages for Upgrades".
The following procedure describes how to obtain the 10.1.4 installers and patch sets you need to upgrade an earlier Oracle Access Manager deployment. If you plan to use the in-place upgrade method, skip step 4.
To obtain the 10.1.4 base release and patch sets
10g (10.1.4.0.1) Packages for In-place and Zero Downtime Upgrade Methods:
Go to Oracle Technology Network at the following URL to download 10g (10.1.4.0.1):
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html
On the Oracle Identity Management 10g (10.1.4.0.1) Downloads page, click Oracle Access Manager Readme, and then review the contents of each CD on this page.
Core Components: In the Platform columns, click the links of appropriate CDs to download their contents.
Web Components: Locate and select Oracle Access Manager - 3rd Party Integration (Last updated ...) Readme; review the contents of each CD and click the links of appropriate CDs to download packages for WebGate, WebPass, Policy Manager, and Application Server Connectors.
Documentation: Perform the following steps to acquire 10g (10.1.4.0.1) manuals.
Go to the following URL:
http://www.oracle.com/technology/documentation/oim1014.html
In the table for Oracle Access Manager, locate part number B28196-01 (Oracle Identity Management 10g (10.1.4.0.1) Online Documentation Library), then click View Library or Download.
In the online documentation library, locate Release Notes.
Within the release notes, click the bookmark for Oracle Access Manager.
In-Place Component Upgrade: Use instructions in the Oracle Access Manager Upgrade Guide to upgrade earlier 6.x and 7.x instances in place.
10g (10.1.4.2.0) Packages for Zero Downtime Upgrades (or Patching): Perform Steps 1 and 2, and then perform remaining activities here:
Note: You cannot perform a zero downtime upgrade using 10g (10.1.4.3) packages. However, you need both 10g (10.1.4.0.1) and 10g (10.1.4.2.0) packages. |
Go to My Oracle Support (formerly MetaLink) and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter 5957301, and then click Go.
On the Patch 5957301 page, click the Download button beside each zip file name.
Readme: Click the View Readme button to display the Release Notes, which you can print to review the list of bugs fixed, enhancements, and more.
Documentation: Perform the following steps to acquire 10g (10.1.4.2.0) manuals.
Go to the following URL:
http://www.oracle.com/technology/documentation/oim1014.html
In the table for Oracle Access Manager, locate part number E10761-01 Oracle Access Manager (10g (10.1.4.2.0) Online Documentation Library), then click View Library or Download.
Proceed as follows, depending on your needs:
Zero-Downtime Upgrade: See Part VI, "Upgrading Using the Zero Downtime Upgrade Method" for details.
Patch Installation: See the Release Notes for all prerequisites, patch install, and post-patching instructions.
10g (10.1.4.3) Patch: Perform the following steps to acquire the 10g (10.1.4.3) patch packages.
Note: You cannot use 10g (10.1.4.3) packages for upgrades. |
Go to My Oracle Support (formerly MetaLink) and log in as usual:
http://metalink.oracle.com
From the Quick Find list, choose Patch Number, in the empty field to the right, enter Oracle Access Manager, and then click Go.
On the Patch 8276055 page, click the Download button beside each zip file name.
Readme: Click the View Readme button to display the Release Notes, which you can print to review the list of bugs fixed, enhancements, and more.
Patch Installation: See the 10g (10.1.4.3) Readme for all prerequisites, patch install, and post-patching instructions.
Documentation: Perform the following steps to acquire 10g (10.1.4.3) manuals.
Go to the following URL:
http://www.oracle.com/technology/documentation/oim1014.html
In the table for Oracle Access Manager, locate part number E15217-01 Oracle Access Manager (10g (10.1.4.3) Online Documentation Library, then click View Library or Download.
Oracle recommends that you maintain your upgraded environment according to the conditions for the upgrade method that was used:
In-Place Upgrades: After upgrading to 10g (10.1.4.0.1), apply the latest patch sets (10g (10.1.4.2.0) and then 10g (10.1.4.3)). After applying the patch sets, you can expand the environment by adding new 10g (10.1.4.3) instances.
Patch sets are available on My Oracle Support (formerly MetaLink). For more information, see Steps 5 and 7 in "Obtaining Packages for Upgrades"
Zero Downtime Upgrades: Oracle recommends that you expand the environment before upgrading with this method. Just add earlier instances as described in Part VI.
Note: You can expand an upgraded environment after applying the 10g (10.1.4.3) patch by using 10g (10.1.4.3) installers to add fresh instances. You cannot use patch set packages to install fresh instances. |
To add fresh instances, you must acquire 10g (10.1.4.3) installers from the Oracle Technology Network: http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
.
Backward compatibility with earlier plug-ins and most components is enabled automatically regardless of the upgrade method you use. However, not all components provide backward compatibility with earlier components. Table 4-1 provides an overview with pointers to additional information.
Table 4-1 Backward Compatibility for Oracle Access Manager Components
Component | Backward Compatibility Enabled Automatically | For More Information See |
---|---|---|
Identity Servers (formerly known as the NetPoint or COREid Server) |
When you upgrade Identity Servers, backward compatibility with earlier custom plug-ins is enabled automatically. If you add a 10g (10.1.4.0.1) Identity Server after an in-place upgrade, you must set a flag manually to enable backward compatibility with earlier custom plug-ins. You cannot use patch set packages to install fresh instances. Upgraded Identity Servers are not backward compatible with earlier WebPass instances. Identity Servers now use the value of the obVer attribute in OblixOrgPerson to support user data migration of multiple value in challenge and response attributes for Lost Password Management. |
Identity Server Backward Compatability |
After upgrading all earlier Identity Servers, you must upgrade all earlier WebPass instances. Earlier WebPass instances are not compatible with 10g (10.1.4.0.1) Identity Servers (or Policy Managers). You can install 10g (10.1.4.0.1) WebPass instances in your upgraded environment. However, 10g (10.1.4.0.1) WebPass instances are not compatible with earlier Identity Servers (or Policy Managers). You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances. |
Web Components and Backward Compatibility |
|
Policy Managers (formerly known as the Access Manager component) |
After upgrading the schema and data, and all Identity System components, you must upgrade all earlier Policy Managers. |
|
When you upgrade earlier Access Servers, backward compatibility with earlier custom plug-ins and earlier WebGates is enabled automatically. However, if you add a 10g (10.1.4.3) Access Server to an upgraded environment, you must set a flag to enable backward compatibility. You cannot use patch set packages to install fresh instances. Earlier Access Servers are not compatible with 10.1.4 WebGates. Access Servers now use the obVer attribute in OblixOrgPerson to support user data migration of multiple values in challenge and response attributes for Lost Password Management. Access Servers are compatible with custom AccessGates created using either. the SDK for NET 1 or the SDK with NET 2 support. |
Access Server Backward Compatibility Access Manager SDK in this table |
|
Release 6.1.1, 6.5, and 7.x WebGates can coexist with upgraded 10.1.4 Access Servers. If you add a 10g (10.1.4.0.1) Access Server to the upgraded environment, you must set a flag to enable backward compatibility with earlier WebGates. You can add 10g (10.1.4.3) WebGates to your upgraded environment. However, 10.1.4 WebGates are not compatible with earlier Access Servers. You cannot use patch set packages to install fresh instances. |
Access Server Backward Compatibility |
|
Release 10g (10.1.4.3) includes both:
|
"Recompiling Custom AccessGates for .NET 2 Support" |
Oracle Access Manager 10.1.4 retains customizations made in your earlier installation as described in "Preserved Items". However, in certain cases, you must perform manual tasks to upgrade or integrate customized items from your earlier environment into the upgraded environment, as outlined in Table 4-2. For more information, see "Customization Upgrade Planning".
Table 4-2 Manual Tasks You Must Perform to Upgrade Customizations
Only Oracle Access Manager 10g (10.1.4.0.1) provides a method to switch from a Solaris platform to a Linux platform while upgrading earlier releases (6.1.1, 6.5, or 7.x) to 10g (10.1.4.0.1). For more information, see Appendix B. After the upgrade you can apply the latest patch sets.
10g (10.1.4.2.0) Patch Set: Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides the tools required to perform a zero downtime upgrade while upgrading earlier releases (6.1.1, 6.5, or 7.x). For more information about zero downtime upgrades, see Chapter 15.
10g (10.1.4.3): This release provides a patch set that you can apply to 10g (10.1.4.2.0) instances. In addition, installation packages for a fresh 10g (10.1.4.3) installation are available on Oracle Technology Network (OTN). However, you cannot use 10g (10.1.4.3) installers to perform an upgrade.
In addition to the preceding tables, this chapter provides a consolidated and centralized summary of expected behaviors in Oracle Access Manager 10.1.4 so that you do not need to look through all the manuals to locate this information
Changes to the Oracle Access Manager schema are made periodically. Be sure to check the Oracle Access Manager Schema Description for any schema changes that were made between your starting release and the latest release. For example, new attributes and object classes might have been added to supoprt enhancements.
This discussion provides information about previous behaviors that apply equally to the Identity and Access Systems. The focus is on changes to previous behaviors and what to expect after upgrading to 10.1.4. Topics include:
This topic provides the following information:
Installers: Oracle provides installers for a fresh installation. With a major release (10g (10.1.4.0.1)), installers can also be used to upgrade earlier instances. However, you cannot use 10g (10.1.4.3) installation packages to upgrade an earlier Oracle Access Manager installation.
Patch Sets: A patch set is a mechanism for delivering fully tested and integrated product fixes. Each patch set release updates specific software and configuration files in your installation. Patch sets can include new functionality.
Bundle Patches: A bundle patch is an official Oracle patch for Oracle Access Manager components on baseline platforms. Bundle patches are available following one patch set release and before the next.
Newly Certified Components: Oracle provides Oracle Access Manager full installers and patch packages for components on newly certified platforms. These packages are available under the Oracle Access Manager 3rd Party Integration link on the Oracle Technology Network (OTN).
For more information, see the "About Installation Packages, Patch Sets, Bundle Patches, and Newly Certified Components" in the Oracle Access Manager Installation Guide.
The base release required for 10g (10.1.4.3) is 10g (10.1.4.2.0). Oracle Access Manager 10g (10.1.4.3) installers cannot be used to upgrade an earlier Oracle Access Manager release. The 10g (10.1.4.3) patch set can be applied to only 10g (10.1.4.2.0) instances.
To upgrade earlier Oracle Access Manager instances (6.x or 7.x) to 10.1.4, you must use either:
10g (10.1.4.0.1) installers available on OTN can be used to perform an in-place component upgrade. After upgrading, you can apply the 10g (10.1.4.2.0) patch and then apply the 10g (10.1.4.3) patch.
or
10g (10.1.4.2.0) packages available on My Oracle Support (formerly MetaLink) provide the tools you need to perform a zero downtime upgrade. After upgrading you can apply the 10g (10.1.4.3) patch.
For more information, see "Obtaining Packages for Upgrades".
Early product releases provided messages for end users and administrators in only the English language. Starting with release 6.5, support for translatable messages was provided through Language Packs for certain Latin-1 languages (French and German).
Oracle Access Manager 10.1.4 provides support for nearly a dozen Administrator languages and over two dozen end-user languages, as described in the Oracle Access Manager Introduction.
Oracle Access Manager 10g (10.1.4.3) provides new Lanauage Pack installers for use in either a fresh installation or an upgraded and patched deployment. Messages for minor releases (10g (10.1.4.2.0) and 10g (10.1.4.3) added as a result of new functionality might not be translated and can appear in only English.
Applying the 10g (10.1.4.3) Patch: After upgrading using either method described in this book, Oracle recommends that you remove (uninstall) existing 10g (10.1.4.0.1) Language Packs before you patch. After applying the 10g (10.1.4.3) patch, you can install 10g (10.1.4.3) Language Packs. If needed, you can reinstate a non-English default language. For details, see "Preparing Upgraded Environments for 10g (10.1.4.3) Language Packs".
Installing 10g (10.1.4.3): When installing 10g (10.1.4.3) components, you choose the language (locale) to be used as the default for Administrative tasks. Administrative information for the Identity System Console, Access System Console, and Policy Manager can be displayed in only installed Administrator languages. In earlier releases, a drop-down list of languages appeared in the top-right corner of the System Console. However, this is not available in 10.1.4. The only way to select the language is by changing the browser setting on the user's or administrator's computer. If administrative pages are requested in any user language (based on the language selected for the browser), the language that was selected as the default Administrator language during product installation (or upgrades) is used to display administrative pages. See the Oracle Access Manager Installation Guide for details about installing and enabling Language Packs.
Enabling Language Packs: After installing Oracle-provided Language Packs, you must enable all languages to be used, then configure Oracle Access Manager to use the installed languages by entering display names for attributes, tabs, and panels. See the Oracle Access Manager Identity and Common Administration Guide for details about enabling languages after installing.
Messages: Messages in Oracle Access Manager stylesheets depend upon a language. Beginning with release 6.5 multiple language capability, messages have been brought out of the stylesheets and defined separately as variables in msgctlg.xsl (and msgctlg.js for JavaScript files). In addition, each stylesheet has a corresponding language-specific thin wrapper stored in IdentityServer_install_dir\identity\oblix\lang\langTag\style0. Each wrapper in \style0 includes the main language-neutral stylesheet stored in IdentityServer_install_dir\identity\oblix\lang\shared. The purpose of this new thin wrapper is to segregate the main functionality of the stylesheet template, which is language independent, from language-specific messages in the stylesheets. For more information, see the Oracle Access Manager Customization Guide.
Note: While 10g (10.1.4.0.1) message files should work with10g (10.1.4.3) components, Oracle recommends that you upgrade older message files to 10g (10.1.4.3) when upgrading components. |
For more information, see "Console-based Command-line Interfaces".
The Crystal Reports package is no longer provided with the Oracle Access Manager package. You must obtain this product from the vendor.
Oracle Access Manager 10g (10.1.4.0.1) supports the Unicode standard. To support all the languages available with Oracle Access Manager 10g (10.1.4.0.1), the definitions of auditing and reporting tables have changed. Simply upgrading or altering existing database instances and tables is not supported and could result in permanent truncation and loss of existing data. For more information, see "Auditing and Access Reporting".
For the steps you must take to ensure a properly working auditing and reporting environment after upgrading Oracle Access Manager components to 10g (10.1.4.0.1), see auditing and access reporting topics in:
Also, when configuring Audit Policies in the Identity System Console, you can specify a list of profile attributes for every audit record. Profile attributes (Full Name, Employee Number, Department Number, and the like) are specific to the user performing the action/event being audited (Search or View Profile or Modify Profile, for example). The purpose of profile attributes is to help you identify the user performing the action/event.
WARNING: To avoid exposing a challenge phrase or response attribute, Oracle recommends that you do not select these as profile attributes for auditing. If you add a challenge phrase or response as a profile attribute, it is audited in proprietary encoded format. |
Using an enhancement in Release 10.1.4 Patch Set 1 (10.1.4.2.0), users can be logged in automatically after changing their password. To configure automatic login, the change password redirect URL must include STLogin=%applySTLogin%
as a parameter.The following is an example of a change password redirect URL that logs the user in:
/http://hostname:portnumber/identity/oblix/apps/lost_password_mgmt/bin/lost_password_mgmt.cgi? program=redirectforchangepwd&login=%login%%userid%&backURL=% HostTarget%%RESOURCE%&STLogin=%applySTLogin%&target=top
To implement this with a form-based authentication scheme, you must configure the challenge parameter creds
by supplying the user name credential parameter as the first token, the password credential parameter as the second token, then any other credential parameters.
See the Oracle Access Manager Identity and Common Administration Guide for details.
This has been removed due to an ldifde.exe tool licensing issue. For ADAM, the schema must be updated manually. For details, see the Oracle Access Manager Installation Guide.
When upgrading from releases earlier than 7.0, you might need to recompile C++ programs created with the Access Manager SDK and Oracle Access Manager APIs following the upgrade. For more information, see:
A 10g (10.1.4.0.1) Identity Server cannot flush the cache of an earlier Access Server. To eliminate any problems, be sure to upgrade your Access Servers to 10g (10.1.4.0.1).
For more information, see "Access Server Backward Compatibility".
Communication between a directory server and Oracle Access Manager Servers, and the Policy Manager can be either open (no security) or use the Secure Sockets Layer (SSL). SSL-enabled requires a signer's certificate (root certification Authority (CA) certificate) in Base64 format from a third-party Certificate Authority.
Three transport security modes are provided for communication between Web clients (WebPass and Identity Server and between Policy Manager and WebPass and between Access Server and WebGate. These security modes are Open, Simple (Oracle-provided), and Cert (third-party CA).
In both Simple and Cert mode, Oracle Access Manager components use X.509 digital certificates only. This includes Cert Authentication between WebGates and the Access Server where the standard cert-decode plug-in decodes the certificate and passes certificate information to the standard credential_mapping authentication plug-in.
Both Oracle and third-party vendors provide localized certificates for LDAP SSL communication between components and the directory server and for Oracle Access Manager components installed in Cert mode. With localization and UTF-8 support in 10g (10.1.4.0.1), you can request and add localized certificates containing non-ASCII text in all fields except Email and Country (according to x509 standards). After receiving a localized certificate, you must install it using one of the Oracle Access Manager command-line tools as described in the Oracle Access Manager Identity and Common Administration Guide. If the server is running a non-English operating system, you might want to set the Oracle National Language Support NLS_LANG or COREID_NLS_LANG environment variables (or both) to override the automatic server locale detection as described in the Oracle Access Manager Installation Guide. Setting these variables is optional because Oracle Access Manager automatically detects and uses the server locale.
Starting with Oracle Access Manager 7.0 (also available as part of Oracle Application Server 10g Release 2 (10.1.2)), the default certificate store format and name has changed from cert7.db to cert8.db for LDAP SSL certificates. When you upgrade to 10g (10.1.4.0.1), the old certificate store (cert7.db) is used. Oracle Access Manager 10g (10.1.4.0.1) works with both the cert7.db (upgraded environments) and cert8.db (new installations) certificate stores. You are not required to manually generate a new certificate store after upgrading. However, this will happen transparently whenever you add, modify, or delete certificates using configureAAAServer, setup_ois, or setup_accessmanager utilities that automatically modify the certificate store format and name to cert8.db.
For more information, see the Oracle Access Manager Identity and Common Administration Guide.
Starting with Oracle Access Manager release 7.0, components on Solaris and Linux are compiled using the GCC v3.3.2 C++ compiler to address multi-threading issues encountered with earlier compiler releases. As a result, after the upgrade you must recompile custom plug-ins from release 5.x or 6.x using GCC v3.3.2 C++ compiler. This includes Identity Event plug-ins and custom authentication and authorization plug-ins.
For more information, see:
WARNING: You must use the GCC v3.3.2 compiler, regardless of the compiler that might be provided with the Operating System. |
Previous versions of Oracle Access Manager managed certain information (including but not limited to directory connection information and WebGate parameters) solely through XML and LST configuration files. In 10g (10.1.4.0.1), Oracle Access Manager provides the ability to manage this information through the graphical user interface (GUI). See also "Directory Server Connection Details" and "WebGates".
Starting with Oracle Access Manager release 7.0, connection pooling was consolidated to support failover across the entire system. The directory connection pool does not depend on directory type.
There might be some impact when upgrading, depending on the earlier configuration of Oracle Access Manager to each directory server used:
Identity System Connection Pools: There is no impact. Initial Connections and Maximum Connections specified in the database instance profile are retained and will operate as they did previously.
Access System Connection Pools Before Release 6.5: Values for Initial Connections
and Maximum Connections
in the UserDB.lst and UserDBFailover.lst might not be retained. After upgrading Access System Components, it is a good idea to verify the values in the database instance profile of the newly created directory server profile.
On NDS: For concurrent authentication requests on NDS directory servers, Oracle recommends that you increase the connection pool size to something higher than the default (1) for the user directory profile using the System Console.
See also "Directory Server Failover".
Oracle Access Manager provides console-based command-line tools for administrators to configure Access and Identity components. 10.1.4 command-line tools automatically detect the server locale and use it for processing. You can optionally set either the COREID_NLS_LANG or NLS_LANG environment variables (or both), which toggle auto-detection off and take precedence over the server locale.
To ensure correct behavior of command-line interfaces with a non-English operating system, the Master Administrator must complete several tasks as described in the Oracle Access Manager Installation Guide.
Default product stylesheets are periodically updated by Oracle to instantiate improvements. Upgraded functionality depends, in part, on stylesheet files in the latest \style0 and \shared directories.
Customized .XSL style files, images, and JavaScript files are not migrated during the upgrade. If your earlier Oracle Access Manager installation includes customized images, JavaScript files, and stylesheets, you must complete manual processing to use these with 10g (10.1.4.0.1). If you use a style other than the Oracle Access Manager default Classic Style, you must manually include those changes in 10g (10.1.4.0.1) stylesheets, images, and JavaScript files.
Starting in Oracle Access Manager 6.5, you must reference images using the two variables ($gifPathName and jsPathName) to make your customization language and style independent.
Note: Any style directories created in the earlier installation are saved, not migrated, and are stored in the renamed (backup) source directory during the upgrade. After upgrading the Identity System, you must complete manual processing to use customized styles with 10g (10.1.4.0.1). See "Incorporating Customizations from Releases Earlier than 6.5". |
To support multiple languages, the location of java scripts, stylesheets, and images changed starting with Oracle Access Manager release 6.5. The directory structure introduced with release 6.5 continues with 10g (10.1.4.0.1).
Earlier releases used the Latin-1 character set. With 10g (10.1.4.0.1), Oracle Access Manager supports the Unicode character set and internationalized characters (Chinese, Japanese, Arabic, and the like).
In new installations, Oracle recommends that you choose a Unicode character set for your database. If you upgrade an earlier installation to 10g (10.1.4.0.1), be sure to change your database character set to Unicode.
In earlier releases with the Latin-1 character set, the varchar type for columns of audit and reporting related tables was sufficient. 10g (10.1.4.0.1), the audit record can contain data with non Latin-1 characters. For more information, see "Auditing and Access Reporting".
Formats differ between the Identity System and Access System, as follows:
Identity System: In the 10g (10.1.4.0.1) Identity System, the date format remains the same as in the last release and is not internationalized (on the Diagnostics page and Ticket Information page for example). However, month names taken from Identity System message catalogs will be displayed in the locale specified by the browser.
As in earlier releases, date order formats (MM/DD/YYYY versus /MM/YYYY and the like) can be configured by modifying object class attributes in the Identity System Console as described in the Oracle Access Manager Identity and Common Administration Guide. On the Ticket Information page, the date is displayed in the format specified in the obDateType
parameter in the globalparams.xml file. Weekday names do not appear anywhere within the Identity System.
Access System: In the 10g (10.1.4.0.1) Access System, month names, the date-order format (MM/DD/YYYY versus DD/MM/YYYY), and weekday names are displayed according to the locale specified for the browser. In the Access System, month and weekday names are not taken from message catalog files. The following information can vary from one locale to another:
Access System Date Format: In the Access System only, the date format is internationalized and will appear in the locale specified for the browser. In India, for example, the date format is typically expressed as DD/MM/YYYY. In the United States the date format is typically expressed as MM/DD/YYYY.
Access System Month Names: Earlier releases presented the names of months from language-specific message catalogs on the server. However, this meant that the user would see the month name in the server's locale. In the 10g (10.1.4.0.1) Access System, the name of the month will reflect the user's browser locale.
Note: Month names, and weekday names, (both full and abbreviated) have been removed from the globalmsg.xml file. Time zone locations have been removed from the oblixadminmsg.xml and policyservcenmsg.xml. These files are located in \AccessServer_install_dir\access\oblix\lang\en-us. |
Access System Weekday Names: In earlier releases, the names of weekdays (like the names of the month) were taken from language-specific message catalogs in the server's locale. In the Access System 10g (10.1.4.0.1), the name of the day will reflect the locale specified by the user's browser.
Access System Time Zone List: In earlier releases, the names of the location/city appeared with the Greenwich Mean Time (GMT) offset. However, the location/offset pair was not static because of the daylight savings time rule.
In 10g (10.1.4.0.1), the Time zone list shows only the offset expressed as Universal Time Coordinated (UTC) plus or minus from 00:00 to 12:00 hours. For example, UTC-00:00 or UTC+01:00 or UTC-03:30, and so on.
Note: Universal Time Coordinated (UTC) is also known as Coordinated Universal Time and sometimes as Universal Coordinated Time. All are abbreviated as UTC and refer to the standard time common to every place in the world (formerly and still widely referred to as Greenwich Mean Time (GMT) or World Time. UTC reflects the mean solar time along the Earth's prime meridian. The Time format remains the same as it was in the last release (7.0, also available as part of Oracle Application Server 10g Release 2 (10.1.2). |
You will see examples of these behaviors on the Access Server Diagnostics page; the Timing Conditions page under the Authorization Rules in access policies created in the Policy Manager; on the Manage Reports page under the System Management tab in the Access System Console; and the Manage Sync Records page under the System Management tab of the Access System Console.
With Oracle Access Manager 10g (10.1.4.0.1), there can be only one static HTML page at the address /identity/oblix/index.html and one static HTML page at the address /access/oblix/index.html.
These static product pages always use the default Administrator language selected during Identity Server and Access Server installation at this location. Starting with release 6.5, the product supported multiple Latin-1 languages (French, German). The default product page behavior remains the same as in previous releases.
See also "HTML Pages".
Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides enhancements for detecting and handling cross-site scripting and SQL injection. These enhancements guard against malicious data entry in the Oracle Access Manager user applications and administration consoles.
Release 10.1.4 Patch Set 1 (10.1.4.2.0) includes new diagnostic tools for the Identity and Access Server to help you work with an Oracle Technical Support representative to troubleshoot problems.
The diagnostic tools enable you to do the following:
Obtain hard-to-locate information about component configuration and behavior.
Automatically capture events that immediately precede a core dump.
Manually capture a stack trace of any event in the Identity or Access System.
See the Oracle Access Manager Identity and Common Administration Guide for details.
Starting with release 5.2, the Identity System included directory profiles and database instances. Starting with release 6.5, the Access System began partially using directory profiles and database instances for accessing user data. Directory profiles replace the UserDB.lst, GroupDB.lst, UserDBFailover.lst, and GroupDBFailover.lst configuration files that were used in earlier Access System releases.
A directory profile (also known as a directory server profile) contains the connection information for one or more directory servers that share the same namespace and operational requirements for Read, Write, Search, and so on. The connection information includes a name, a domain or namespace to which it applies, a directory type, and a set of operations.
Each directory profile can contain multiple primary/secondary "database instances". Each database instance profile represents connection information to and for a single directory server, including connection pool information.
A directory profile is created automatically each time you install an Identity Server, Policy Manager, or Access Server and specify new directory server connection information. You can create additional directory server profiles for load balancing and failover.
When you upgrade an earlier Policy Manager or Access Server, a message appears during the interval to release 6.5 informing you that a new directory profile was created. The message "DB Profiles created" refers to the directory server profile. During the creation of new Access System directory profiles, connection pool values from earlier configuration files cannot be retained. After the upgrade, Oracle recommends that you verify these values in the Database Instance profile of the newly created directory profile. See also "Connection Pool Details".
Previous versions of Oracle Access Manager managed directory connection information solely through XML configuration files. Recently, Oracle Access Manager provided the ability to manage this information through the interface using the Directory Profile page in the Identity System Console and the Access System Console. However, some configuration and policy data are still managed through the XML files. See also "Directory Profiles and Database Instance Profiles".
The Identity Server failover configuration has resided in the directory server profile in the System Console since release 5.2. Starting with release 6.5:
A directory server profile is created for the master directory server as well as any failover directory servers.
Directory server information from certain configuration files is used to create one Database Instance Profile each for all configured primary (and secondary) directory servers.
For example, during the incremental upgrade to release 6.5, directory profiles for the Access Server are automatically created and replace certain earlier configuration files where:
Primary directory server information was stored in:
AccessServer_install_dir/access/oblix/config/UserDB.lst and GroupDB.lst
Information for all the failover and load-balancing directory servers (primary and secondary) was stored in:
AccessServer_install_dir/access/oblix/config/UserDBFailover.lst
and GroupDBFailover.lst
When creating the directory server profile for the Policy Manager, directory server credentials are read from PolicyManager_install_dir/access/oblix/config/userDB.lst.
Note: If the configuration tree is in the user directory server and under the user node, then the configuration directory profile is not created. Otherwise, a configuration directory profile is created using directory server information from PolicyManager_install_dir/oblix/config/ldap/configdb.lst and marked for use only by the Policy Manager. |
Profiles are not created for Policy Manager failover servers. In the case of release 6.1, if the policy tree was on a separate directory server a profile for policy data existed.
The Access Server will handle multiple directory servers following data upgrades.
After upgrading, to verify that the failover configuration you had in the previous release operates as expected see:
Former .lst files are transformed into .xml files, as described in "Message and Parameter Files". See also "Connection Pool Details".
An enhancement with Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides a new parameter in globalparams.xml named LDAPOperationTimeout
sets an amount of time that the Identity Server, Access Server, or Policy Manager waits for a response from the directory server for a single entry of a search result before the component fails over to a secondary server, if one is configured.
A heartbeat_ldap_connection_timeout_in_millis
parameter in globalparams.xml determines the time limit for establishing a connection with the directory server. If the time limit is reached, the Identity and Access Servers start establishing connections with another directory server. This parameter enables the Identity and Access Servers to proactively identify when a directory server is down, and it enables failover without requiring an incoming directory service request and a subsequent TCP timeout.
See the chapter on failover in the Oracle Access Manager Deployment Guide and the appendix on parameter files in the Oracle Access Manager Identity Customization Guide for details.
The 10g (10.1.4.0.1) directory server interface reads, processes, and stores data in UTF-8 encoding. Earlier releases behaved in this same way. Therefore, there is no impact in upgraded environments. Oracle Access Manager used UTF-8 encoding for directory server communications even in earlier releases
Product releases before release 6.5 did not include any language directories, because English was the only language. When you install 10g (10.1.4.0.1) components, you can name the top-level directory as you like. During installation, Oracle Access Manager appends an identifier is appended to the directory name you assign to identify the type of components installed therein. For example, the top-level structure is:
OracleAccessManager\access: Created with the installation of the Access Server
OracleAccessManager\identity: Created with the installation of the Identity Server
OracleAccessManager\webcomponent: Created with the installation of Oracle Access Manager Web components (WebPass, Access Manager, WebGate)
Release 6.5 through 10g (10.1.4.0.1) installations provide a language directory containing a named subdirectory for each installed language (which contains .XML message catalog files for various applications that you can customize):
For more information, see Appendix A.
As in earlier releases of the product, 10g (10.1.4.0.1) supports ASCII characters for domain names and Uniform Resource Identifiers (URIs). The most common form of a URI is a Web page address (a subset of the URI is known as a Uniform Resource Locator or URL).
With Oracle Access Manager10g (10.1.4.0.1), there is no support for international characters in domain names (internationalized domain names) nor in the Uniform Resource Identifiers (internationalized resource identifiers) nor, by extension, in the URL.
Starting in Oracle Access Manager release 7, AES became the encryption scheme used by Access System components. The Identity System continues to use RC6 encryption for Lost Password Management responses.
The shared secret encryption algorithm is an Oracle Access Manager-wide setting that affects all encrypted cookies. For example, the ObSSOCookie cookie is encrypted using a configurable encryption key known as a shared secret.
For shared secret keys used in release 5.x, the RC4 encryption scheme was recommended.
For shared secret keys used in release 6.x, the RC6 encryption scheme was recommended. (RC6 encryption is deprecated in Oracle Access Manager 10g (10.1.4.0.1), and its support will be deprecated in future releases.)
AES is a new encryption scheme introduced in release 7.0 which continues in to 10g (10.1.4.0.1). AES is the default encryption scheme.
In environments that include earlier WebGates, the earliest encryption algorithm should be used.
For more information, see "Shared Secret" and details about setting encryption schemes in the Oracle Access Manager Access Administration Guide.
Oracle Access Manager release 7 introduced a heartbeat polling mechanism to facilitate immediate failover to a secondary directory server when the number of connections in the connection pool is less than the specified threshold level. Additionally, a failback mechanism facilitates switching from the secondary directory server back to the primary server as soon as the preferred connection has been recovered.
The heartbeat feature polls all the primary directory server connections periodically to verify the availability of the directory service (and by implication, the network). You configure the polling interval by setting the Sleep For (Seconds)
parameter for each Directory Profile in the System Console as described in the Oracle Access Manager Identity and Common Administration Guide.
When the host cannot be reached, further attempts to connect to that host are blocked for the specified the Sleep For
interval, rather than for the TCP timeout used previously.
A new heartbeat_ldap_connection_timeout_in_millis
parameter in globalparams.xml determines the timeout interval for establishing a connection. The default value for this parameter is 4000 (4 seconds). See the Oracle Access Manager Deployment Guide.
If the directory service is not available, the heartbeat mechanism immediately initiates failover to the secondary directory server. Thus, failover can take place without being triggered by an incoming directory service request and a subsequent TCP timeout.
In situations where the enterprise network performance is poor, the heartbeat feature can trigger false alarms and tear down already-established connections. Therefore, the heartbeat_enabled
parameter in the globalparams.xml files enables you to activate or deactivate the heartbeat mechanism in response to current network conditions. By default the heartbeat feature is activated.
As with earlier releases, only ASCII characters are supported in file and path names.
Note: Be sure that all file and path names include only English language characters. In file and path names, no international characters are allowed. |
A number of changes have been made to improve and clarify the Web-based graphical user interface. These changes are introduced in the Oracle Access Manager Introduction and are illustrated throughout the suite of manuals.
Each Identity System application, such as the User Manager, Group Manager, and Org Manager, generates HTML for each page within the application. Access System components, such as the Policy Manager and WebGate, generate HTML pages. In earlier releases, HTML pages were generated and displayed using a superset of the Latin-1 character set.
In 10g (10.1.4.0.1), all HTML pages generated by Oracle Access Manager use UTF-8 encoding. This encoding is communicated to Web browsers using the Content-Type HTTP header and META tags.
UTF-8 encoding is rendered correctly on all supported browsers with the Unicode version of the font to be used. For browser support, see the Oracle Access Manager Installation Guide.
Certain Web servers (Apache, for example) allow administrators to specify the default encoding using the Content-Type HTTP header. However if the Web server setting specifies a different character encoding, Oracle Access Manager HTML pages are displayed incorrectly.
Note: To prevent incorrect behavior, Oracle recommends disabling such Web server settings. |
See also, "Default Product Pages".
Oracle Access Manager 10g (10.1.4.3) provides installation packages that you can use for a fresh installation only. Do not use 10g (10.1.4.3) installers to upgrade an earlier Oracle Access Manager deployment.
Note: 10g (10.1.4.3) patch set packages that can be applied to 10g (10.1.4.2.0) instances are available on My Oracle Support (formerly Metalink), as described in "Packages for Upgrades". |
For more information, see the Oracle Access Manager Installation Guide.
Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides an enhancement in the form of ModifyLDAPBindPassword
. This command enables you to periodically update the LDAP bind password for the directory servers that communicate with Oracle Access Manager components in Oracle Access Manager configuration files.
Using the ModifyLDAPBindPassword
command, you can reset the LDAP bind password without restarting any servers or re-running setup.
See the chapter on reconfiguring the system in the Oracle Access Manager Deployment Guide for details.
Prior to release 6.5, Oracle Access Manager messages were controlled by an XML file for a specific application and stored in application specific directories. For example:
IdentityServer_install_dir/identity/oblix/apps/appname/bin/appnamemsg.xml
where IdentityServer_install_dir is the directory where the Identity Server is installed and appname matches a specific application, as follows:
groupservcenter--Group Manager
objservcenter--Organization Manager
In 10g (10.1.4.0.1), these message files now reside in language-specific directories. For example: IdentityServer_install_dir/identity/oblix/lang/langTag/oblixbasemsg.xml.
Earlier release also provided a mix of parameter and message catalogs in .xml and .lst (proprietary) format. For example, Access System and SNMP Agent messages and parameters were stored in .LST files. To accommodate translation, .lst files were converted to .xml.
During an upgrade to Oracle Access Manager10g (10.1.4.0.1), any customizing in earlier message and parameter catalogs is preserved automatically. Also, .lst files are converted to XML format.
Note: During the upgrade, messages are displayed in English. |
New installations of Oracle Access Manager 10g (10.1.4.0.1) include .xml parameter and message catalog files. The exception to this rule includes files that are used during an upgrade to Oracle Access Manager10g (10.1.4.0.1), such as ois_520_to_600_msg.lst, which remain in the proprietary .lst format. 10g (10.1.4.0.1) upgrade tools use .lst message and parameter catalogs.
Oracle Access Manager 10g (10.1.4.2.0) includes a new parameter in the globalparams.xml, file MigrateUserDataTo1014
. This parameter comes into play only when you upgrade using the zero downtime upgrade method described in Chapter 15. The parameter is used by the Identity Server and Access Server during a user's first login after upgrading using the zero downtime upgrade method.
This user data migration is also known as on-the-fly user data migration. This migration impacts the obVer attribute in user or person entries in the directory server (OblixOrgPerson). It also impacts the challenge and response attributes for Lost Password Management. Multiple values in challenge and response attributes were introduced with Oracle Access Manager 10g (10.1.4.0.1). No other user data attributes are migrated during a user's first login.
The MigrateUserDataTo1014
flag is not present in globalparams.xml until you have a 10g (10.1.4.2.0) or later instance. After 10g (10.1.4.2.0), there are two possible values for MigrateUserDataTo1014
in the globalparams.xml, file:
true
: A value of true enables the automatic migration of a user's Lost Password Management challenge parameters during their first login (whether a user or an administrator). The value is set to true
by default when you:
Install a fresh Oracle Access Manager 10g (10.1.4.0.1) instance and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Perform an in-place upgrade to Oracle Access Manager 10g (10.1.4.0.1) and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Install a fresh Oracle Access Manager 10g (10.1.4.3) instance.
false
: A value of false
halts the automatic migration of a user's Lost Password Management challenge parameters during their first login.
The value is set to false
by default only when you upgrade using the zero downtime upgrade method. During a zero downtime upgrade, you install Oracle Access Manager 10g (10.1.4.0.1) and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) before finishing the upgrade. As a result, components are upgraded to Oracle Access Manager 10g (10.1.4.2.0).
Note: After applying the 10g (10.1.4.3) patch,, the value for the MigrateUserDataTo1014 parameter is retained |
After finishing the zero downtime upgrade and validating that it is successful, you must change the MigrateUserDataTo1014
parameter value to true
in the globalparams.xml file of each 10.1.4.2.0 Identity Server and Access Server. Automatic propagation of changes to globalparams.xml is not provided. As mentioned in the first bullet, a value of true
starts the automatic migration of a user's Lost Password Management challenge parameters during their first login.
A globalparams.xml file is located in the following directories:
IdentityServer_install_dir/identity/oblix/apps/common/bin
WebPass_install_dir/Webcomponent/identity/oblix/apps/common/bin
PolicyManager_install_dir/Webcomponent/access/oblix/apps/common/bin
AccessServer_install_dir/access/oblix/apps/common/bin
Only the Identity Server and Access Server use the MigrateUserDataTo1014
parameter. In general, some parameters in the globalparams.xml file are the same for all components while other parameters are specific to only a few components. For more information about the content of the globalparams.xml file, see the Oracle Access Manager Customization Guide.
In earlier releases, you needed to enter at least three characters when performing a search in Identity System applications. In 10g (10.1.4.0.1) there is no minimum number of characters required. As in earlier releases, you can control the minimum number of characters that users must enter in the search field as described in Oracle Access Manager Customization Guide.
In earlier releases, the lost password management feature supported only a single challenge and a single response. The challenge phrase and response attribute in user entries contained only a single value. For example:
ChallengeAttribute: what is your name? ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the name)
In earlier releases, the obVer attribute in user or person entries in the directory server (OblixOrgPerson, for example) indicated the current release for informational purposes only.
Oracle Access Manager 10g (10.1.4.0.1) supports multiple values in challenge phrases and response attributes, and expects these in encoded format (with @n#
as a delimiter between multiple values). For example:
ChallengeAttribute: what is your name?@1#what is your school name?@2# ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the name@1#SGschool@2#) ChallengeAttribute: what is your name?@1# ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the name@1#)
Note: In the delimiter @n# between multiple values, n is the number of the challenge or response. With Oracle Access Manager 10g (10.1.4.0.1), even a single value for the challenge and response uses the encoded format. |
Oracle Access Manager 10g (10.1.4.0.1) uses the obVer attribute in the user entry (OblixOrgPerson) to indicate the encoding for challenge phrase and response attributes for lost password management. For more information, see "obVer Attribute Changes".
Some product and component names have changed as you will see after an installation or upgrade. During an upgrade, earlier product, component, and functions names are changed to the new name. For example, in 10g (10.1.4.0.1), the default Policy domains are Identity Domain and Access Domain and the default authentication schemes are Oracle Access and Identity, Oracle Access and Identity for AD Forest, and Anonymous. These new names replace earlier names during the upgrade.
Certain function names have revised to noun phrases the Access and Identity Systems as noun phrases. The AM Service State name has changed to Policy Manager API Support Mode. For more information, see "Product and Component Name Changes".
Any names assigned by an administrator during installation and configuration are retained during an upgrade (not changed). Therefore if you have named a service "COREid Identity Server" or "NetPoint Identity Server" these names will be the same in the upgraded environment. Your earlier authentication schemes and policy domains are also retained as is during the upgrade. See also "Preserved Items".
Before release 6.5, the namespaces for Policy data and user data stored in two separate directories had to be unique. During an upgrade to 10g (10.1.4.0.1) Oracle recommends that you confirm this uniqueness to ensure that multi-language capability can be enabled.
For more information, see "Configuring Unique Namespaces for Directory Connection Information".
Earlier releases of Oracle Access Manager for Linux used the LinuxThreads library only. Using LinuxThreads required that you set the environment variable LD_ASSUME_KERNEL, which is used by the dynamic linker to decide what implementation of libraries is used. When you set LD_ASSUME_KERNEL to 2.4.19 the libraries in /lib/i686 are used dynamically.
RedHat Linux v5 and later releases support only Native POSIX Thread Library (NPTL), not LinuxThreads. Oracle Access Manager 10g (10.1.4.3) is compliant with NPTL specifications and can use either Native POSIX Thread Library (NPTL) or LinuxThreads.
The default mode for Oracle Access Manager 10g (10.1.4.3) is LinuxThreads. To support the default, the start_ois_server and start_access_server scripts will start in LinuxThreads mode. In this case, the variable LD_ASSUME_KERNEL is automatically set to 2.4.19. The message "Using Linux Threading Library." appears in the console and in the server's oblog file.
To use NPTL, you must start the server with the start_ois_server_nptl (or restart_ois_server_nptl) and start_access_server_nptl (or restart_access_server_nptl) scripts (or restart the server with restart_ois_server_nptl or restart_access_server_nptl). In this case, the message "Using NPTL Threading Library." appears in the console and in the server's oblog file.
Note: On Linux, Oracle Access Manager Web components for Oracle HTTP Server 11g use only NPTL; you cannot use the LinuxThreads library. In this case, do not set the environment variable LD_ASSUME_KERNEL to 2.4.19. |
With NPTL, there is no requirement to manually set the environment variable LD_ASSUME_KERNEL to 2.4.19. Standard stop scripts and the following standard setup scripts will operate successfully: start_setup_ois, start_setup_webpass, start_setup_access_manager, start_configureAAAServer. However, you might need to remove the LD_ASSUME_KERNEL environment variable (or comment it out) from the start_snmp_agent script.
With NPTL, there is no impact on custom plug-ins and APIs that you have created for Oracle Access Manager. When upgrading, you must still recompile custom plug-ins from Oracle Access Manager 5.x or 6.x using the GCC v3.3.2 C++ compiler.
For the differences between NPTL and LinuxThreads, see http://www.kernel.org/doc/man-pages/online/pages/man7/pthreads.7.html
See Also: Oracle Access Manager Installation Guide
|
There have been several schema changes. For more information, see Oracle Access Manager Schema Description.
The obVer attribute identifies the current Oracle Access Manager release and is one of several attributes in the class description of many Oracle Access Manager schema objects. For example, the obVer attribute is part of oblixPanel, oblixConfig, oblixLocation, oblixMetaAttribute, oblixEnum, and OblixOrgPerson to name only a few.
Until release 10g (10.1.4.0.1), the obVer attribute was purely informational. However starting with release 10g (10.1.4.0.1), the obVer attribute is used by the Identity and Access Servers to support encoding of multiple values in challenge phrase and response attributes for lost password management. In this case, Oracle Access Manager 10g (10.1.4.0.1) reads the obVer attribute in:
oblixConfig class: The structural class defines the container node for the Oracle Access Manager configuration data.
In oblixConfig, the obVer attribute always exists and indicates the COREid or Oracle Access Manager release.
OblixOrgPerson class: The auxiliary class used for associating Oracle Access Manager person information with the class configured as the structural person object class.
In OblixOrgPerson obVer might or might not exist. When obVer does not exist in a user entry, the value is assumed to be less than 10.1.4.0.
Oracle Access Manager 10g (10.1.4.0.1) uses the obVer value in the OblixOrgPerson class in the following ways:
An obVer vale of less than 10.1.4.0 indicates that there is a single value for the challenge phrase and the response with no encoding. For example:
ChallengeAttribute: what is your name? ResponseAttribute: xxxxxxxx (encrypted form of Ramakrishna)
An obVer value of 10.1.4.0 or greater indicates that the challenge phrase and response attributes are encoded (with @n# as a delimiter between multiple values, where n is the number of the challenge or response). For example:
ChallengeAttribute: what is your name?@1#what is your school name?@2# ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the name@1#SGschool@2#) ChallengeAttribute: what is your name?@1# ResponseAttribute: xxxxxxxx (where xxxxxxxx is the encrypted form of the name@1#
When you upgrade from an earlier release to Oracle Access Manager 10g (10.1.4.0.1), configuration data stored in the oblix
tree is migrated automatically and the value of the obVer attribute is changed to 10.1.4.0. However, user data is not migrated until the first login following the upgrade. Instead, the obVer attribute value remains less than 10.1.4.0 in user data (in the OblixOrgPerson class). In this case, during the first login the user data is migrated and:
The existing challenge phrase and response values are encoded (@1# is appended to the existing values automatically).
The value of the obVer attribute in user data (the OblixOrgPerson class) is set to the value of the obVer attribute in migrated configuration data in the root node of the oblix
tree (oblixConfig).
Caution: The first time a user logs in after the upgrade to 10g (10.1.4.0.1), that user entry is migrated immediately. Any existing challenge and response values for that user are encoded (@1# is appended to the end) and the obVer attribute value is changed to 10.1.4.0. However if you restore your earlier release, the rollback process does not revert these changes. If you rollback to your previous release, the obVer value in the user entry in the OblixOrgPerson class remains 10.1.4.0 and challenge and response values remain encoded format. To temporarily stop the immediate migration of user data (also known as on-the-fly migration) during an in-place upgrade, see "Halting On-the-fly User Data Migration at First Login Temporarily". This is not needed during a zero downtime upgrade. |
For more information about multiple values in challenge phrase and response attributes, see "Multiple Values in Challenge Phrase and Response Attributes" .
This release contains password policy and password management enhancements. You can configure the minimum and maximum number of characters users can specify in a password. For lost password management, you can set multiple challenge-response pairs, create multiple style sheets, and configure other aspects of the user's lost password management experience. You can also redirect users back to the originally requested page after resetting a password. For more information, see the Oracle Access Manager Identity and Common Administration Guide.
Oracle Access Manager 10g (10.1.4.0.1) uses the value of the obVer attribute in the user entry (OblixOrgPerson) to indicate the encoding for challenge phrase and response attributes. This has implications when upgrading from an earlier release to Oracle Access Manager 10g (10.1.4.0.1).
In 10g (10.1.4.0.1), you can reconfigure the logging framework without restarting the servers. To do this an administrator must manually update the log configuration for each component:
Changes to logging parameters take effect within one minute, rather than requiring you to restart the server where the changes were made. For more information, see the Oracle Access Manager Identity and Common Administration Guide.
Oracle Access Manager handles sensitive information about users, which can include the user password, date of birth,security questions and answers for lost password requests ( a challenge response), and more. At certain logging levels, sensitive information might be captured and could be displayed in plain text. With Oracle Access Manager, you can enable secure logging and filter sensitive information in log files.
For more information, see the chapter on logging in the Oracle Access Manager Identity and Common Administration Guide.
There have been a number of changes in supported platforms and third-party versions. You can now locate complete platform support details on Oracle Technology Network at:
http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
When you configure SSL mode for the directory server, only server authentication is supported. Client certificates are not supported. Oracle Access Manager verifies the server certificate against the Root CA certificate that you imported during product setup. For more information, see the Oracle Access Manager Identity and Common Administration Guide.
Oracle Access Manager 10g (10.1.4.0.1) provides a method to switch from a Solaris platform to a Linux platform while upgrading earlier releases (6.1.1, 6.5, or 7.x) to 10g (10.1.4.0.1). For more information, see Appendix B.
Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides the tools required to perform a zero downtime upgrade. For more information on the zero downtime upgrade method, see Part VI.
Certain Web server-specific packages will not be available with the initial release of 10g (10.1.4.3), but will be available at a later date. For more information, see "Web Server-Specific Installation Packages" in the Oracle Access Manager Installation Guide.
Earlier WebPass instances are not compatible with 10g (10.1.4.0.1) Identity Servers (or Policy Managers). After upgrading all earlier Identity Servers, you must upgrade all earlier WebPass instances. The exception to this rule is when you upgrade the schema and data against the master Identity System that you add for this purpose. For more information about in-place upgrades, see Part II.
You can install 10g (10.1.4.0.1) WebPass instances in your upgraded environment. However, 10g (10.1.4.0.1) WebPass instances are not compatible with earlier Identity Servers (or Policy Managers). You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances.
Release 6.1.1, 6.5, and 7.x WebGates can coexist with upgraded Access Servers. You can install 10g (10.1.4.0.1) WebGates in your upgraded environment. However, 10g (10.1.4.0.1) WebGates are not compatible with earlier Access Servers. Fore more information, see "WebGates".
If you add a 10g (10.1.4.0.1) Access Server to the upgraded environment, you must set a flag to enable backward compatibility with earlier WebGates. For more information, see "Access Server Backward Compatibility".
Security-related changes have been implemented to ensure that sensitive data in the following directories cannot be viewed directly through a browser:
Configuration files from /access or /identity/oblix/config/*.*
Log files from /access or /identity/oblix/log/*.* directory
The importantnotes.txt file has been removed and the information that was in this file is now documented in an appendix in the Oracle Access Manager Installation Guide.
There have been no changes for globalization and UTF-8 support in any Web server configuration files.
An enhancement in Release 10.1.4 Patch Set 1 (10.1.4.2.0) enables Oracle Access Manager to write a stack trace to a log file when there is a core dump. To enable this functionality, you turn on logging at any minimal level. You can send the log file that contains the stack trace information to Oracle, along with a report of the problem.
See the appendix on troubleshooting in the Oracle Access Manager Identity and Common Administration Guide for details.
This discussion outlines the encoding schemes you will see in XML message and parameter catalog files and XSL stylesheet files, and what to specify if you customize these files. See also "Acquiring and Using Multiple Languages".
ISO-8859-1 Encoding: For pure English text, there is no difference between ISO-8859-1 encoding and UTF-8 encoding. For this reason, the encoding scheme for English language XML message and XSL files remains ISO-8859-1. The following example shows an XML message file (auditmsg.xml), from an English directory (\lang\en-us):
\IdentityServer_install_dir\identity\oblix\lang\en-us\auditmsg.xml
<?xml version="1.0" encoding="ISO-8859-1" ?> - <MessageCtlg xmlns="http://www.oblix.com" CtlgName="auditmsg"> ...
Note: XML files in earlier product releases might continue to specifyencoding="ISO-8859-1" , while earlier LST files that have been converted to XML use UTF-8 encoding. See also "Message and Parameter Files". |
The next example illustrates an XSL stylesheet wrapper (style.xsl), which is the same in all language directories: English \lang\en-us, or German \lang\de-de, or Japanese \lang\ja-jp, and so on). The only difference in these files is the language designation specified by the langtag item in the last line of this example, which will differ from language to language:
\IdentityServer_install_dir\identity\oblix\lang\langtag\style0\style.xsl
<?xml version="1.0" encoding="ISO-8859-1" ?>
- <!-- Copyright (c) 1996-2005, Oracle All Rights Reserved. -->
- <xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:oblix="http://www.oblix.com/">
<xsl:variable name="styleName">style0/</xsl:variable>
<xsl:variable name="localeName">langtag</xsl:variable>
...
UTF-8 Encoding: For non-English languages, XML message files have encoding set as UTF-8, because ISO-8859-1 encoding cannot represent all characters in all languages. The sample file shown next is from the German language directory \IdentityServer_install_dir\identity\oblix\lang\de-de\auditmsg.xml:
<?xml version="1.0" encoding="UTF-8" ?> - <MessageCtlg xmlns:oblix="http://www.oblix.com" CtlgName=""> <Message MsgTag="ExAuditInitHandler">ExçêpäìÖÑExç ÖççürrêdÖçç ìÑì ähêä AüdìäAü MÖdülêMÖ ìÑìäìàlìzàäìÖÑìÑìäì. ThêT êxçêpäìÖÑêxç säàçksä ìsì: %1.</Message> ...
Even within the English language directory (\lang\en-us) some files state UTF-8 encoding because this encoding scheme is universal. For example, the English version of data_types.xml is:
<?xml version="1.0" encoding="UTF-8" ?> <?xml version="1.0" encoding="UTF-8" ?> - <MessageCtlg xmlns="http://www.oblix.com" CtlgName="data_types.xml"> <Message MsgTag="OB_BIN">Binary</Message> <Message MsgTag="OB_DN">Distinguished Name</Message> <Message MsgTag="OB_TEL">Telephone</Message> ...
In other language directories, German for example, the same file appears as:
<?xml version="1.0" encoding="UTF-8" ?> - <MessageCtlg xmlns:oblix="http://www.oblix.com" CtlgName=""> <Message MsgTag="OB_BIN">BìÑàryBì</Message> <Message MsgTag="OB_DN">DìsäìÑgüìshêdDìsä NàmêN</Message> <Message MsgTag="OB_TEL">TêlêphÖÑêTêl</Message> ...
Note: When customizing XML and XSL files, you can choose eitherencoding="ISO-8859-1" or encoding="UTF-8" . In either case, the Oracle Access Manager XML parser reads the encoding tag in the file for correct processing. |
For more information about XSL stylesheets and wrapper files, see the Oracle Access Manager Customization Guide. See also, "XSLProcessor Parameter".
This discussion provides information about previous Identity System behaviors with a focus on changes and what to expect after upgrading to 10g (10.1.4.0.1). Topics include:
In earlier releases, the challenge phrase and response attributes were allowed on different panels of the User Profile page. In 10g (10.1.4.0.1), however, both the challenge phrase and response attributes must be on the same panel. In 10g (10.1.4.0.1), challenge phrases and responses are displayed one after the other even though these are not configured one after the other in the panel.
If a panel contains only the challenge attribute, it will be displayed in the User Profile page without a response. If the panel contains only the response (without the challenge attribute), the response will not be displayed in User Profile Page at all. For details about combining these on a single panel, see "Combining Challenge and Response Attributes on a Panel".
IdentityXML changes have also been made for this feature. For details, see the Oracle Access Manager Developer Guide.
You can add the SetContentLengthHeader
parameter to the WebPass globalparams.xml file. A value of true sets the "Content-length" header in the response coming from WebPass to its Web server. As a result, the Web server does not send the "Connection" header with the value "Close" in its response to the browse. For more information, see the chapter on parameters in the Oracle Access Manager Customization Guide.
Oracle Access Manager 10g (10.1.4.3) allows the addition of the UseDefaultOptionsForAllMails
parameter in the Identity Server globalparams.xml file. This parameter enables you to configure an email ID to be used to send all email notifications.
For more information about this parameter, see Parameter Reference" in Oracle Access Manager Customization Guide. For encoding formats, see "Mail Notification Enhancements".
Starting with 10g (10.1.4.0.1), the Identity Server uses UTF-8 encoding and plug-in data will contain UTF-8 data. Earlier plug-ins send and receive data in Latin-1 encoding.
When you upgrade earlier Identity Servers, backward compatibility with earlier custom plug-ins is enabled automatically. In this case, a new flag (encoding)
is added to the oblixpppcatalog.lst file automatically to ensure backward compatibility with earlier plug-ins. A backward-compatible Identity Server continues to send data to earlier plug-ins in Latin-1 encoding.
Caution: When you add a new 10g (10.1.4.0.1) Identity Server to an upgraded environment, you must manually edit IdentityServer_install_dir\identity\oblix\apps\common\bin\oblixpppcatalog.lst to enable communication with earlier plug-ins and interfaces that need backward compatibility for Latin-1 data. For details, see the Oracle Access Manager Installation Guide. You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances. |
For more information, see the discussion on backward compatibility in "Identity System Event Plug-ins", next. See also "Cache Flush". Upgraded Identity Servers are not backward compatible with earlier WebPass instances.
The Identity Event Plug-in API is a standard component installed with the Identity Server that enables you to extend base Identity System functionality by developing your own small applications (called actions) to perform custom business logic and integrate with external systems. The Identity System makes certain data available to the actions, which are then allowed to modify the data and influence the outcome of the event.
Starting with 10g (10.1.4.0.1), the Identity Server uses UTF-8 encoding; plug-in data will contain UTF-8 data. Also, on Solaris and Linux, plug-ins earlier than release 7.x must be re-compiled using the GCC v3.3.2 C++ compiler as described in "Plug-ins".
In earlier releases, data was sent to Identity Event plug-ins using Latin-1 encoding. In an upgraded environment, any earlier Identity Event plug-in still uses Latin-1 encoding. You might need to redesign earlier custom plug-ins to use UTF-8 encoding. In some cases, however, you might want 10g (10.1.4.0.1) Identity Servers to communicate with earlier plug-ins.
Backward compatibility with earlier Identity Event plug-ins is automatic when you upgrade an earlier Identity Server to 10g (10.1.4.0.1). During the upgrade, a new flag is added to the oblixpppcatalog.lst file (encoding)
. A backward-compatible Identity Server continues to send data to earlier plug-ins in Latin-1 encoding; earlier plug-ins receive and send data in Latin-1 encoding. There is no change in plug-in data encoding.
When you add a new 10g (10.1.4.0.1) Identity Server to an upgraded environment, you need manually set the encoding
flag in the Identity Server oblixpppcatalog.lst to enable communication with earlier plug-ins and interfaces.
The catalog is stored in IdentityServer_install_dir\oblix\apps\common\bin\oblixpppcatalog.lst. It contains event handler entries and their mapping to the various events. The format of the entries is:
actionName;exectype;netpointparam1,...;path;execparam,...;apiVersion;encoding;
The next sample line shown here illustrates how to use the encoding flag to enable backward compatibility with Latin-1 plug-ins:
userservcenter_view_post;lib;;..\..\..\unsupported\ppp\ppp_dll
\ppp_dll.dll;PostProcessingTest;Latin-1;
Note: In the catalog file, theencoding flag is similar to the apiVersion flag, which sets the version of the Event API to be used by the event handler. As described in the catalog file, you can use apiVersion to set backward compatibility for the Event API. For example, if apiVersion is set to preNP60 then the API format for versions prior to Oracle Access Manager v60 and Latin-1 encoding is used by default. In this case, setting the encoding flag is redundant. |
Common uses of the Identity Event Plug-in API include password validation, integration, and provisioning. For example, you can develop an event handler for password management events that use the Identity Event API and add this event handler to the Oracle Access Manager password policy function. Or, you can develop an event handler for the Enable step of each registration workflow instance to either update the remote database using the RDBMS vendor's API or to generate a unique string in the required format and pass it back to the Identity System to use as the uid attribute value. For details, see the Oracle Access Manager Developer Guide
An action is a unit of external logic (also known as an event handler) written by a developer and configured by an Oracle Access Manager administrator to execute in response to a particular event. Actions might perform their tasks without accessing external components, or use any available mechanism to access third-party applications and resources such as Web services, RDBMS services, and ERP applications. You connect actions to the event using the oblixpppcatalog.lst file. At startup the Identity Server reads the catalog, which identifies the events that have actions. When an event occurs, the server executes the associated action.
There are three types of actions with the Identity Event Plug-in API:
LIB Action: A function within a shared library (DLL on Windows systems) that the Identity Server calls. Once dynamically loaded, the action executes in the same process space as the Identity Server and has direct access through API functions to data objects held by the server. The Identity Server sends a C++ object containing plug-in data to the library.
MANAGEDLIB Action: A function for Windows systems only, written in any .NET language for which a Microsoft Intermediate Language (MIL) compiler exists. MIL instructions are compiled once into native machine instructions and stored in dynamic memory, then executed by the Microsoft .NET Common Language Runtime (CLR). MANAGEDLIB actions are similar to LIB actions with the benefits of managed code. The Identity Server sends a C++ object containing plug-in data to the library.
EXEC Action: A standalone executable program that run in their own process space. Communication with the Identity Server is limited to startup parameters and an XML stream for input, and an XML stream plus an exit status code for output. Actions can also use any other APIs, such as an LDAP Identity Event Plug-in.
An event is a state change within the Identity System. Examples of events include when a request is received and is about to be passed to an application (such as the User Manager view program), or results have been generated by an application (such as the Group Manager search program), or a user has entered a challenge response while attempting a password reset, or an attribute on a profile page for an application (such as the Organization Manager) has been modified, or a workflow ticket awaiting approval the by corporate IT group has been approved.
The most frequently used type of events are pre-processing and post-processing events, which are generated in pairs. Each application (User, Group, or Org Manager) contains a number of programs (view, search, and so on) that generate HTML for each page within the application. Each program recognizes the event pair. Pre-processing events are generated before the program begins to create the page and allows an event handler to work with a request before it reaches a program. The Post-processing event is generated after the program has created the page and before responding to the user with an HTML page. The post-processing event allows an event handler to work with the results of processing a request.
Rather than interacting with the application through a browser, you can write a program. IdentityXML provides a programmatic interface for carrying out the actions that a user can perform when accessing an Identity System application from a browser. IdentityXML enables you to process simple actions and multi-step workflows to change user, group, and organization object profiles. IdentityXML allows external applications to access Identity System functions.
Starting with release 6.5, certain syntax changes were made for IdentityXML requests. Earlier syntax should still operate without problem. For new syntax descriptions, see the Oracle Access Manager Developer Guide.
In 10g (10.1.4.0.1), UTF-8 encoding is used for XML pages, for SOAP/IdentityXML requests, and for Identity Event Plug-in data sent to executables. Earlier releases used ISO-8859-1 encoding (also known as Latin-1).
To provide backward compatibility, 10g (10.1.4.0.1) supports IdentityXML requests in both ISO-8859-1 encoding and UTF-8. For XML documents written to disk, both ISO-8859-1 and UTF-8 encoding are supported. IdentityXML responses are emitted in the same encoding format as the request. Therefore, when a request uses Latin-1 encoding (encoding="ISO-8859-1"
) the response uses Latin-1 encoding; when a request uses UTF-8 encoding, the response uses UTF-8 encoding.
Note: Oracle recommends that you useencoding="UTF-8 " in new 10g (10.1.4.0.1) installations. In upgraded environments, Oracle recommends that you use encoding="ISO-8859-1" for backward compatibility. |
If an IdentityXML request uses encoding="ISO-8859-1"
and the response to it contains any characters outside the Latin-1 character set, the response containing such characters is garbled. For example, when encoding="ISO-8859-1"
is used for the request and the response includes Japanese or Arabic characters, such characters in the response are garbled.
IdentityXML changes have also been made in 10g (10.1.4.0.1) to accommodate challenge and response phrase changes. For details, see the Oracle Access Manager Developer Guide.
Starting with Release 10.1.4 Patch Set 2 (10.1.4.3.0), IdentityXML requests for gathering the attribute list pertaining to modifing a profile (modifyUser, modifyGroup, and modifyObject), no longer depend on a panel in the Identity System.
For more information, see the IdentityXML chapter of the Oracle Access Manager Developer Guide
An applet is a small program that is sent to a user along with a Web page. Java applets perform interactive animations, immediate calculations, or other simple tasks without having to send a user request back to the server.
In earlier releases, the Identity System Console included a drop-down list that enumerated the languages that were installed and configured in the product. When the user changed the language in this list, applets and other pages would be rendered in the selected language. For example, a user working in an English locale could work with applets displayed in a European language simply by selecting the language in the drop-down list. This model worked well for only European languages.
With the introduction of multibyte languages, such as Japanese, the model has changed to ensure that multibyte characters are rendered correctly. The language list has been eliminated from the Identity System Console. A user working in an English locale cannot view applets in multibyte languages. To work with applets in a multibyte language, the locale on the user's computer must be set to the same language.
Note: There is a known limitation of Java applets in JDK1.1.7. Oracle Access Manager 10g (10.1.4.0.1), applets with non-ASCII data can only be displayed properly on computers running with a native encoded operating system. Setting browser encoding will not work. |
There are no JavaScript changes that impact the user experience.
Enhancements with Release 10.1.4 Patch Set 2 (10.1.4.3.0) enable you to set parameters in the groupdbparams.xml file to enhance performance during group evaluation by eliminating dynamic or nested groups when these are not used.
For more information, see the Parameters chapter in the Oracle Access Manager Customization Guide
With Release 10.1.4 Patch Set 1 (10.1.4.2.0), if a static group is too large (over 10,000 members, for example) you can modify the default evaluation method for the group using the LargeStaticGroups
parameter in globalparams.xml. For more information on this parameter, see the Oracle Access Manager Customization Guide.
If you use this feature, you must make appropriate changes in your Identity System configuration to ensure that subgroups of the modified group are still searched and evaluated as intended. See the chapter on performance tuning in the Oracle Access Manager Deployment Guide for details.
Identity Server sends notification mails for various functions, such as attribute modification, workflows, containment limit, and others. The formats that are available for mail include text only, rich HTML, and MHTML (MIME encapsulation of aggregate documents, such as HTML. Both asynchronous and synchronous modes are supported when sending mail. The Identity Server communicates directly with the mail server using the SMTP protocol.
Earlier releases used ISO-8859-1 (Latin-1) "Q" encoding for the header messages, which is a recommended standard when most of the characters to be encoded are in the ASCII character set. In 10g (10.1.4.0.1) uses UTF-8 "B" (Base64 encoding) encoding is used.
MIME headers for all non-MHTML mail message are set as follows:
MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; Content-Transfer-Encoding: 8bit
In previous releases, you needed to enter at least three characters when performing a search in Identity System applications (User Manager, Group Manager, and Organization Manager). In 10g (10.1.4.0.1) there is no minimum number of characters required. By default, you can enter no characters. As in previous releases, to help users narrow their search criteria you can control the minimum number of characters that users must enter in the search field by setting the searchStringMinimumLength
parameter in oblixadminparams.xml. See the Oracle Access Manager Customization Guide for details.
You can model your business processes in the Identity System using workflows. In earlier releases, you could use workflows to issue, revoke, and renew certificates. However, this is no longer supported.
The Oracle Identity Protocol (formerly known as the NetPoint or COREid Identity Protocol) facilitates communication between Identity Servers and associated WebPass instances. There are no changes in the protocol for globalization. See also "Oracle Access Protocol (OAP) Updates".
A number of new parameters are available for globalparams.xml:
Identity Server: you can use the UseDefaultOptionsForAllMails
parameter enables you to configure an email ID to be used to send all email notifications.
WebPass: You can add the SetContentLengthHeader
parameter to the WebPass globalparams.xml file. A value of true sets the "Content-length" header in the response coming from WebPass to its Web server. As a result, the Web server does not send the "Connection" header with the value "Close" in its response to the browse.
For more information, see the chapter on parameters in the Oracle Access Manager Customization Guide.
You can use the Identity System to define policies to constrain passwords. These policies are enforced at run time and include such items as:
Minimum password length
Minimum number of uppercase characters
Minimum number of lowercase characters
Minimum number of non-alphanumeric characters
and the like
In 10g (10.1.4.0.1), internationalized characters are supported in password policies.
In earlier releases, password policies worked only with Latin1 characters when enforcing policy constraints. There are no Password Management run-time changes.
A Web page address is commonly known as a Uniform Resource Locator (URL), which is a subset of the Uniform Resource Identifier (URI). The encoding of data in the query string of the URI has changed from Latin-1 (in earlier releases) to UTF-8 encoding in 10g (10.1.4.0.1).
In new 10g (10.1.4.0.1) installations, the change is transparent. However, earlier Portal Inserts in installations that have been upgraded to 10g (10.1.4.0.1) require modification. After upgrading the environment to 10g (10.1.4.0.1), you must change the encoding of the query string in earlier Portal Inserts from Latin-1 to UTF-8.
The HTTP standard does not provide any mechanism for a browser to specify the encoding of the query string. Oracle Access Manager 10g (10.1.4.0.1) cannot detect query string character encoding and assumes it to be UTF-8. The 10g (10.1.4.0.1) Identity Server cannot process Latin-1 data from earlier Portal Inserts.
Note: After upgrading the environment to 10g (10.1.4.0.1), you must change the encoding of the query string in earlier Portal Inserts from Latin-1 to UTF-8. |
Before release 6.5, the PresentationXML library was provided under two directories and distributed depending upon how the files were likely to be used. For example, stylesheets that define the default Oracle Access Manager Classic Style were maintained in flat files in the file system directory \IdentityServer_install_dir\identity\oblix\apps\AppName. Starting with release 6.5, and continuing through 10g (10.1.4.0.1), the PresentationXML library are now stored in different directories:
For more information, see "About Custom Items and Upgrades".
In the User Manager, Group Manager and Org. Manager, search results are sorted using a locale-based case insensitive method when you click the column heading (Full Name, for example) in the search results table.
Starting with 10g (10.1.4.3), in the Identity Server globalparams.xml file, you can use the negativeListForEntityAttributes parameter to identify specific attributes that will not be read or cached during view and modify profile operations. With IdentityXML, items in this list can only be read and cached.
For more information, see the Performance chapter, "Tuning the Internal DBAgent Cache", in the Oracle Access Manager Deployment Guide, and Parameters chapter, globalparams.xml table, in the Oracle Access Manager Customization Guide
Oracle Access Manager now provides sample code for implementing Web services using IdentityXML. For more information, see the Oracle Access Manager Developer Guide.
Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides an enhancement when using IdentityXML. With Release 10.1.4 Patch Set 1 (10.1.4.2.0), the XSLProcessor
parameter in the globalparams.xml file indicates the processor to use when generating the page. The only officially supported value, default
, indicates that the XDK processor should be used. You can use the values XALAN
or DGXT
for testing.
See the appendix on configuration parameters in the Oracle Access Manager Customization Guide for details. See also "XML Catalogs and XSL Stylesheet Encoding".
This discussion provides information about previous behaviors of the Access System. The focus is on what to expect after upgrading to 10g (10.1.4.0.1). Topics include:
Access Manager SDK, Access Manager API, and Custom AccessGates
Custom Authentication and Authorization Plug-ins and Interfaces
Error Handling for Message Channel Initialization During Cache Flush
Triggering Authentication Actions After the ObSSOCookie Is Set
In releases before 10g (10.1.4.0.1), cookie encryption and decryption was handled by WebGate/AccessGate. However, cookie encryption and decryption is now handled by the Access Server. For this reason, earlier Access Servers are not compatible with 10g (10.1.4.0.1) WebGates. See also "Encryption Schemes".
Starting with Oracle Access Manager 10g (10.1.4.0.1), the Access Server uses UTF-8 encoding and plug-in data will contain UTF-8 data. Earlier plug-ins send and receive data in Latin-1 encoding.
When you upgrade earlier Access Servers, backward compatibility with earlier custom plug-ins and earlier WebGates is enabled automatically. In this case, a new parameter "IsBackwardCompatible" Value="true
" is set in the Access Server globalparams.xml file automatically. This provides backward compatibility that enables the Access Server to continue to send (and receive) data to earlier custom authentication and authorization plug-ins in Latin-1 encoding (and earlier custom plug-ins will set data in Latin-1 encoding). In addition, the Access Server maintains backward compatibility with earlier WebGates and custom AccessGates that continue to encrypt/decrypt cookies
Caution: When you install a new instance of the latest Access Server in an upgraded environment, you must manually set " |
For more information, see "Custom Authentication and Authorization Plug-ins and Interfaces" and "Oracle Access Protocol (OAP) Updates".
The Access Manager SDK (formerly known as the Access Server SDK) is an optional component that provides documentation, resources, and code samples that you can use to construct simple custom AccessGate servlets or applications for each of the supported development platforms. AccessGates are Access Server clients (or agents) that process user requests for access to resources within the LDAP domain protected by Oracle Access Manager. The code for processing user requests can be embedded in a plug-in or written as a standalone application.
After installing the Access Manager SDK, you can use the Access Manager API (formerly known as the Access Server API) to write custom AccessGate code in any of the four supported development languages: Java, C and C++, and C# (.NET). The four implementations are functionally equivalent even though each takes advantage of platform-specific features to implement the API.
While you can select any of the four implementations as the development language interface you use to write your custom AccessGate code, your code will interact with underlying C++ binaries in the API, as described in the Oracle Access Manager Developer Guide.
When you develop custom AccessGates using the C and C++ Access Manager APIs, data is sent and received in UTF-8 encoding automatically. In earlier releases, data was sent and received in Latin-1 encoding.
For the C# (.NET) Managed Code implementation of the Access Manager API, there have been no external changes for 10.1.4. The C# .NET implementation internally uses UTF-16 encoding, which was converted to Latin-1 in earlier Oracle Access Manager releases. 10.1.4 Access Servers and C# AccessGates use UTF-8 encoding automatically.
For Java interfaces and the Java implementation of the Access Manager API, there have been no external changes for 10g (10.1.4.0.1). JNI calls use UTF-16 encoded Java string objects. Earlier Oracle Access Manager releases converted this data to Latin-1. 10.1.4 Access Servers and AccessGates use UTF-8 encoding automatically.
Note: The Access Manager SDK and custom AccessGates are not backward compatible with earlier Access Servers, nor with the earlier Access Manager SDK and AccessGates. However, you can use earlier AccessGates with 10.1.4 Access Servers that are enabled to be backward compatible. See also "Platform and SDK .NET Support" and "Oracle Access Protocol (OAP) Updates". |
Custom AccessGates (and WebGates) no longer perform cookie encryption and decryption. As a result, these components no longer need the shared secret key.
In Oracle Access Manager 10g (10.1.4.3), the software developer kit (SDK) supports NET Framework 1.1 and Microsoft Visual Studio 2002.
Oracle Access Manager 10g (10.1.4.3) also includes a new SDK for Windows, which provides .NET 2 support for custom AccessGates. This new SDK uses Microsoft Development Environment (MSDE) 2005, including NET Framework 2 and MSDE Visual Studio 2005.
The SDK for .NET 2 can be added to a fresh installation or to an upgraded installation that includes the 10g (10.1.4.3) patch. If you have earlier AccessGates created with the .NET 1 SDK and you start building AccessGates with the .NET 2 SDK, you might want to recompile the earlier AccessGates for .NET 2 Support.
In the Access Server globalparams.xml file, the splTimeout
parameter can be used to specify the time in seconds for Access Server cache flush operations in replicated environments. For more information, see the caching chapter of the Oracle Access Manager Deployment Guide.
See Also: The table on globalparams.xml in the chapter on parameters in the Oracle Access Manager Customization Guide |
Previous releases of Oracle Access Manager used a synchronous mode for cache flush requests from Identity Servers to Access Servers. In synchronous mode the Identity Server sends a cache flush request to the primary Access Server and the Identity Server does not proceed until it receives a response. However, any delay in the system causes a delay for the user.
Oracle Access Manager 10g (10.1.4.3) provides an asynchronous cache flush option to help streamline performance and avoid delays associated with synchronous cache flush operations on the Access System. The flow of information is the same whether you use the synchronous or asynchronous method. However, with the asynchronous method, the thread does not wait for a response from the Access Server before notifying the Identity Server. Instead, the request arrives at the Access Server and a response is sent immediately to the Identity Server.
Oracle Access Manager 10g (10.1.4.3) enhances the network layer shared by WebGate and Access Server. As a result, errors that might occur as a result of message channel initialization failure due to a closed socket are avoided. Today, the message channel stops sending and receiving messages and a WARNING level log message is recorded.
For more information, see the chapter on caching in the Oracle Access Manager Deployment Guide.
In 10g (10.1.4.0.1) it is no longer necessary to disable an authentication scheme before you modify it. Also, in 10g (10.1.4.0.1) you can configure an authentication scheme that allows the user to log in for a period of time rather than a single session.
In release 6.1.1, Authorization Rules were attached to particular access policies. Starting with release 6.5 (and later), Authorization rules are grouped under a different tab (named "Authorization Rules").
During an upgrade, the name of an Authorization Rule is shifted to the Authorization Rules tab. In addition, the name becomes a combination of the Policy name to which the rule belongs, followed by the Authorization Rule name: PolicyName_AuthorizationRuleName. For more information about recognizing and handling Authorization Rules after the upgrade, see "Associating Release 6.1.1 Authorization Rules with Access Policies".
Also, a new authorization inconclusive state was introduced in release 7.x (apart from authorization success and failure states). When your earlier installation included authorization failure redirects, you must complete a procedure after the upgrade to specify an explicit Deny rule and to change Allow takes precedence
to Yes
under the General tab of the authorization rule. For more information, see "Assuring Proper Authorization Failure Re-directs After Upgrading from 6.1.1". For details about the size of authorization expressions, see " "Large Authorization Expressions".
With 10g (10.1.4.0.1) there are some changes and backward compatibility, considerations as described here.
Authentication is the process of determining that a user trying to access a protected resource is who they say they are. Authorization is the process of determining that an authenticated user has access rights for the protected resource. The Access Server uses both authentication and authorization controls to limit access to resources that it protects, and provides defined interfaces that interact with authentication and authorization plug-ins.
You can either use standard authentication and authorization plug-ins or create your own custom plug-ins using the Oracle Access Manager Authentication Plug-In API and Authorization Plug-In API. Each custom plug-in implements the appropriate interface (authentication or authorization). Depending on the plug-in, the interface is activated to pass relevant information between the Access Server and the plug-in. Methods within the interface parse the data.
Before 10g (10.1.4.0.1), the Authentication Plug-In API and Authorization Plug-In API for C used Latin-1 encoding for data exchanged between the Access Server and the custom plug-ins. However, 10g (10.1.4.0.1) the Authentication Plug-In API and Authorization Plug-In API for C use UTF-8 encoding for plug-in processing.
There is no change for .NET (managed code) plug-ins, which continue to use the same API interface as in earlier releases of Oracle Access Manager.
You might need to redesign earlier custom plug-ins to use UTF-8 encoding. In some cases, however, you might want 10g (10.1.4.0.1) Access Servers to communicate with earlier plug-ins.
An earlier Access Server that is upgraded to 10g (10.1.4.0.1) provides backward compatibility automatically. However, when you add a new 10g (10.1.4.0.1) Access Server to an upgraded environment, you need manually set backward compatibility. For more information, see "Access Server Backward Compatibility".
This discussion provides an overview of authentication and authorization plug-ins in Oracle Access Manager.
Authentication is governed by authentication rules. Authentication rules use authenticating schemes; the schemes use one or more plug-ins to test the credentials provided by a user. Standard authentication plug-ins are provided as part of the Access Server installation or you can create your own custom plug-ins using the Authentication Plug-In API.
Authorization is governed by a policy domain that includes an authorization expression among a set of default rules that specify how resources for this domain are protected. Authorization rules are combined to create authorization expressions. When you create a rule, you include an authorization scheme in it. You can use the authorization scheme provided by the Access System or configure one or more custom ones schemes that include custom plug-ins created using the Authorization Plug-In API.
Release 6.5 introduced support for directory server profiles for the Access Server and Policy Manager. During a Policy Manager upgrade from any release before 7.x, a new directory server profile is added automatically. However, the values for Initial Connections
and Maximum Connections
are not retained during the Policy Manager upgrade
After upgrading, Oracle recommends that you verify and validate that new directory server profiles were properly created and that load-balancing and failover settings in Access System directory server profiles are configured as expected.
For more information, see "Directory Profiles and Database Instance Profiles". For more information about directory profiles, see "Error Handling for Message Channel Initialization During Cache Flush", in the Oracle Access Manager Deployment Guide, Chapter 5.
Oracle Access Manager 10g (10.1.4.3) allows you to add the DynamicGroupFilterMaxSize
parameter in the Access Server globalparams.xml file. This parameter enables a dynamic filter size when you have 4K of data or more. You add this parameter and value following an Access Server upgrade and after applying Release 10.1.4 Patch Set 2 (10.1.4.3.0). The group dynamic filter migrates automatically after updating the file.
For more information, see "Users Who Do Not Satisfy a Large Group Dynamic Filter Are Part of the Group" and the "Parameter Reference" in the Oracle Access Manager Customization Guide.
Oracle Access Manager 10g (10.1.4.3) enhances the network layer shared by WebGate and Access Server. As a result, errors that might occur as a result of message channel initialization failure due to a closed socket are avoided. Today, the message channel stops sending and receiving messages and a WARNING level log message is recorded.
For more information, see the section on "Rrror Handling for Message Channel Initialization During Cache Flush in the Oracle Access Manager Deployment Guide, Chapter 5.
Oracle Access Manager 10g (10.1.4.3) includes a new, optional, and configurable challenge parameter (maxpostdatabytes
) for form-based authentication schemes only. Use of the maxpostdatabytes
challenge parameter is similar to other challenge parameters (form, creds, action, and passthrough). For more information, see the Oracle Access Manager Access Administration Guide.
10.1.4 WebGates accept input data only in UTF-8 encoding. As a result, form-based authentication supports non-ASCII login credentials (username/password). When you use form-based authentication with 10.1.4 WebGates, you must ensure that character set encoding for the login form is set to UTF-8. To set the login form encoding to UTF-8 after an upgrade, see "Upgrading Forms-based Authentication".
Note: Basic Authentication fails with non-ASCII login credentials. Use form-based authentication for non-ASCII login credentials. Use Basic Authentication with ASCII login credentials. |
Any modification to a user profile or policy information is updated in the directory server. These modifications require an Access Server cache flush to ensure that authentication and authorization information is up to date. Enabling the Update Cache feature in Oracle Access Manager forces a cache flush every time an entry is written to the directory server. If you do not select Update Cache, the Access Server caches are updated when they time out and read new information from the directory server.
Before a cache flush, the Access Server checks the oblixGSN objectclass in the directory server, which is used in the cache flush mechanism. It contains a global sequence number (a value in the obSeqNo attribute) that represents the flush request number. This value is updated every time an entry is written to the directory server when the Update Cache feature is turned on, or on time out and read operations if the Update Cache feature is off The obSeqNo has a single unique value.
When you have multiple Access Servers writing to multiple directory servers, however, changes could cause the global sequence number in the directory servers to get out of sync. As a result, corresponding entries in the directory servers might become corrupted, which can lead to inconsistent performance in Oracle Access Manager. Recovey requires removal of corrupted entries from the directory server. A manual process is possible; however, it is error prone and time consuming.
Oracle Access Manager 10g (10.1.4.3) provides functionality that enables you to detect corrupted GSNs in the directory server from the command-line tool (recovergsncorruption) in the following path: PolicyManager_install_dir\access\oblix\tools. 10g (10.1.4.3) also provides functionality that enables you to recover from GSN corruption using functions in the Access System Console after disabling GSN updates by manually disabling the cache flush operation between all Identity Servers and Access Servers and blocking all updates from the Policy Manager and applications using AMAPI.
For more information, see the section on "Restoring Sync Records in Environments with Multiple Directory Servers" in the Oracle Access Manager Access Administration Guide.
In the Access Server globalparams.xml file, the UserMgmtNodeEnabled
parameter can be used. This parameter controls the enabling and disabling of a feature that manages WebGate memory growth. For more information, see the chapter on parameters in the Oracle Access Manager Customization Guide. See also, the tip on "Cache Flush Issues with Active Directory" in the Oracle Access Manager Access Administration Guide.
idleSessionTimeoutLogic
In release 7.0.4 WebGates enforce their own idle session timeout only. In 10g (10.1.4.0.1), behavior changed and WebGates enforced the most restrictive timeout value among all WebGates the token had visited. With 10g (10.1.4.3), the 7.0.4 behavior has been reinstated as the default. This 7.0.4 behavior can be reconfigured by setting a User-Defined Parameter (idleSessionTimeoutLogic
) in the AccessGate Configuration page of the Access System Console. Now WebGates enforce their own idle session timeout only, ignoring the MaxIdleSessionTimeout. For information on setting the idleSessionTimeoutLogic
configuration parameter, see "Configuring User-Defined AccessGate Parameters" in the Oracle Access Manager Access Administration Guide.
Oracle Access Manager supports Internet Protocol Version 4 (IPv4). However, you can configure Oracle Access Manager to work with clients that support IPv6 by setting up a reverse proxy server.
For more information, see the Oracle Access Manager Access Administration Guide.
Oracle Access Manager 10g (10.1.4.3) provides the policyDSMaxAttrValueLength
parameter in the globalparams.xml file of Access Server and Policy Manager. This parameter enables you to add large authorization expressions (beyond the directory server limit for non-binary attribute values). You might also need to configure the directory server to accept large attribute values. For more information, see "Parameter Reference" in Oracle Access Manager Customization Guide.
The following Access Sytem performance enhancements for large group evaluations are provided with Oracle Access Manager 10g (10.1.4.3):
Today, the Access Server (and Policy Manager when using the Access Tester) will evaluate the group for membership as a type, only if that type is enabled. To improve performance during group evaluations when you do not use dynamic groups, or when you have dynamic groups but do not want to evaluate them while processing ObMyGroups, you can turn off dynamic group evaluation using the TurnOffDynamicGroupEvaluation
parameter in the Access Server (or Policy Manager) globalparams.xml file.
Access Server v7.0.2 had the ability to disable nested group evaluatio using the TurnOffNestedGroupEvaluation
parameter in the Access Server globalparams.xml file.
See Also:
|
Today, retrieving all attributes except the disired attribute (uniquemember, groupfilter, and the like) depends on the LDAP query. Also, caching the whole entry has been disabled; only the attributes in the LDAP query are cached. In earlier releases the Access Server would read the whole group entry, including all attributes and cache the entry.
See Also: The topic, "Improving Performance of ObMyGroups Evaluations", in the chapter on performance in the Oracle Access Manager Deployment Guide |
Today, a new algorithm can be used during group evaluation involving ObMyGroups: TurnOffNewAlgorithmForObmyGroups
. This algorithm in the Access Server globalparams.xml file works equally when you have static, dynamic, and nested groups.
See Also:
|
Today, NestedQueryLDAPFilterSize
in the Access Server globalparams.xml file can be used if TurnOffNewAlgorithmForObmyGroups
is false
to improve evaluation performance of ObMyGroups. With this parameter, the LDAP search query is divided and then executed.
See Also:
|
The GroupCacheTimeout
parameter enables you to specify the amount of time an element will remain valid in the Access Server group cache. The parameter is provided in the Access Server globalparams.xml file (or the Policy Manager file if you are using the Access Tester).
See Also:
|
The GroupCacheMaxElement
parameter specifies the maximum number of elements that can be stored in the Access Server group cache. The parameter is provided in the Access Server globalparams.xml file (or the Policy Manager file if you are using the Access Tester).
See Also:
|
In earlier releases, the default value for this parameter was 100000. However, in Oracle Access Manager 10g (10.1.4.0.1), the default value has changed to 10000. You can find this parameter by navigating to the Access System Console, Access System Configuration tab, Access Server Configuration function. Look on the Details for Access Server page.
For more information, see the Oracle Access Manager Access Administration Guide.
Cache flush requests do not contain sensitive data. During cache flush operations, only the LDAP configuration is read. As a result, Open mode communication is appropriate for cache flush requests. Implementing automatic cache flush is a best practice, however, it can cause performance issues if you have multiple Access Servers that use a secure communication mode.
Oracle Access Manager 10g (10.1.4.2.0) provided a manual method that enabled you to use Open mode communication for cache flush requests between the Identity and Access Server while retaining Simple or Cert mode for all other requests. This type of configuration is known as mixed-security mode (or mixed-mode) communication. After configuring mixed security mode manually, you had to follow a specific method to modify an AccessGate or WebGate. Otherwise, WebGate could not contact the Access Server when running the configurewebgate
or configureaccessgate
tool. Specifically, when you attempted to modify an AccessGate or WebGate, all previous Preferred HTTP Host settings were removed.
Oracle Access Manager 10g (10.1.4.3) provides a streamlined method to implement automatic mixed-mode communication for cache flush requests. In the Access Server and Policy Manager globalparams.xml file, the setAccessFlushInOpenMode
parameter enables you to set the mode for cache flush operations.
For more information on both methods, see the caching chapter of the Oracle Access Manager Deployment Guide.
The Oracle Access Protocol (formerly known as the NetPoint or COREid Access Protocol) enables communication between Access System components during user authentication and authorization. WebGates and AccessGates store the user information required for authentication and authorization for example, (login name, password, headers, and the like). The data is serialized and sent to the Access Server where it is deserialized. The Access Server sends results back to the Access clients.
In earlier product releases, Latin-1 encoding was used for data as it was sent and received. In 10g (10.1.4.0.1), UTF-8 encoding is used. An updated Oracle Access Protocol is provided to accommodate both globalization and shared secret generation for 10g (10.1.4.0.1) Access Servers.
In new 10g (10.1.4.0.1) installations, you do not need to take any action. The latest version of Oracle Access Protocol is used for all communication between Access Servers and associated WebGates/AccessGates, as well as between Access Servers and new standard and custom authentication and authorization plug-ins.
In upgraded environments, Access Server backward compatibility is provided as discussed in "Access Server Backward Compatibility".
See also "Oracle Identity Protocol (OIP)".
OracleAS Web Cache is a reverse proxy cache and compression engine that is deployed between the browser and the Oracle Access Manager WebGate Web server.
POST Data Restoration: WebGate uses Web Cache to provide POST data restoration after the POST request is interrupted for re-authentication due to timeout. performance.
In earlier releases, WebGate did not store POST data if the POST request was interrupted by an authentication event (for example, a secure session time-out). However, with the integration of Web Cache and Oracle Access Manager, POST data is retained and WebGate can retrieve it after the user re-authenticates.
Cookieless Session Support: You can implement a cookie-less user session for Oracle Access Manager Single Sign-on and handle cookies with large data content on electronic devices.
For more information, see the Oracle Access Manager Integration Guide.
The primary purpose of impersonation is to trigger access checks against a client's identity. In a Windows environment, after a user authenticates, the authenticating application can impersonate that user's identity.
In addition to configuring impersonation for resources on a computer that is protected by a WebGate, you can extend impersonation to other resources on the network. This is known as assigning a Delegate impersonation level to the client . This function is available starting with 10g (10.1.4.2.0).
See the chapter on overriding Windows-enabled impersonation in the Oracle Access Manager Integration Guide.
After upgrading all Identity System components, you must upgrade all earlier Policy Managers (formerly known as the Access Manager component).
The Access System provides programmatic access to most of the functions provided by the Policy Manager graphical user interface (GUI). However, you can use the Policy Manager API (formerly known as the Access Management API) to create and manage policy domains and their contents or to allow custom applications to access the authentication, authorization, and auditing services of the Access Server. As in earlier releases, the 10g (10.1.4.0.1) Policy Manager API provides Java, C, and C# (.NET managed code) bindings for classes.
In earlier releases, ObAMMasterAuditRule_getEscapeCharacter
returned the audit escape character.
In Oracle Access Manager 10g (10.1.4.0.1):
In the C language API, the ObAMMasterAuditRule_getEscapeCharacter
remains and you can continue using this. However, the audit escape character must be an ASCII character; otherwise the return value is incorrect. In this case, you must modify your C code to use the new API.
On Java clients, the ObAMMasterAuditRule_getEscapeCharacter
works correctly and you can continue using this even when the audit escape character is not an ASCII character.
In the C language API, a new ObAMMasterAuditRule_getUTF8EscapeCharacter
has been added, which returns a pointer to the UTF-8 encoded audit escape character.
This WebGate configuration parameter is now mandatory and must be configured with an appropriate value whenever a WebGate is added (from the Access System Console, select Access System Configuration, Add New AccessGate). This must be done before WebGate installation.
The Preferred HTTP Host parameter defines how the host name appears in all HTTP requests as users attempt to access the protected Web server. the host name within the HTTP request is translated into the value entered into this field (regardless of the way the host name was defined in an HTTP request from a user). This safeguard prevents a hacker from constructing a malicious HTTP request that could bypass the WebGate. For more information, see the Oracle Access Manager Access Administration Guide.
New parameters can be added to Policy Manager globalparams.xml, that help monitor the Preferred HTTP Host field in a WebGate configuration in the Access System Console.
AllowEmptyPreferredHost
PreferredHostValidityCheckEnabled
See Also: Knowledge base article 416329.1 on My Oracle Support (formerly MetaLink) athttp://metalink.oracle.com . This note provides guidelines for deciding if you want to use the Preferred HTTP Host feature, and how to bypass it if you decide that enabling virtual hosting is more important in your environment than using the preferred host. |
A new parameter, AllowEmptyPreferredHost
, can be added to the Policy Manager globalparams.xml file, which allows you to leave empty the Preferred HTTP Host field in a WebGate configuration in the Access System Console.
For more information, see "Invalid or Missing Preferred HTTP Host Identifier in WebGate Profile" in the Oracle Access Manager Access Administration Guide. For parameter details, see the table on globalparams.xml in the chapter on parameters in the Oracle Access Manager Customization Guide.
PreferredHostValidityCheckEnabled
In the Policy Manager globalparams.xml file, you can use the PreferredHostValidityCheckEnabled
parameter to validate the value in the Preferred HTTP Host field of a WebGate profile.
For more information, see "Invalid or Missing Preferred HTTP Host Identifier in WebGate Profile" in the Oracle Access Manager Access Administration Guide. For parameter details, see the table on globalparams.xml in the chapter on parameters in the Oracle Access Manager Customization Guide.
In earlier releases, the shared secret was stored in the directory server and cookie encryption and decryption was accomplished by WebGates and custom AccessGates. In 10g (10.1.4.0.1), the shared secret remains in the directory server; however, cookie encryption and decryption is accomplished by the Access Server. As a result, WebGates and AccessGates no longer need the shared secret key.
If you change the shared secret during a user session, the user does not need to re-authenticate. If a cookie is being decrypted with the old shared secret and the cookie is refreshed, it is encrypted with the new shared secret. For more information, see the Oracle Access Manager Access Administration Guide.
For details about Access Servers, see "Access Server Backward Compatibility". For details about WebGates, see "WebGates". See also "Encryption Schemes".
Oracle Access Manager 10g (10.1.4.3) provides a new function that enables you to specify a wait period for sockets during synchronous cache flush requests between multiple Access Servers. In this case, the socket waits for only a specified time for I/O completion. If the expected operation is not completed within the specified time, an error is reported and the request is sent to other Access Servers. With synchronous requests, WebPass and Policy Manager will not hang if one Access Server hangs.
For more information, see "Configuring Sychronous Cache Flush Requests between Multiple Access Servers", in the Oracle Access Manager Deployment Guide, Chapter 5.
To specify a wait period for sockets during synchronous cache flush requests from the Access Manager SDK, you must add the CacheFlushTimeOut
parameter to the globalparams.xml file for each Access Server. For synchronous cache flush requests originating from the Policy Manager, you must add the CacheFlushTimeOut
parameter to the Policy Manager's globalparams.xml file.
For more information, see the table on globalparams.xml in the chapter on parameters in the Oracle Access Manager Customization Guide.
You can cause authentication actions to be executed after the ObSSOCookie is set. Typically, authentication actions are triggered after authentication has been processed and before the ObSSOCookie is set. However, in a complex environment, the ObSSOCookie might be set before a user is redirected to a page containing a resource. In this case, you can configure an authentication scheme to trigger these events. See also Oracle Access Manager Access Administration Guide.
Release 6.1.1, 6.5, and 7.x WebGates can coexist with upgraded Access Servers. You can install 10g (10.1.4.0.1) WebGates in your upgraded environment. However, 10g (10.1.4.0.1) WebGates are not compatible with earlier Access Servers.
The WebGateStatic.lst file available in earlier releases no longer exists. Instead, with 10g (10.1.4.0.1) WebGates you configure such parameters as IPValidation and IPValidationExceptions from the Access System Console, as described in the Oracle Access Manager Access Administration Guide.
In releases before 10g (10.1.4.0.1), cookie encryption and decryption was handled by WebGate/AccessGate. However starting with 10g (10.1.4.0.1), cookie encryption and decryption is now handled by the Access Server.
The code for WebGates has been rewritten so that 10.1.4 WebGates and AccessGates share the same code base. For more information, see the Oracle Access Manager Developer Guide.
Oracle recommends that you upgrade all earlier WebGates even though these can coexist with 10g (10.1.4.3) Access Servers. In environments that include a mix of WebGate releases, use the encryption scheme that corresponds to the earliest WebGate. For example:
Use RC4 as the encryption scheme if you have release 5.x and 10.1.4 WebGates co-existing in the same system.
Use RC6 as the encryption scheme if you have release 6.x and 10.1.4 WebGates co-existing in the same system.
Use the AES encryption scheme if you have only release 7.0 or 10.1.4 WebGates co-existing in the same system.
As discussed earlier, if you install a 10g (10.1.4.3) Access Server in an upgraded environment that includes earlier WebGates/AccessGates, you must manually configure the Access Server for backward compatibility. For more information, see "Access Server Backward Compatibility". You cannot use Release 10.1.4 Patch Set 2 (10.1.4.3.0) packages to install fresh instances.
Access Management Service Clarification
Several clarifications have been made with regard to the Access Management Service in WebGate and Access Server profiles. This setting is Off by default. When set to On, the Access Server starts servicing requests from AccessGates. The Access Management Service must be On for associated Access Servers and AccessGates. WebGates do not require the Access Management Service, unless an associated Access Server uses it.
For more information, see the chapter on configuring Access Servers and WebGates in the Oracle Access Manager Access Administration Guide.
User-defined Parameters in AccessGate Configuration Profiles
Several new user-defined parameters have been added for use in WebGate configuration profiles.
ContentLengthFor401Response
idleSessionTimeoutLogic
ProxySSLHeaderVar
RetainDownstreamPostData
SUN61HttpProtocolVersion
For more information, see the chapter on configuring Access Servers and WebGates in the Oracle Access Manager Access Administration Guide.
The following table provides a summary of the additional features that are included from Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Table 4-3 New Features with Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Feature Description | More Information |
---|---|
Documentation: Deployment overview and back up and recovery strategies |
A new chapter has been added to describe various deployment strategies and scenarios for Oracle Access Manager. For details, see the chapter on deployment scenarios in the Oracle Access Manager Deployment Guide. A new chapter has been added to outline various back up and recovery strategies for Oracle Access Manager installations. For details, see the chapter on back up and recovery strategies in the Oracle Access Manager Deployment Guide. |
Zero downtime upgrade method |
You can now perform an upgrade without shutting down service to your Oracle Access Manager customers. The zero downtime upgrade method is provided as an alternative to the in-place upgrade. Part VI describes how you can perform a zero downtime upgrade. |
Upgrade parameter to halt automatic user data migration using zero downtime method |
A new parameter in the globalparams.xml file, |
Upgrade while Switching from a Solaris platform to a Linux platform |
Appendix B explains how you can upgrade to 10g (10.1.4.0.1) while making a switch from a Solaris platform to a Linux platform. You cannot perform this task if you are using the zero downtime upgrade method. |
Functions for updating the LDAP bind password |
You may need to periodically update the LDAP bind password for the directory servers that communicate with Oracle Access Manager components. For example, you may want to update the LDAP bind password to comply with government regulations. Functionality for updating the LDAP bind password has been added in this release. See the Oracle Access Manager Deployment Guide for details. Note that in previous releases, after updating the LDAP bind password, it was necessary to re-run setup. In this release, it is no longer necessary to rerun setup. |
Assigning a Delegate impersonation level to the client |
In addition to configuring impersonation for resources on a computer that is protected by a WebGate, you can extend impersonation to other resources on the network. This is known as assigning a Delegate impersonation level to the client. See the chapter on Windows Impersonation in the Oracle Access Manager Integration Guide for details. |
New configuration parameters for IdentityXML |
When using IdentityXML, the See the appendix on configuration parameters in the Oracle Access Manager Customization Guide for details. |
Enhancements to xsl files |
Enhancements have been made to certain xsl files to support a JavaScript-related fix and a number of large-group-related fixes. These xsl files are available when you apply the 10g (10.1.4.2.0) patch set. For more information, see the Oracle Access Manager Customization Guide. For steps you must perform after applying Release 10.1.4 Patch Set 1 (10.1.4.2.0), see Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems. |
Log the time consumed by different types of calls to external components |
You can now generate logs that show details about the time consumed by different types of calls to external components. Using this information, you can better assess whether requests to specific components are taking longer than expected. For more information, see the Oracle Access Manager Identity and Common Administration Guide. |
Group performance is improved |
For large static groups, for example, groups with over 10,000 members, operations that involve the group can cause memory to spike. Group performance has been improved in this release. However, if you find that a large static group still affects performance, you can modify the default evaluation method for the group using the There are a number of additional actions that you can take to improve the performance of large groups. See the chapter on performance tuning in the Oracle Access Manager Deployment Guide for details. |
Oracle Instant Client binaries |
Oracle Instant Client binaries are now shipped with the Identity Server and Access Server. When auditing to a database, this eliminates the requirement for a 10.1.0.5 ORACLE_HOME on the computer that hosts them. |
NLS libraries and data files |
Even if an environment variable is set to ORACLE_HOME or ORA_NLS10, or a third-party Web component refers to a different version of the NLS libraries and data files than the one used by Oracle Access Manager, Oracle Access Manager components choose NLS data files from the oracle_access_manager_component_install_dir. For more information, see the Oracle Access Manager Installation Guide. |
Limit the number of retries that the WebGate performs for a non-responsive server |
A WebGate-to-Access Server timeout threshold specifies how long (in seconds) the WebGate waits for the Access Server to respond before it considers it unreachable and attempts the request on a new connection. However, if the Access Server takes longer to service a request than the value of the timeout threshold, the WebGate abandons the request and retries the request on a new connection. Note that the new connection that is returned from the connection pool can be to the same Access Server, depending on your connection pool settings. Additionally, other Access Servers may also take longer to process the request than the time allowed by the threshold. In these cases, the WebGate can continue to retry the request until the Access Servers are shut down. You can now configure a limit on the number of retries that the WebGate performs for a non-responsive server using the See the Oracle Access Manager Access Administration Guide for details. |
Preferred HTTP Host |
With Oracle Access Manager 10.1.4.0.1, the Preferred HTTP Host field became required. This introduced issues for environments that support virtual hosting. In 10g (10.1.4.2.0), to support virtual hosts you set the Preferred HTTP Host value to HOST_HTTP_HEADER for most Web hosts or SERVER_NAME (Apache only). Additional configuration is required for IIS. See the chapter on configuring Access Servers and AccessGates in the Oracle Access Manager Access Administration Guide for details. |
New diagnostic tools |
The Access Server and Identity Server have new diagnostic tools to help you work with an Oracle Technical Support representative to troubleshoot problems. The diagnostic tools enable you to do the following:
See the Oracle Access Manager Identity and Common Administration Guide for details. |
Log file enhancements |
Operating system error information is now included in the logs. For example, when an attempt to create a listener thread fails, the error code returned on GetLastError() is added to the log files. |
The webpass.xml file poll tracking refresh parameter is configurable |
When setting up multiple Identity Servers or modifying WebPass, administrators can now configure the PollTrackingRefreshInterval in the webpass.xml file. This interval should be configured in seconds. There are implications when setting up multiple Identity Servers or modifying a WebPass instance. See the Oracle Access Manager Identity and Common Administration Guide for details. |
Users can be logged in automatically after changing their password |
To configure automatic login, the change password redirect URL must include The following is an example of a change password redirect URL that logs the user in: /http://machinename:portnumber/identity/oblix/apps/lost_password_mgmt/bin/lost_password_mgmt.cgi? program=redirectforchangepwd&login=%login%%userid%&backURL=% HostTarget%%RESOURCE%&STLogin=%applySTLogin%&target=top To implement this with a form-based authentication scheme, you must configure the challenge parameter See the Oracle Access Manager Identity and Common Administration Guide for details. |
Write a stack trace to a log file |
If Oracle Access Manager experiences a core dump, it can now write a stack trace to a log file. To enable this functionality, you turn on logging at any minimal level. You can send the log file that contains the stack trace information to Oracle, along with a report of the problem. See the appendix on troubleshooting in the Oracle Access Manager Identity and Common Administration Guide for details. |
New parameters for directory server failover |
A new parameter in globalparams.xml named A See the chapter on failover in the Oracle Access Manager Deployment Guide and the appendix on parameter files in the Oracle Access Manager Customization Guide for details. |
Resetting the LDAP bind password in configuration files |
You may need to periodically update the LDAP bind password for the directory servers that communicate with Oracle Access Manager components. The See the chapter on reconfiguring the system in theOracle Access Manager Deployment Guide for details. |
Directory server searches are minimized for certain operations |
In previous releases, it could take a long time to create a large number of policy domains and URL prefixes in the Policy Manager. In this release, searches to the directory server have been minimized for these operations, resulting in better performance for these operations. |
Assigning a Delegate impersonation level to the client |
In addition to configuring impersonation for resources on the computer that is protected by a WebGate, you can extend impersonation to other resources on the network. This is known as assigning a Delegate impersonation level to the client. Note that the information on impersonation has moved from the Oracle Access Manager Access Administration Guide to the Oracle Access Manager Integration Guide See the chapter on configuring impersonation in the Oracle Access Manager Integration Guide for details. |
Release 10.1.4 Patch Set 1 (10.1.4.2.0): Integration support includes SharePoint Office Server 2007. See the chapter on integrating with SharePoint in the Oracle Access Manager Integration Guide for details. Integration support with SAP NetWeaver is provided. See the chapter on integrating with SAP in the Oracle Access Manager Integration Guide for details. Integration support with Siebel in a multi-domain Active Directory environment is provided. See the chapter on integrating with Siebel in the Oracle Access Manager Integration Guide for details. Integration support with Weblogic 9.2 is provided. See the chapter on integrating with WebLogic in the Oracle Access Manager Integration Guide for details. Integration support with WebSphere 6.1 is provided. See the chapter on integrating with WebSphere in the Oracle Access Manager Integration Guide for details. |