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

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

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

4 System Behavior and Backward Compatibility

This chapter provides a centralized summary of expected system behaviors and changes between Oracle Access Manager 10g (10.1.4.0.1) and earlier releases. Behaviors that have not changed are, for the most part, not included in this chapter. Information is organized into the categories in the following list:


Note:

For a quick reference table of Oracle Access Manager 10g (10.1.4.0.1) behaviors (as well as an overview of new functions and features), see the Oracle Access Manager Introduction. See also "Product and Component Name Changes".

4.1 Platform Support

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 10g (10.1.4.0.1). However, there may significant differences between releases prior to 7.0.4 and 10g (10.1.4.0.1).

To ensure that you always have the most up to date information, support details are not presented in manuals. For the latest support information, see details under the Certify tab on:

https://metalink.oracle.com

To use MetaLink

  1. Navigate to https://metalink.oracle.com.

  2. Log in to MetaLink as directed.

  3. Click the Certify tab.

  4. Click View Certifications by Product.

  5. Select the Application Server option and click Submit.

  6. Choose Oracle Application Server and click Submit.

For a quick reference table of components and third-party products that are no longer supported, see "Support Deprecated".

4.2 About Upgrading and Backward Compatibility

Backward compatibility with earlier plug-ins and the like is enabled automatically when you upgrade components. However, not all components are backward compatible 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 to an upgraded environment, you must set a flag manually to enable backward compatibility with earlier custom plug-ins.

Upgraded Identity Servers are not backward compatible with earlier WebPass instances.

Identity Server Backward Compatability


WebPass

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 may 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).

"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.

Policy Manager


Access Servers

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.0.1) Access Server to an upgraded environment, you must set a flag to enable backward compatibility.

Earlier Access Servers are not compatible with 10g (10.1.4.0.1) WebGates.

Access Server Backward Compatibility

WebGates

Release 6.1.1, 6.5, and 7.x WebGates may coexist with upgraded 10g (10.1.4.0.1) Access Servers.

You may 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.

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.

WebGates

Access Server Backward Compatibility


Oracle Access Manager 10g (10.1.4.0.1) retains customizations made in your earlier installation as described in "Preserved Items". However, in certain cases, you need to 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".

In addition to the preceding tables, this chapter provides a consolidated and centralized summary of expected behaviors in Oracle Access Manager 10g (10.1.4.0.1) so that you do not need to look through all the manuals to locate this information.

4.3 General Behavior Changes

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 10g (10.1.4.0.1). Topics include:

4.3.1 Acquiring and Using Multiple Languages

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 10g (10.1.4.0.1) provides support for nearly a dozen Administrator languages and over two dozen end-user languages, as described in the Oracle Access Manager Introduction.

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 Installation Guide and Oracle Access Manager Identity and Common Administration Guide for details about installing and enabling multiple-languages after the upgrade.

When upgrading to (or installing) 10g (10.1.4.0.1), 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 10g (10.1.4.0.1). The only way to select the language is by changing the browser setting on the user's or administrator's machine. 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.

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.

For more information, see "Console-based Command-line Interfaces".

4.3.2 Auditing and Access Reporting

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 need to 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.


4.3.3 Automatic Schema Update Support for ADAM

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.

4.3.4 C++ Programs

When upgrading from releases earlier than 7.0, you may need to recompile C++ programs created with the Access Manager SDK and Oracle Access Manager APIs following the upgrade. For more information, see:

4.3.5 Cache Flush

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".

4.3.6 Certificate Store and Localized Certificates

Communication between a directory server and Oracle Access Manager Servers, and the Policy Manager may 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 may 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 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.

4.3.7 Compilers for Plug-ins

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. This means that 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 may be provided with the Operating System.


4.3.8 Configuration Files

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".

4.3.9 Connection Pool Details

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 may 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 may 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".

4.3.10 Console-based Command-line Interfaces

Oracle Access Manager provides console-based command-line tools that can be used by administrators to configure Access and Identity components. 10g (10.1.4.0.1) command-line tools automatically detect the server locale and use it for processing. You may 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.

4.3.11 Customized Styles, Images, and JavaScript

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 need to 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 need to manually include those changes in 10g (10.1.4.0.1) stylesheets, images, and JavaScript files.

