test

Sun Java System Access Manager 7.1 Release Notes

Access Manager 7.1 Patch 3

Access Manager 7.1 patch 3 fixes a number of problems, as listed in the README file included with the patch. Patch 3 also includes changes and known issues:

New Features and Changes in Access Manager 7.1 Patch 3

Sun Java System LDAP JDK Patches are Available

Check the Sun Java System LDAP JDK Patches section to determine if you need to apply these patches.

Running the updateschema Script is Required

Beginning with patch 3 (and any subsequent patches unless specifically noted), you must run the updateschema.sh script on Solaris and Linux systems or the updateschema.pl script on Windows. The updateschema script updates the Sun Java System Directory Server schema with any new attributes required by the patch.

Requirements for the updateschema.sh or updateschema.pl script include:

Access Manager 7.1 WAR File Deployment

To locate the updateschema script:

  1. After you unzip the 140504-05.zip file, unzip the AccessManager7_1Patch4.zip file.

  2. In the 140504-05/patch directory, unzip the AM7_1Patch4.zip file.

    The updateschema.sh and updateschema.bat scripts are in the 140504-05/patch/bin directory.

For an Access Manager 7.1 WAR file deployment, run the updateschema script after you add the patch. The script prompts you for paths to the following items:

Access Manager 7.1 Installer (Package-Based) Deployment

After you unzip the patchID.zip file, the updateschema.sh or updateschema.bat script is in the patchID directory, where patchID is 126356-05, 126357-05, 126358-05, or 126359-05, depending on your platform.

For an Access Manager 7.1 installer (package-based) deployment, run the updateschema script after you add the patch. The script prompts you for the same Directory Server information as requested for a WAR file deployment.

Limitation is Removed for Creation of Data Store Authentication Module Instance in Legacy Mode

Patch 3 removes the limitation for Creation of Data Store authentication module instance fails in Legacy mode (6764919).

In patch 2, the amadmin user was prevented from logging in to any authentication module other than the Data Store and Application authentication modules. CR 6811036 in patch 3 removes this restriction, but at the same time re-implements the original security fix to protect the authentication for the amadmin user, which is considered as a special or “internal” user.

An internal user such as amadmin must first authenticate internally to the OpenSSO configuration data store before it can authenticate to any authentication module. Hence you can login as amadmin to any authentication module only if you can first successfully authenticate to the configuration data store.

Note. Due to CR 6811036, if you log in as amadmin to the Access Manager Admin Console and provide an incorrect password, the “Your authentication module is denied' message will be displayed instead of “Authentication Failed” (which was displayed prior to patch 2).

Backward Compatibility Issue Between Access Manager 7.1 and amclientsdk.jar is Fixed

Patch 3 fixes the Backward compatibility issue between Access Manager 7.1 and amclientsdk.jar File (6754863). If you apply patch 3, the workaround documented for patch 2 is not needed.

Sun Java Web Console 3.1 Patches Are Required

The fix for CR 6804294 requires that the following Java Web Console 3.1 patches be applied:

These patches are available on SunSolve (http://sunsolve.sun.com/).

New Property Prevents Sessions From Being Destroyed After Session Upgrade

For a Distributed Authentication UI server deployment, Access Manager 7.1 patch 3 (CR 6700722) includes the new com.sun.identity.authentication.destroySessionAfterUpgrade property to prevent old sessions from being destroyed after a session upgrade. Values for this property can be:

Note. This new property applies only to a Distributed Authentication UI server and not to Access Manager 7.1 server.

To prevent sessions from being destroyed after a session upgrade:

  1. Add this new property with a value of false in the AMConfig.properties file. For example:

    com.sun.identity.authentication.destroySessionAfterUpgrade=false

  2. Restart the Distributed Authentication UI server.

New Property Allows SSO Token Restriction Other Than an IP Address

Access Manager 7.1 patch 3 (CR 6496155) includes the new com.iplanet.dpro.session.dnRestrictionOnly property to enforce the DN as the SSO token restriction rather then the IP address in cross-domain single sign-on (CDSSO) deployments and cookie-hijacking prevention mode. Values for this property can be:

Note: Older agents that use amclientsdk.jar from Access Manager 7 2005Q4 patch 5 and earlier should not set this property to true.

To require Access Manager 7.1 server to enforce that an agent send the DN as the SSO token restriction:

  1. Add this new property with a value of true in the AMConfig.properties file. For example:

    com.iplanet.dpro.session.dnRestrictionOnly=true

  2. Restart Access Manager 7.1 server.

Distributed Authentication UI Server Works With Basic Authentication

An Access Manager 7.1 patch 3 Distributed Authentication UI server now works with basic authentication (CR 6754852).

SecurID Authentication Support is Added for Linux Systems

Access Manager 7.1 patch 3 includes support for the SecurID authentication module on Linux systems (CR 6767780).

SecurID authentication support is also available on Solaris SPARC systems and Solaris x86 systems (since patch 2). See SecurID authentication is supported on Solaris x86 systems (6621802).

Known Issues in Access Manager 7.1 Patch 3

Single WAR Access Manager Deployment Cannot Use https Protocol Handler (6810092)

If Access Manager 7.1 patch 3 is deployed from a single WAR file, the https protocol handler cannot be used.

Workaround. None.

If config Directory Path on Windows Contains a Space, Patch 3 updateschema.pl Fails (6852463)

If Access Manager 7.1 patch 3 is deployed from a single WAR file on Windows, running the updateschma.pl script fails if the path to the config directory contains a space.

For example: c:\Documents and Settings\Administrator\AMConfig

Workaround. In the updateschema.pl file, add a double quote (") around the filename path in the following lines and then rerun the script:

$XMLFILE="$AM_ETCDIR/add_cert_org_serverconfig.xml";
$XMLFILE="$AM_ETCDIR/add_cert_org.xml";
$XMLFILE="$AM_ETCDIR/add_choice_none_org.xml";
$XMLFILE="$AM_ETCDIR/add_choice_none_org_serverconfig.xml";
$XMLFILE="$AM_ETCDIR/add_delegation_default_SubjectIdType.xml";
$XMLFILE="$AM_ETCDIR/add_auth_attr.xml";

For example:

$XMLFILE="\"$AM_ETCDIR/add_cert_org_serverconfig.xml\"";
$XMLFILE="\"$AM_ETCDIR/add_cert_org.xml\"";
$XMLFILE="\"$AM_ETCDIR/add_choice_none_org.xml\"";
$XMLFILE="\"$AM_ETCDIR/add_choice_none_org_serverconfig.xml\"";
$XMLFILE="\"$AM_ETCDIR/add_delegation_default_SubjectIdType.xml\"";
$XMLFILE="\"$AM_ETCDIR/add_auth_attr.xml\"";  Entry 1

Hard-coded Path Should be Removed from Patch 3 updateschema.pl Script on Windows (6852467)

If Access Manager 7.1 patch 3 is deployed from a single WAR file on Windows, running the updateschma.pl script fails because the path to the tools directory is hard-coded.

Workaround. Remove /amAdminTools from the following line of the updateschema.pl file and then rerun the script:

$AM_ADMIN_CMD="$WAR_TOOLS_DIR/amAdminTools/$DEPLOY_URI/bin/amadmin.bat";