| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
| Oracle® Access Manager Upgrade Guide 10g (10.1.4.2.0) Part Number B32416-01 |
|
|
View PDF |
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. In addition to behavior and product changes for 10g (10.1.4.0.1), there are enhancements available with Release 10.1.4 Patch Set 1 (10.1.4.2.0). Unless explicitly stated, release 10g (10.1.4.0.1) and release 10g (10.1.4.2.0) operate in the same way. Behaviors that have not changed are, for the most part, not included in this chapter.
This chapter provides the following topic categories:
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".10g (10.1.4.0.1) refers to any Oracle Access Manager release in the 10.1.4 series, including base 10g (10.1.4.0.1) installations as well as those which include the 10.1.4.2.0 patch set. For a brief description of enhancements available in the latest patch set, see Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems.
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 are significant differences in support prior to release 7.0.4 and 10g (10.1.4.0.1).
For the latest support information, see details under the Certify tab on:
http://metalink.oracle.com
Navigate to MetaLink at https://metalink.oracle.com.
Log in to MetaLink as directed
Click the Certify tab.
Click View Certifications by Product
Select the Application Server option and click Submit.
Choose Oracle Identity Manager and click Submit.
Click Oracle Identity Management Certification Information 10g (10.1.4.0.1) (html) to display the Oracle Identity Management page.
Click the link for Section 6, "Oracle Access Manager Certification" to display the certification matrix.
For a quick reference table of components and third-party products that are no longer supported, see "Support Deprecated".
Oracle Access Manager 10g (10.1.4.0.1) is a major release, not a patch set. Oracle Access Manager 10g (10.1.4.0.1) is a patch set (also known as Release 10.1.4 Patch Set 1 (10.1.4.2.0)). A patch set is a mechanism for delivering fully tested and integrated product fixes.
Patch sets can include new functionality. For example, only Release 10.1.4 Patch Set 1 (10.1.4.2.0) provides the tools required for the zero downtime upgrade method. For more information about the enhancements available with 10g (10.1.4.2.0), see "Enhancements Available with Release 10.1.4 Patch Set 1 (10.1.4.2.0)".
Oracle recommends that you apply the latest patch set as described in Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems. However, before you do, review the following considerations:
When 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), the component instances are considered to be 10g (10.1.4.0.1). In this case you must remove Release 10.1.4 Patch Set 1 (10.1.4.2.0) before you can apply subsequent patch sets.
You can install fresh 10g (10.1.4.0.1) instances using 10g (10.1.4.0.1) packages, and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
When you upgrade to Oracle Access Manager 10g (10.1.4.0.1) using the in-place method, you can then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0). In this case, component instances are considered to be release 10g (10.1.4.0.1). Before installing future patch sets, you must remove Release 10.1.4 Patch Set 1 (10.1.4.2.0).
After an in-place upgrade, you can install fresh 10g (10.1.4.0.1) instances to expand the environment, and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
When you upgrade using the zero downtime upgrade method, you use tools available with Oracle Access Manager Release 10.1.4 Patch Set 1 (10.1.4.2.0). To obtain these tools, before the upgrade you will extract 10g (10.1.4.0.1) component libraries and files and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0). After the upgrade, instances are considered to be release 10g (10.1.4.2.0). As a result, you cannot remove Release 10.1.4 Patch Set 1 (10.1.4.2.0) before you apply subsequent patch sets.
Before a zero downtime upgrade, you can expand the environment by adding earlier instances and then upgrading as described in Part VI. However, you cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install a fresh instance.
For more information about what is included in Release 10.1.4 Patch Set 1 (10.1.4.2.0), see "Enhancements Available with Release 10.1.4 Patch Set 1 (10.1.4.2.0)".
The information in the following procedure explains how to obtain Release 10.1.4 Patch Set 1 (10.1.4.2.0). There might be a later patch set available. Oracle recommends that you always apply the latest patch set.
To obtain Release 10.1.4 Patch Set 1 (10.1.4.2.0)
Go to Oracle MetaLink Web site and obtain Release 10.1.4 Patch Set 1 (10.1.4.2.0), as follows:
Navigate to MetaLink at https://metalink.oracle.com.
Log in to MetaLink as directed.
Click the Patches & Updates tab.
Click Quick Links to the Latest Patchsets, Mini Packs, and Maintenance Packs
Double-click Oracle Oblix COREid, under the label "Latest Oracle Server/Tools Patchsets".
Locate and select the latest patch set for 10g (10.1.4.0.1) from the table at the bottom of the page. For example, select 5957301 to obtain Release 10.1.4 Patch Set 1 (10.1.4.2.0).
From the Platform or Language list, select the appropriate platform for your deployment and then click Download.
Use instructions in the Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems to prepare your environment before applying the patch set.
Use instructions in the Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems to apply Release 10.1.4 Patch Set 1 (10.1.4.2.0) to each 10g (10.1.4.0.1) component instance.
Perform any post application tasks that are in the Oracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0) For All Supported Operating Systems to ensure that your environment is operating properly.
Oracle recommends that you maintain an upgraded environment according to the conditions that apply to the upgrade method that was used in your environment. The following list explains the considerations:
Perform an in-place upgrade using 10g (10.1.4.0.1) packages and then apply Release 10.1.4 Patch Set 1 (10.1.4.2.0). To expand this environment after upgrading, you can add new 10g (10.1.4.0.1) instances and apply Release 10.1.4 Patch Set 1 (10.1.4.2.0).
Perform a zero downtime upgrade and expand the environment before upgrading by add earlier instances as described in Part VI. You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances. Adding 10g (10.1.4.0.1) packages and applying Release 10.1.4 Patch Set 1 (10.1.4.2.0) has implications for subsequent patches as described in "Obtaining the Latest Patch Set".
Backward compatibility with earlier plug-ins and most components is enabled automatically when you upgrade, regardless of the 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 Release 10.1.4 Patch Set 1 (10.1.4.2.0) 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.0.1) Access Server to an upgraded environment, you must set a flag to enable backward compatibility. You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances. Earlier Access Servers are not compatible with 10g (10.1.4.0.1) 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 Server Backward Compatibility |
|
|
Release 6.1.1, 6.5, and 7.x WebGates can coexist with upgraded 10g (10.1.4.0.1) 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. You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances. 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. |
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".
Table 4-2 Manual Tasks You Must Perform to Upgrade Customizations
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 about zero downtime upgrades, see Chapter 15.
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
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:
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 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.
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".
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.
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. 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 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 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 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 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).
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, you need to 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".
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 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.
Release 10.1.4 Patch Set 1 (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.
There are two possible values for MigrateUserDataTo1014the 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 in the following situations:
After 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). This results in an Oracle Access Manager 10g (10.1.4.0.1) instance of the component.
After you 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). This results in an Oracle Access Manager 10g (10.1.4.0.1) instance of the component.
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 10.1.4.2.0.
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 10.1.4.2.0 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.
Note:
OblixOrgPerson is one user object class; however, your deployment might include others. For example, your deployment might include both OblixOrgPerson and gensiteorgperson.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) 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".
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. This means that 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.
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.
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.
See Also:
Part VI, if you are using the zero downtime upgrade method.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.
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, 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.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.
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.
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".
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.
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.
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. The values XALAN or DGXT can be used 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
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 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. You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances.
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 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.
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 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".
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".
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.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 and is available with Release 10.1.4 Patch Set 1 (10.1.4.2.0).
See the chapter on Windows Impersonation in the Oracle Access Manager Integration Guide.
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.
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)".
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 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.
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".
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 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 can 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". You cannot use Release 10.1.4 Patch Set 1 (10.1.4.2.0) packages to install fresh instances.
Oracle Access Manager 10g (10.1.4.2.0) provides additional functionality to several key features. The following table provides a summary of the additional features that are available with 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 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. |