Starting in Oracle Access Manager 6.5, you need to 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).

4.3.12 Database Input and Output

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 may contain data with non Latin-1 characters. For more information, see "Auditing and Access Reporting".

4.3.13 Date and Time Formats

Formats may 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 may 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.

4.3.14 Default Product Pages

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".

4.3.15 Directory Profiles and Database Instance Profiles

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 may not be retained. After the upgrade, you need to verify these values in the Database Instance profile of the newly created directory profile. See also "Connection Pool Details".

4.3.16 Directory Server Connection 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".

4.3.17 Directory Server Failover

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".

4.3.18 Directory Server Interface

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 because Oracle Access Manager used UTF-8 encoding for directory server communications even in earlier releases

4.3.19 Directory Structure

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 may customize):


IdentityServer_install_dir\identity\oblix\lang\en-us: English messages
IdentityServer_install_dir\identity\oblix\lang\fr-fr: French messages
IdentityServer_install_dir\identity\oblix\lang\shared: default global
stylesheets in all languages

For more information, see Appendix A, "Oracle Access Manager Directory Structure Changes".

4.3.20 Domain Names, URIs, and URLs

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.

4.3.21 Encryption Schemes

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.

4.3.22 Failover and Failback

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.

4.3.23 File and Path Names

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.

4.3.24 Graphical User Interface

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.

4.3.25 HTML Pages

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".

4.3.26 Message and Parameter Files

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

userservcenter--User 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 Manager10g (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.

4.3.27 Names Assigned by Administrators and Product Names

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".

4.3.28 Namespaces for Policy Data and User Data Stored Separately

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) you need to confirm this uniqueness to ensure that multi-language capability can be enabled.

For more information, see "Configuring Unique Namespaces for Directory Connection Information".

4.3.29 Reconfiguring the Logging Framework without a Restart

In 10g (10.1.4.0.1), you may reconfigure the logging framework without restarting the servers. To do this an administrator must manually update the log configuration for each component:


Identity Server
WebPass
Policy Manager
Access Server
WebGate

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.

4.3.30 Support Changes

There have been a number of changes in supported platforms and third-party versions. You can now locate complete platform support details under the Certify tab at https://metalink.oracle.com.

4.3.31 Transport Security for the Directory Server

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.

4.3.32 Web Components and Backward Compatibility

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, see Part II, "Upgrading the Schema and Data".

You may 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).

Release 6.1.1, 6.5, and 7.x WebGates may coexist with upgraded Access Servers. You may 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".

4.3.33 XML Catalogs and XSL Stylesheet Encoding

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 may continue to specify encoding="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> 
  ...

It is worth mentioning that 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 either encoding="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.

4.3.34 Web Server Configuration Files

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.

4.4 Identity System Behavior Changes

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:

4.4.1 Challenge and Response Attributes

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.

4.4.2 Identity Server Backward Compatability

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.


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.

4.4.3 Identity System Event Plug-ins

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".

4.4.3.1 Identity Event Plug-in Backward Compatibility

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 may need to redesign earlier custom plug-ins to use UTF-8 encoding. In some cases, however, you may 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, the encoding 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, apiVersion can be used 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.

4.4.3.2 Common Uses of the Identity Event Plug-in API

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

4.4.3.3 Identity Event Plug-in Action Types

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 may 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.

4.4.3.4 Identity Event Plug-in Event Types

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.

4.4.4 IdentityXML and SOAP Requests

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. However, IdentityXML responses are emitted in only UTF-8 encoding.

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.

4.4.5 Java Applets

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 machine 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 machines running with a native encoded operating system. Setting browser encoding will not work.

There are no JavaScript changes that impact the user experience.

4.4.6 Mail Notification Enhancements

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

4.4.7 Minimum Number of Search Characters

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.

4.4.8 Multi-Step Identity Workflow Engine

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.

4.4.9 Oracle Identity Protocol (OIP)

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".

4.4.10 Password Policies and Password Management Runtime Changes

You can use the Identity System to define policies to constrain passwords. These policies are enforced at runtime 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 runtime changes.

4.4.11 Portal Inserts and the URI Query String

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.

4.4.12 PresentationXML Directories

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:

IdentityServer_install_dir\identity\oblix\apps\AppName\bin
IdentityServer_install_dir\identity\oblix\lang\langTag
IdentityServer_install_dir\identity\oblix\lang\langTag\style0
IdentityServer_install_dir\identity\oblix\lang\shared
WebPass_install_dir\identity\oblix\lang\langTag
WebPass_install_dir\identity\oblix\lang\langTag\style0
WebPass_install_dir\identity\oblix\lang\shared
WebPass_install_dir\identity\oblix\WebServices\XMLSchema

For more information, see "About Custom Items and Upgrades".

4.4.13 Sorting User Search Results

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.

4.5 Access System Behavior Changes

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:

4.5.1 Access Server Backward Compatibility

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 add a new 10g (10.1.4.0.1) Access Server to an upgraded environment, you must manually set "IsBackwardCompatible" Value="true" in the new Access Server globalparams.xml to enable communication with earlier plug-ins and interfaces, as well as earlier WebGates and custom AccessGates. For details, see the Oracle Access Manager Installation Guide.


For more information, see "Custom Authentication and Authorization Plug-ins and Interfaces" and "Oracle Access Protocol (OAP) Updates".

4.5.2 Access Manager SDK, Access Manager API, and Custom AccessGates

The Access Manager SDK (formerly known as the Access Server SDK) is an optional component that provides all the documentation, resources, and code samples that you need 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 10g (10.1.4.0.1) 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 10g (10.1.4.0.1). The C# .NET implementation internally uses UTF-16 encoding, which was converted to Latin-1 in earlier Oracle Access Manager releases. 10g (10.1.4.0.1) 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. 10g (10.1.4.0.1) Access Servers and AccessGates use UTF-8 encoding automatically.


Note:

The 10g (10.1.4.0.1) Access Manager SDK and custom 10g (10.1.4.0.1) 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 10g (10.1.4.0.1) Access Servers that are enabled to be backward compatible. See also "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.

4.5.3 Authentication Scheme Updates

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.

4.5.4 Authorization Rules and Access Policies

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 need to 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".

4.5.5 Custom Authentication and Authorization Plug-ins and Interfaces

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.

4.5.5.1 Access Server Backward Compatibility

You may need to redesign earlier custom plug-ins to use UTF-8 encoding. In some cases, however, you may 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".

4.5.5.2 Authentication and Authorization Plug-ins Background

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.

4.5.6 Directory Profiles

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".

4.5.7 Forms-based Authentication

10g (10.1.4.0.1) WebGates accept input data only in UTF-8 encoding. As a result, in 10g (10.1.4.0.1), form-based authentication supports non-ASCII login credentials (username/password). When you use form-based authentication with 10g (10.1.4.0.1) 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.

4.5.8 Maximum Elements in Session Token Cache

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.

4.5.9 Oracle Access Protocol (OAP) Updates

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)".

4.5.10 Policy Manager

After upgrading all Identity System components, you must upgrade all earlier Policy Managers (formerly known as the Access Manager component).

4.5.11 Policy Manager API

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 may 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.

4.5.12 Preferred HTTP Host

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 hostname appears in all HTTP requests as users attempt to access the protected Web server. The hostname within the HTTP request is translated into the value entered into this field (regardless of the way the hostname 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.

4.5.13 Shared Secret

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".

4.5.14 Triggering Authentication Actions After the ObSSOCookie Is Set

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 may 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.

4.5.15 WebGates

Release 6.1.1, 6.5, and 7.x WebGates may coexist with upgraded Access Servers. You may 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 10g (10.1.4.0.1) 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 WebGate even though these may coexist with 10g (10.1.4.0.1) 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 10g (10.1.4.0.1) WebGates co-existing in the same system.

  • Use RC6 as the encryption scheme if you have release 6.x and 10g (10.1.4.0.1) WebGates co-existing in the same system.

  • Use the AES encryption scheme if you have only release 7.0 or 10g (10.1.4.0.1) WebGates co-existing in the same system.

As discussed earlier, if you install a 10g (10.1.4.0.1) 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".