Access Manager 7.1 Patch Releases

The latest revisions of the Access Manager 7.1 patches are available for download from My Oracle Support at https://support.oracle.com/.

The most recent patch IDs are:

• Solaris SPARC systems: 126356-06

• Solaris x86 systems: 126357-06

• Linux: 126358-06

• Windows: 126359-05

  Note: Patch 6 is not available for Windows.

• WAR file deployments (all platforms): 140504-06

Information about Access Manager 7.1 patches includes:

• Sun Java System LDAP JDK Patches

• Access Manager 7.1 Patch 6

• Access Manager 7.1 Patch 5

• Access Manager 7.1 Patch 4

• Access Manager 7.1 Patch 3

• Access Manager 7.1 Patch 2

• Access Manager 7.1 Patch 1

• Pre-Installation Considerations

• Patch Installation Instructions

• Access Manager 7.1 Patch 1 Single WAR Deployment

Sun Java System LDAP JDK Patches

Sun provides the following LDAP JDK patches for security and performance related fixes:

• Solaris SPARC and x86 systems: 119725

• Linux: 120834

• Windows (and platforms other than Solaris and Linux systems): 138905

Check My Oracle Support (https://support.oracle.com/) for the latest version of these patches.

Access Manager 7.1 Patch 6

Access Manager 7.1 patch 6 fixes a number of problems, as listed in the README file included with the patch. For a list of the supported platforms and patch IDs for patch 6, see Access Manager 7.1 Patch Releases. Information about this patch includes the following item:

Access Manager 7.1 Patch 6 WAR File Issue on GlassFish 2.2.x (13730542)

To run Access Manager 7.1 patch 6 in a GlassFish 2.1.x web container with an external directory server using LDAPS with JDK 1.6.x, set the NSS_USE_DECODED_CKA_EC_POINT environment variable to 1 before you start the GlassFish 2.1.x domain. For example:

NSS_USE_DECODED_CKA_EC_POINT=1
export NSS_USE_DECODED_CKA_EC_POINT

After you set this variable, restart the GlassFish 2.1.x web container.

Access Manager 7.1 Patch 5

Access Manager 7.1 patch 5 fixes a number of problems, as listed in the README file included with the patch. For a list of the patch IDs, see Access Manager 7.1 Patch Releases. Patch 5 also includes the following new features and changes:

• Time to Live (TTL) is implemented for the Service Management (SMS) cache (6973683)

• Retry mechanism is implemented in the PLL server (6963531)

• Access Manager 7.1 patch Readme lists the required LDAP JDK patches (6959325)

• HttpServletRequest and HttpServletResponse are available with Distributed Authentication User Interface (6677966)

Time to Live (TTL) is implemented for the Service Management (SMS) cache (6973683)

Patch 5 includes the following new properties to implement the TTL for the SMS cache. The TTL is the period of time before data in the SMS cache is discarded.

• com.sun.identity.sm.cache.ttl.enable enables the TTL function for the SMS cache, if set to true.

• com.sun.identity.sm.cache.ttl specifies the time in minutes before data in the cache is discarded. The default is 30 minutes.

To use these new properties, add them with appropriate values to the AMConfig.properties file and then restart the Access Manager web container.

Retry mechanism is implemented in the PLL server (6963531)

Patch 5 includes the following new properties to implement the retry mechanism in the PLL server:

• com.sun.identity.notification.retry.limit enables the Access Manager 7.1 server to repeat sending notifications until the notification is delivered successfully. The default is 3 retries, if the value is set to any nonnumeric character. A value of 0 (zero) specifies that no retries are sent.

• com.sun.identity.notification.retry.interval species the time interval in milliseconds between re-sending the retries, if com.sun.identity.notification.retry.limit is set to a nonnumeric character (or not set). The default is 500 milliseconds.

To use these new properties, add them with appropriate values to the AMConfig.properties file and then restart the Access Manager web container.

Access Manager 7.1 patch Readme lists the required LDAP JDK patches (6959325)

The Access Manager 7.1 Readme file included with the patch now lists the required LDAP JDK patches. For more information, see the patch 5 Readme file.

HttpServletRequest and HttpServletResponse are available with Distributed Authentication User Interface (6677966)

Patch 5 allows you to access the HttpServletRequest object and modify the HttpServletResponse object through a custom authentication module for Access Manager 7.1 server deployments with the Distributed Authentication User Interface (DAUI), as well as for Access Manager 7.1 server deployments without the DAUI.

To use this new feature, you must modify your existing custom authentication modules using the authentication SPI framework. (If you don't want to use this feature, your existing custom authentication modules do not need to be modified. The current APIs for getHttpServletRequest and getHttpServletResponse will continue to be supported but only for Access Manager 7.1 server deployments without the DAUI.)

Changes to custom authentication modules include both JAVA class files and callback XML files. No UI changes are required. Patch 5 adds these new callbacks:

• HttpRequestCallback: equivalent to the container HttpServletRequest object

• HttpResponseCallback: equivalent to the container HttpServletResponse object

For more information, see the Sun Java System Access Manager 7.1 Developer’s Guide.

Access Manager 7.1 Patch 4

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

• New Features and Changes in Access Manager 7.1 Patch 4

• Known Issues in Access Manager 7.1 Patch 4

New Features and Changes in Access Manager 7.1 Patch 4

• New property prevents "Too many authentication attempts" error (6883136)

• New property sets idle time out for policy agent sessions (6697260)

• Access Manager session cookies can be marked as HTTPOnly (6843487)

• ampassword utility has new options to hash and encrypt a password (6850818)

• Windows Desktop SSO authentication is added for Distributed Authentication UI Server deployment (6888820)

• CDC Servlet inserts custom HTTP response header (6800246)

• Changes to the updateschema.sh script (6870576)

New property prevents “Too many authentication attempts” error (6883136)

If you open multiple browser tabs in the same browser instance to access the Access Manager login page, the new com.sun.identity.authentication.mutiple.tabs.used property prevents the “Too many authentication attempts” error.

To use this new property, add it with a value of true to the AMConfig.properties file and restart the Access Manager web container.

New property sets idle time out for policy agent sessions (6697260)

The new com.iplanet.am.session.agentsessionidletime property sets the maximum idle timeout in minutes for policy agent sessions. The default value is 0, which causes policy agent sessions to never time out. The minimum value is 30 minutes. A value between 0 and 30 minutes will be reset to 30.

To use this new property, add it with a value appropriate for your deployment to the AMConfig.properties file and restart the Access Manager web container.

Access Manager session cookies can be marked as HTTPOnly (6843487)

The new com.sun.identity.cookie.httponly property allows Access Manager session cookies to be marked as HTTPOnly, in order to prevent scripts or third-party programs from accessing the cookies. Specifically, session cookies marked as HTTPOnly can help to prevent cross-site scripting (XSS) attacks.

By default, the value for com.sun.identity.cookie.httponly is false. To use this new property, add it with a value of true to the AMConfig.properties file and restart the Access Manager web container

You must also set this property on the client side. For example, for a Distributed Authentication UI server deployment, set it to true in the AMDistAuthConfig.properties file.

ampassword utility has new options to hash and encrypt a password (6850818)

In patch 4, the ampassword utility has the following new options:

ampassword -s | --hash [ password ]
ampassword -c | --hashencrypt [ password ]

where:

-s or --hash hashes the password.

-c or --hashencrypt both hashes and encrypts the password.

Windows Desktop SSO authentication is added for Distributed Authentication UI Server deployment (6888820)

Support for Windows Desktop SSO authentication is added for a Distributed Authentication UI server deployment and the Access Manager 7.0 and later Client SDK. This CR was verified for the following Access Manager 7.1 deployment scenarios:

• Access Manager 7.1 server with a version 7.1 Distributed Authentication UI server deployment from a browser (both Internet Explorer and Firefox)

• Access Manager 7.1 server with a version 7.1 Distributed Authentication UI server deployment with the Access Manager 7.0 and later Client SDK on Windows XP and Windows 2003

CDC Servlet inserts custom HTTP response header (6800246)

In patch 4, if you integrate Cross-Domain Single Sign-On (CDSSO) with programmatic clients, the CDC Servlet inserts an extra HTTP response header (which is not configurable). For example, with a web agent installed in CDSSO mode, viewing a response on “Live HTTP Headers”, you will see the Cdcservlet_auto_post: true header. This change allows custom applications to easily distinguish the auto submitting form and to process the information accordingly.

Changes to the updateschema.sh script (6870576)

Patch 4 includes the following changes to the updateschema.sh script:

• Removes the restriction of requiring the user to be superuser (root) to execute the script.

• Allows the user to specify whether Directory Server has SSL enabled.

• Validates the path of the ldapsearch and ldapmodify commands and prompts the user to specify the path if they are incorrect.

• Corrects the path to the amadmin utility in an Access Manger 7.1 single WAR file deployment.

Known Issues in Access Manager 7.1 Patch 4

• updateschema.pl script fails with older version of ldapjdk.jar (6934848)

• updateschema script cannot run successfully under certain circumstances in WAR file deployment (6934844)

updateschema.pl script fails with older version of ldapjdk.jar (6934848)

On Windows, the updateschema.pl script in Access Manager 7.1 patch 3 and later requires the version 4.21 or later ldapjdk.jar file. In some old ldapjdk.jar files, the version is not even defined in the META-INF/MANIFEST.MF file. If the LDAP JDK version is older than 4.21 or not defined, the updateschema.pl script exits with an error.

Workaround. Download and install the latest LDAP JDK patch, as described in Sun Java System LDAP JDK Patches.

updateschema script cannot run successfully under certain circumstances in WAR file deployment (6934844)

If Access Manager 7.1 patch 4 is deployed from a WAR file, the updateschema script cannot run successfully for the following reasons:

• On Solaris systems, the -B option is not available for the version of the ldapsearch utility that is called by the updateschema.sh script.

• On Linux systems, the -Z option is not available for the version of the ldapsearch utility that is called by the updateschema.sh script.

• On Windows, if you are running the updateschema.pl script, you cannot specify that the Directory Server is SSL enabled.

Workarounds

• On Solaris or Linux systems, edit the updateschema.sh script and change the path for the ldapsearch utility to point to a version that supports the -B and -Z options. You might need to download a version of ldapsearch that supports these options. Then, rerun the updateschema.sh script.

• On Windows, enable non-SSL access to Directory Server and rerun the updateschema.pl script.

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

• Known Issues in Access Manager 7.1 Patch 3

New Features and Changes in Access Manager 7.1 Patch 3

• Sun Java System LDAP JDK Patches are Available

• Running the updateschema Script is Required

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

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

• Sun Java Web Console 3.1 Patches Are Required

• New Property Prevents Sessions From Being Destroyed After Session Upgrade

• New Property Allows SSO Token Restriction Other Than an IP Address

• Distributed Authentication UI Server Works With Basic Authentication

• SecurID Authentication Support is Added for Linux Systems

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 Directory Server schema with any new attributes required by the patch.

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

• The updateschema.sh or updateschema.pl script requires JDK 1.5 or later. Therefore, set your JAVA_HOME environment variable to a JDK installation of 1.5 or later.

• On Windows systems, the updateschema.pl script requires AcivePerl 5.8 or later.

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 WAR file deployment directories (which must already exist):

  • Staging directory

  • Configuration directory

  • Tools directory

• Sun Java System Directory Server information:

  • Fully-qualified hostname. For example: ds.example.com

  • Port number, Default is 389.

  • Directory Manager DN and password. Default is cn=Directory Manager.

  • Top-level administrator and password. For example: uid=amadmin,ou=People,dc=example,dc=com

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:

• Solaris SPARC systems: 125950-18

• Solaris x86 systems: 125951-18

• Linux: 125954-18

• Windows: 125955-18 and 127534-18

These patches are available on My Oracle Support (https://support.oracle.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:

• true (default): Old sessions are destroyed immediately after a session upgrade.

• false: Old sessions are not destroyed after a session upgrade.

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:

• true: Access Manager 7.1 server enforces that an agent send the DN as the SSO token restriction.

• false (default): Access Manager 7.1 server uses whatever SSO token restriction is sent by the agent. The token restriction can be the IP address (for older agents that have amclientsdk.jar from Access Manager 7 2005Q4 patch 5 and earlier) or the DN (for newer agents that have amclientsdk.jar from Access Manager 7 2005Q4 patch 6 and later).

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 config Directory Path on Windows Contains a Space, Patch 3 updateschema.pl Fails (6852463)

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

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

Access Manager 7.1 Patch 2

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

• Access Manager 7.1 on WebLogic Server requires new ldapjdk.jar File (6774634)

• Creation of Data Store authentication module instance fails in Legacy mode (6764919)

• Sub-realm administrator can log in as amadmin in root realm (6761627)

• New com.sun.identity.appendSessionCookieInURL property (6740071)

• Backward compatibility issue between Access Manager 7.1 and amclientsdk.jar File (6754863)

• Access Manager JAR files should include version number in MANIFEST.MF file (6693152)

• Security permission is missing for CRL validation (6673538)

• SecurID authentication is supported on Solaris x86 systems (6621802)

• Access Manager Key Provider needs option to use types other than JKS format (6603228)

• Delegation privileges cannot be defined for a filtered role (6486843)

• Persistent cookie support is added (6600325)

Access Manager 7.1 on WebLogic Server requires new ldapjdk.jar File (6774634)

Sun provides a new ldapjdk.jar file that includes security and performance related fixes for Access Manager 7.1 patch 2. However, the Sun ldapjdk.jar won't be effective on WebLogic Server because weblogic.jar bundles an older ldapjdk.jar file.

Workaround. Put the Sun ldapjdk.jar ahead of weblogic.jar in the CLASSPATH, as follows:

1. Download the new Sun LDAP JDK patch (ldapjdk.jar) for your platform, as described in the note under Access Manager 7.1 Patch 2.

2. Copy the Sun ldapjdk.jar to the WebLogic lib directory.

   For example, on Windows:BEA_HOME\weblogic92\server\lib

3. Prefix the path to this ldapjdk.jar to the existing classpath. by editing the startup script used to start WebLogic Server. In the following examples, BEA_HOME is where WebLogic Server is installed.

   On Windows, edit:

   BEA_HOME\weblogic92\samples\domains\wl_server\bin\startWebLogic.cmd

   Change set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% to:

   set CLASSPATH=BEA_HOME\weblogic92\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%

   On Solaris or Linux, edit:

   /bea/weblogic92/samples/domains/wl_server/bin/startWebLogic.sh

   or

   /usr/local/bea/user_projects/domains/base_domain/bin/startWebLogic.sh

   Change CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" to:

   CLASSPATH="BEA_HOME/weblogic92/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"

4. Restart WebLogic Server.

Creation of Data Store authentication module instance fails in Legacy mode (6764919)

If you install Access Manager 7.1 patch 2 in Legacy mode and you create a Data Store authentication module instance in the Console, an error occurs while the module instance is created.

Note: This problem applies only to Access Manager 7.1 patch 2 and previous releases.

Workaround for Access Manager 7.1 in Legacy Mode. On systems running Access Manager 7.1 in Legacy Mode, in Directory Server, add the sunRegisteredServiceName attribute to the Data Store service and set the sunAMAuthDataStoreAuthLevel attribute to the minimum value (zero), to ensure the creation of the Data Store authentication module instance. For example, using ldapmodify:

ldapmodify -D "cn=Directory Manager" -w dm-password -h ds-host -p ds-port
dn: ds-rootdn
changetype: modify
add: sunRegisteredServiceName
sunRegisteredServiceName: sunAMAuthDataStoreService

ldapmodify -D "cn=Directory Manager" -w dm-password -h ds-host -p ds-port
dn: ou=default,ou=OrganizationConfig,ou=1.0,ou=sunAMAuthDataStoreService,ou=services, ds-rootdn
changetype: modify
add: sunkeyvalue
sunkeyvalue: sunAMAuthDataStoreAuthLevel=0

Sub-realm administrator can log in as amadmin in root realm (6761627)

If Access Manager 7.1 is installed in Realm mode and a sub-realm administrator creates another amadmin user in the sub realm, the second amadmin can also log in to the root (top-level) realm.

Access Manager 7.1 patch 2 fixes this problem. As the consequence of this fix, amadmin can log in to the Console using this URL: http://amhost.example.com:port/amserver/UI/Login?module=DataStore

New com.sun.identity.appendSessionCookieInURL property (6740071)

The new com.sun.identity.appendSessionCookieInURL property determines whether Access Manager appends the session cookie to the URL for zero page authentication. Set this property to false to prevent Access Manager from appending the session cookie to the URL. For example, if an application is filtering incoming URLs for special characters for security reasons and a cookie contains a special character, then access is denied The default value is true (cookie is appended).

Backward compatibility issue between Access Manager 7.1 and amclientsdk.jar File (6754863)

A backward compatibility issue exists between Access Manager 7.1 (all patch levels) and the amclientsdk.jar bundled with the policy agent 2.2 Hotpatch 5 and 7.

Workaround. If Access Manager 7.1 does not have cookie hijacking prevention enabled, add the following property to the policy agent AMAgent.properties file:

com.sun.identity.enableUniqueSSOTokenCookie=false

Note: If Access Manager 7.1 does have cookie hijacking prevention enabled, this workaround will not work.

Access Manager JAR files should include version number in MANIFEST.MF file (6693152)

Access Manager JAR files now have the version and build timestamp added to the MANIFEST.MF file. For example:

Specification-Version: "7.1"
Implementation-Version: "AM_7.1_20080917:05:27:19"

Security permission is missing for CRL validation (6673538)

Certificate-based authentication is not working if it is configured with Certificate Revocation list (CRL) checking.

Workaround. For an existing Access Manager instance, add the following security permission to the web container server policy file and then restart the web container:

permission java.security.SecurityPermission "getProperty.ocsp.*";

For Sun Java System Application Server and IBM WebSphere Application Server, the security policy file is server.policy. For BEA WebLogic Server, the file is weblogic.policy.

For new Access Manager instances, the respective web container amconfig script has been revised to add this security permission to the security policy file.

SecurID authentication is supported on Solaris x86 systems (6621802)

SecurID authentication is now supported on Solaris x86 systems (as well as on Solaris SPARC systems).

Access Manager Key Provider needs option to use types other than JKS format (6603228)

The default Key Provider implementation (JKSKeyProvider) uses JKS format. Access Manager now includes the following new configuration property that allows the keystore type to be changed. For example, for PKCS12 format:

com.sun.identity.saml.xmlsig.storetype=PKCS12

To use this new property, add it the AMConfig.properties file and restart the Access Manager web container.

Delegation privileges cannot be defined for a filtered role (6486843)

If you create a new filtered role, it does not appear under the Privileges tab in the Admin Console.

Workaround. After you apply patch 2, follow these steps to update the Delegation Service (sunAMDelegationService) in the Directory Server schema:

1. Create an XML file with the FILTEREDROLE subject type. For example:

   <?xml version="1.0" encoding="ISO-8859-1"?>
   <!DOCTYPE Requests
       PUBLIC "-//iPlanet//Sun Java System Access Manager 2005Q4 Admin CLI DTD//EN"
       "jar://com/iplanet/am/admin/cli/amAdmin.dtd">
   <Requests>
      <SchemaRequests serviceName="sunAMDelegationService"
          SchemaType="Global" i18nKey="">
          <AddDefaultValues>
              <AttributeValuePair>
                  <Attribute name="SubjectIdTypes"/>
                  <Value>FILTEREDROLE</Value>
              </AttributeValuePair>
          </AddDefaultValues>
      </SchemaRequests>
   </Requests>

   Note: The XML encoding used in this example is ISO-8859-1. You might need to use a different encoding depending on your environment.

2. Use the amadmin command to load the XML file you created in Step 1 into Directory Server. For example:

   # cd /opt/SUNWam/bin
   # ./amadmin -u amadmin -w pwfile -t new-filteredrole.xml

   where:

   • pwfile contains the amadmin password.

   • new-filteredrole.xml is the new XML file you created in Step 1.

3. Restart the Access Manager server web container.

Now, when you log in to the Administration Console, the filtered role will appear under the Privileges tab.

Persistent cookie support is added (6600325)

Persistent cookie support is added for Access Manager session cookies if:

• The com.iplanet.am.cookie.timeToLive property is set to a non-zero value in the AMConfig.properties file.

  and

• The Access Manager Console is accessed with PersistAMCookie=true, as follows:

  http://amhost:port/amserver/UI/Login?PersistAMCookie=true

Access Manager 7.1 Patch 1

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

• Support for specific application idle session timeout values

• Web Proxy Agent 2.2-01 in CDSSO mode does not work with Access Manager 7.1 Patch 1 (CR 6611841)

• Distributed Auth UI does not work with a WebSphere Application Server 5.1.1.12 server (CR 6625928)

• Password file exposed in a temporary directory after Patch 1 re-deployment (CR 6640377)

• LDAP Failover not working properly (CR 6611627)

• amconfig does not tag-swap and re-register the monitoring framework descriptor (CR 6636710)

• amtune does not work if installed in a non-default directory (CR6640673)

• amtune does not delete the world readable password file (CR 6640672)

• amtune should set thread pool size at 3 times the number of CPUs or cores for CMT servers (CR 6631123)

• amsfo.pl does not work for Windows (CR 6629189)

• Not able to deploy WAR file generated by patch.bat if -l option is used for Windows (CR 6636474)

• amserveradmin.bat throwing errors for Access Manager 7.1 Patch for Windows (CR 6631526)

• amsfo.pl script does not work for Session Failover in a Single War deployment for Windows (CR 6646519)

• Access Manager classpath not pointing to xml.sec.jar in Patch 1 for Windows (CR 6644461)

• Post authentication plug-in supports Microsoft SharePoint (CR 6541695)

• Retrieving schema from Active Directory data store fails (CR 6542686)

• Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout method (CR 6536635)

• saml samples will not work if the saml module instance is created with lower case name "saml" (CR 6648342)

• G11n: CLI commands amhasetup and amserver are not localized (CR 6567135)

• G11n: The User sub-tab incorrectly translated in French language (CR 6633529)

• Web Security Service Issues Fixed

• Removed ACIs that cause unnecessary performance degradation (CR 6484947)

• 6.3-based console online help not displayed win Application Server 8.2 (CR 6587213)

• Multiple passwords not required for amtune script

• amtune-os will not run in local zone

Support for specific application idle session timeout values

Patch 1 allows different applications to have different session idle timeout values. In an enterprise, some applications might require session idle timeout values that are less than the session idle time out specified in the session service. For example, you have specified session the idle timeout value in the session service as 30 minutes, but an HR application should timeout if a user has been idle for more than 10 minutes.

This feature is not currently supported for Distributed Authentication and Cross Domain Single Sign-on scenarios

Requirements to use this feature are:

• Agents protecting the application must be configured to enforce URL policy decisions from Access Manager.

• Agents must be configured to run in self policy decision cache mode. See the following properties:

  • For web agents: com.sun.am.policy.am.fetch_from_root_resource

  • For J2EE agents: com.sun.identity.policy.client.cacheMode

• The Access Manager AMConfig.properties file must specify a policy component evaluation order such that Condition is evaluated last. See the following property:

  com.sun.identity.policy.Policy.policy_evaluation_weights

• The application access allowed by the agent based on a locally cached decision will not be known to the Condition on Access Manager. Therefore, the actual application idle timeout will be between the application idle timeout to the application idle timeout minus the agent cache duration.

To use this feature:

• Add an Authentication Scheme Condition to the policies protecting the application that requires the application specific session idle timeout.

• Specify the Application Name and Timeout Value in the Authentication Scheme Condition.

• Use the same Application Name and Time Out value in all the policies that apply to the resources for the application.

• Specify the Timeout Value in minutes. If the value is 0 or greater than the session idle timeout value specified in the session service, the value is ignored, and the timeout from session service will apply.

For example, consider a policy http://host.sample.com/hr/*, with this Authentication Scheme Condition:

• Authentication Scheme: LDAP

• Application Name: HR

• Timeout Value: 10

If there are multiple policies defined to protect resources of the HR application, you must add the Condition to all of the policies.

When a user in a distinct session attempts to access the HR application protected by the Access Manager agent, that user is prompted to authenticate for the LDAP scheme (if the user is not yet authenticated).

If the user has already authenticated to the LDAP scheme, that user is allowed access only if the time is less than 10 minutes since the time the last authentication or if the time is less than 10 minutes since that user's last access time to the HR application. Otherwise, the user is prompted to authenticate to the LDAP scheme again to access the application.

The Idle Session Timeout for a realm is configured for the highest value required by all applications. Shorter Idle Session Timeout requirements are enforced by the Policy Condition protecting the appropriate applications. However, if you define explicit "deny" policies to protect the application, it would break this protection. This is because the new the new Condition extends the idle timeout for the application, assuming that the access to the application is allowed if this Condition is satisfied. If the other "deny" policy is satisfied, the user can not access the application.

Application idle timeout of value 0 is treated as Integer.MAX_VALUE for the purposes of idle timeout enforcement.

Web Proxy Agent 2.2-01 in CDSSO mode does not work with Access Manager 7.1 Patch 1 (CR 6611841)

The Web Proxy Agent 2.2-01 in Cross Domain Single Sign-on mode does not work with Access Manager 7.1 Patch . The agentRootURL requirement was added as a security measure to ensure that CDC is handing off ssotoken cookie to trusted agents running at known URLs.

Workaround

1. Create a new agent profile in the Access Manager server using the administration console.

2. Set the Agent Key agentRootURL=http://<agenthost>:<agentport>/using the console.

3. Get the encrypted password for the new agent profile using cryp_utilon the Agent

4. Use the new agent username and corresponding encrypted password in the AMAgent.properties file.

Distributed Auth UI does not work with a WebSphere Application Server 5.1.1.12 server (CR 6625928)

In Patch 1, the

Distributed Authentication user interface does not work with a WebSphere Application Server 5.1.1.12 server.

Password file exposed in a temporary directory after Patch 1 re-deployment (CR 6640377)

After Access Manager Patch 1 applied to Access Manager 7.1 and re-deployed, several/tmp directories are created. In one of them, the permissions are incorrectly set so that the sun_ad_dirmgrpasswd is readable. These directories are automatically deleted when the deployment is completed, but they are exposed for a matter of time before hand. This is a potential security risk.

Workaround

Before re-deploying the patch, set umask 077. The files will then be created with the correct permissions.

LDAP Failover not working properly (CR 6611627)

LDAP failover does not work if the primary LDAP failover server is set to SSL and the secondary server is set to non-SSL. There is no workaround at this time.

amconfig does not tag-swap and re-register the monitoring framework descriptor (CR 6636710)

When Patch 1 is applied to a full Access Manager installation using the amconfig script to redeploy all of the web applications, amconfig does not tag swap the monitoring framework descriptor. As a result, the monitoring framework description at $CONFIG_DIR/com.sun.cmm.am.xml only contains tags.

Workaround

Back up the monitoring framework descriptor (Solaris locatoin is /etc/opt/SUNWam/config/com.sun.cmn.am.xml, Linux location is /etc/opt/sun/identity/config/com.sun.am.xml) before applying the patch. Once the patch is applied, replace the patched file with the original file in the same location.

amtune does not work if installed in a non-default directory (CR6640673)

The amtune script will not work if installed in a non-default directory. This occurs on all platforms. The script is defaulting to the LDAP installation directory when the package is not found on the system.

Workaround

Modify the amtune-directory so that LDAP_DIR points to the DSEE base directory:

DSADMIN=$LDAP_DIR/ds6/bin/dsadm

amtune does not delete the world readable password file (CR 6640672)

The amtune script does not delete the password file after it completes. The file should be deleted after the completion of the script.

Workaround

Modify the set DSADMIN_PASSFILE attribute, or any directory that only the root user can read, in the amtune-env file before running the amtune script. For example:

DSADMIN_PASSFILE=/var/tmp/dspassfile

amtune should set thread pool size at 3 times the number of CPUs or cores for CMT servers (CR 6631123)

The optimal size of Access Manager's notification thread pool size (com.iplanet.am.notification.threadpool.size in AMConfig.properties) was 3 times the number of CPU's where Access Manager is deployed or the number of cores in cases of CMT servers like Niagara I and II (Sun Fire T1000/2000 and T5120/T5220 servers). The current amtune-identity sets the maximum number of thread pools at 28 regardless of number of CPU's and calculates the optimal value based on the available amount of memory.

Workaround

Increase the value in the com.iplanet.am.notification.threadpool.size property in AMConfig.properties by three times the number of CPU's or cores in cases of CMT servers (e.g., T1000/T2000 or T5210/T5220 servers), overriding the recommended values by amtune-identity script.

amsfo.pl does not work for Windows (CR 6629189)

For Access Manager Patch 1 for Windows, the amsfo.pl script does not work properly. There is no workaround at this time.

Not able to deploy WAR file generated by patch.bat if -l option is used for Windows (CR 6636474)

If you are deploying the WAR file using patch.bat, do not use the -l option as it will cause errors and fail to deploy.

amserveradmin.bat throwing errors for Access Manager 7.1 Patch for Windows (CR 6631526)

Executing the amserveradmin.bat batch file produces the following error message:

The system cannot find the path specified.
Loading amAdminConsole.xml
The system cannot find the path specified.
Loading amAuth.xml
The system cannot find the path specified.
Loading amAuthAnonymous.xml
The system cannot find the path specified.
Loading amAuthCert.xml
The system cannot find the path specified.

This is because after reconfiguring, tokens in this file are not getting tag swapped.

Workaround

In the amserveradmin.bat.template, set the value for AM_DIR to AM_DIR=c:\sun\identity. Rename the template file to amserveradmin.bat.

amsfo.pl script does not work for Session Failover in a Single War deployment for Windows (CR 6646519)

In a single WAR deployment for Windows, the session failover script, amsfo.pl, fails to start the amsessiondb client. In order to fix this, perform all of the steps described in the following workaround.

Workaround

1. Edit the amsfo.conffile to replace the AMSESSIONDB_ARGS= parameter with AMSESSIONDB_ARGS="".

2. Edit the amsfo.conf file to replace the $AM_HOME_DIR/.password with the absolute value of the .password file. For example:

   PASSWORDFILE=c:/was_session/sfo/.password

3. Edit the amsfo.pl script to include the -javahome option for the following argument:

   $jmq_args = "-bgnd $broker_options -vmargs $broker_vm_args -name $broker_instance_name -port $broker_port -cluster $cluster_list -javahome $java_home";

   Set the java_home as defined in your environment, as it does not read it from the environment even though it is set there.

4. Remove the /logs/jmq pid file.

Access Manager classpath not pointing to xml.sec.jar in Patch 1 for Windows (CR 6644461)

In Access Manager Patch 1 for Windows, the Access Manager classpath is not pointing to the patched version of the xmlsec.jar.

Workaround

Copy jes-install-dir\identity\lib\xmlsec.jar to jes-install-dir\share\lib\xmlsec.jar.

Post authentication plug-in supports Microsoft SharePoint (CR 6541695)

The Access Manager post-authentication plug-in (ReplayPasswd.java) has been modified in this patch release to read the com.sun.am.sharepoint_login_attr_name=sharepoint-login-value property. The value of this property indicates the user token that SharePoint uses for authentication.

For example, if “login” is the LDAP attribute that is mapped in both the places (Access Manager and SharePoint), then the property should be com.sun.am.sharepoint_login_attr_name=login.

The post-authentication plug-in will read this property and retrieve the corresponding value from Directory Server. It will then replace this value as a session property. The IIS6 authentication plug-in is modified to read this new property and set authorization headers for Sharepoint to work.

Retrieving schema from Active Directory data store fails (CR 6542686)

Access Manager 7.1 would not successfully retrieve the schema if you are using the Active Directory datastore. Installing patch 1 will fix this issue. To incorporate the fix, load the am_remote_ad_schema.ldif file. This file is located at /etc/opt/SUNWam/config/ldif for Solaris systems, /etc/opt/sun/identity/config/ldif for Linux systems, and \identity\config\ldif for Windows systems.

Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout method (CR 6536635)

To support the setReadTimeout method, the AMConfig.properties file has the following new property for you to set the read timeout value:

com.sun.identity.url.readTimeout

If the web container is using JDK 1.5, set this property to an appropriate value to cause connections to time out, in order to avoid having too many open HttpURLConnections that might cause the server to hang. The default is 30000 milliseconds (30 seconds).

The setReadTimeout method is ignored if com.sun.identity.url.readTimeout is not present in the AMConfig.properties file or is set to an empty string.

saml samples will not work if the saml module instance is created with lower case name "saml" (CR 6648342)

If a SAML instance is created with the name "saml", the amSAML authentication fails and the sample will not work.

G11n: CLI commands amhasetup and amserver are not localized (CR 6567135)

For EMEA locales, the amhasetup and amserver command line utilities return unlocalized output. For other languages, the output is localized.

G11n: The User sub-tab incorrectly translated in French language (CR 6633529)

After you have created a user in the User sub-tab of the Realm tab in the French language, the edited user message is incorrectly displayed as Modification de Utilisateur.

Web Security Service Issues Fixed

6543625 — UserName token authentication can authenticate against a configured LDAP module

The UserName token authentication is able to authenticate against a configured LDAP module. In previous releases, the UserName token authentication could only use the Access Manager file-based authentication realm.

6543626 — SOAPRequestHandler returns the SSOToken set in the Subject

SOAPRequestHandler now returns the SSOToken set in the Subject, in addition to X509 or UserName token that was used for authentication. The SSOToken is in the format usable to the PolicyEvaluator API.

6544177 — When using X509 token with an invalid certificate AM always accepts the cert even without root CA

When using X509 token with an invalid certificate, Access Manager always accepts the certificate, despite the fact that the root CA is not in the Keystore. this problem has been fixed.

6559603 — Boolean configuration flag for "request" signing

A web service user can now choose boolean configuration for SOAP request signing.

6543620 Access Manager Policy Agent profiles able to apply a digital signature to the service request for UserName token

Access Manager Policy Agent profiles can apply a digital signature to the service request and the service response. In previous releases, digital signature could be used only in case when X509 token is included into SOAP message for authentication.

6543623 Access Manager Policy Agent profiles able to encrypt SOAP request body and SOAP response body

Access Manager Policy Agent profiles are now able to encrypt SOAP request body and SOAP response body.

6570021 Encryption supports SOAP messages with extra spaces.

Access Manager now supports the encryption of SOAP message with extra spaces and new lines between XML elements of SOAP message. It is common to see SOAP messages with extra spaces and new lines inserted for better readability.

Removed ACIs that cause unnecessary performance degradation (CR 6484947)

The amtune script has been changed to enhance the performance of AM 7.1 by removing unnecessary ACI checks. You must run amtune after the patch installation to remove the ACIs.

6.3–based console online help not displayed win Application Server 8.2 (CR 6587213)

If you have installed Access Manager from the Java ES 5 update 1, and have it deployed with Application Server 8.2, the Access Manager console online help will not display. This only occurs in the 6.3–based Access Manager console, accessed by /amconsole.

Multiple passwords not required for amtune script

In Access Manager 7.1 Patch 1 you do not need to enter multiple passwords when executing individual amtune scripts. Only the wrapper amtune script which calls individual scripts needs multiple passwords. For instance, amtune-os and amtune-identity do not require any password. amtune-directory requires only Directory Manager password, while amtune-ws6, -ws7 and -as8 require the corresponding web container admin passwords.

amtune-os will not run in local zone

amtune-os will not run if the wrapper amtune script is run in a local zone on Solaris 10, or higher, but other individual amtune scripts will still run.

Pre-Installation Considerations

Review the following section before applying the patch.

Installing and Configuring Access Manager

The Access Manager patches described in this document do not install Access Manager. Before you install the patch, Access Manager 7.1 must be installed on the server. For information about installation for Sun Java Enterprise System 5, see following documents:

• If you are installing the patch on a Solaris or Linux system, see the Sun Java Enterprise System 5 Installation Guide for UNIX

• If you are installing the patch on a Windows system, see the Sun Java Enterprise System 5 Installation Guide for Microsoft Windows.

For information about installation for Sun Java Enterprise System 5 Update 1, see following documents:

• Sun Java Enterprise System 5 Installation Guide for UNIX

• Sun Java Enterprise System 5 Upgrade Guide for Microsoft Windows

You should also be familiar with running the amconfig script to deploy, re-deploy, and configure Access Manager, as described in Chapter 2, Running the Access Manager amconfig Script, in the Sun Java System Access Manager 7.1 Postinstallation Guide in the Access Manager 7.1 documentation library: http://docs.oracle.com/cd/E19462-01/.

For a list of the Access Manager patches that are made obsolete by this patch and any patches that you must install before you install this patch, refer to the README file included with this patch.

Patch Installation Instructions

• Patch Installation Instructions For Solaris Systems

• Patch Installation Instructions For Linux Systems

• Patch Installation Instructions For Windows Systems

Patch Installation Instructions For Solaris Systems

Before you install the Solaris patch, make sure that you have backed up the files listed in Pre-Installation Considerations.

To add and remove patches on Solaris systems, use the patchadd and patchrm commands, which are provided with the OS.

patchadd Command

Use the patchadd command to install a patch on a standalone system. For example:

# patchadd /var/spool/patch/126356-05

The postpatch script displays a message about redeploying the Access Manager applications, except on a system that has only the Access Manager SDK component installed.

The postpatch script creates the amsilent file in the following directory:

• Solaris systems: AccessManager-base/SUNWam

AccessManager-base is the base installation directory. The default base installation directory is /opt on Solaris systems and /opt/sun on Linux systems.

The amsilent is based on the amsamplesilent file, but with some required parameters set according to the Access Manager configuration files on the system. The password parameters, however, contain default values. Uncomment and modify the value of each password parameter and carefully check values of other parameters in this file, as needed for your deployment.

The COMMON_DEPLOY_URI parameter, the URI prefix for the common domain web application, also contains a default value. If you have chosen a non-default value for this URI, make sure to update this value. Otherwise, the redeployment of the web applications with amconfig and the patch generated amsilent file will fail.

Then, run the following command (shown with Access Manager installed in the default directory):

# cd /opt/SUNWam/bin 
# ./amconfig -s /opt/SUNWam/amsilent

patchrm Command

Use the patchrm command to remove a patch from a standalone system. For example:

# patchrm 126356-05

The backout script displays a message similar to the patchadd command, except on a system that has only the Access Manager SDK component installed.

After the patch is removed, redeploy the Access Manager applications using the amsilent file in the AccessManager-base/SUNWam directory, where AccessManager-base is the base installation directory. The default base installation directory is /opt on Solaris systems.

Set the parameters in the amsilent file, as needed for your deployment.

Then, run the following command, which is shown with Access Manager installed in the default directory on Solaris systems:

# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent

For additional information and examples about the patchadd and patchrm commands, see the appropriate Solaris man pages.

Solaris 10 Zones

The Solaris 10 operating system introduced the new concept of “zones.” Consequently, the patchadd command includes the new -G option, which adds a patch only to the global zone. By default, the patchadd command looks for the SUNW_PKG_ALLZONES variable in the pkginfo of packages to be patched. However, for all Access Manager packages, the SUNW_PKG_ALLZONES variable is not set, and the -G option is required if Access Manager 7.1 is installed in the global zone. If Access Manager is installed in a local zone, the patchadd -G option has no effect.

If you are installing Access Manager 7.1 patches on a Solaris system, it is recommended that you use the -G option. For example:

 # patchadd -G AM7_patch_dir

Similarly, if Access Manager is installed in the global zone, the -G option is required to run the patchrm command. For example:

# patchrm -G 126356-05

Patch Installation Instructions For Linux Systems

Before you install the Linux patch, make sure that you have backed up the files listed in Pre-Installation Considerations.

The installpatch installs a patch on a standalone Linux system. For example:

# ./installpatch

The postpatch script prints messages similar to the messages on a Solaris system. However, the procedure to back out a patch on a Linux system is different than on a Solaris system. There is no generic script to back out a Linux patch. If a lower version of the patch was previously installed, you can re-install that version and then follow the postpatch instructions to redeploy the Access Manager applications by running the amconfig script.

If the patch is installed on the Access Manager 7.1 RTM release and you want to remove the patch and restore the system to the RTM state, you must reinstall the Access Manager RTM bits using the reinstallRTM script. This script takes the path where the Access Manager RTM RPMs are stored and installs the RTM RPMs over the patched RPMs. For example:

# ./scripts/reinstallRTM path_of_AM71_RTM_RPM_directory

After you run the reinstallRTM script, redeploy the Access Manager applications by running the amconfig script and the restart the web container.

Patch Installation Instructions For Windows Systems

The requirements to install the Windows patch include:

• Access Manager 7.1 must be installed on the Windows system. For information about installation, see the Sun Java Enterprise System 5 Installation Guide for Microsoft Windows.

• To run the patch scripts, ActivePerl 5.8 (or later) is required on the Windows system.

Installing the Windows Patch

Before you install the Windows patch, make sure that you have backed up the files listed in Pre-Installation Considerations.

In the base directory path for input to the patch scripts, use a forward slash (/). For example: c:/sun

To install the Windows patch:

1. Logon to the Windows system as a member of the Administrators group.

2. Create a directory to download and unzip the Windows patch file. For example: AM71p1

3. Download and unzip the 126359-05.zip file in the directory from the previous step.

4. Stop all Java Enterprise System 5 services.

5. Run the AM71p1\scripts\prepatch.pl script.

6. Run AM71p1\126359-05.exe to install the patch.

7. Run the AM7p5\scripts\postpatch.pl script.

8. Restart the Java ES 5 services.

9. Redeploy the Access Manager applications.

Backing Out the Windows Patch

To back out the Windows patch:

1. Logon to the Windows system as a member of the Administrators group.

2. Run the Uninstall_126359-05.bat file.

3. Run the AM71p1\scripts\postbackout.pl script.

4. Redeploy the Access Manager applications.

5. Restart the Java ES 5 services.

Access Manager 7.1 Patch 1 Single WAR Deployment

This section describes new features, installation instructions and known problems for Access Manager 7.1 patch 1 single WAR deployment.

New Container Versions Supported

The Access Manager 7.1 patch 1 now supports the following containers:

• IBM WebSphere Application Server 6.1

• BEA WebLogic Server 9.2

The version of Access Manager single web-application (WAR) supported on these containers is located in zip_install_directory/applications/jdk14. zip_install_directory is the directory to which you downloaded the .ZIP file for the WAR.

Considerations for Single WAR Deployment with WebSphere 6.1

After you obtain the Access Manager 7.1 patch 1 single WAR, see “Adding Access Manager Permissions to the Server Policy File” in the Access Manager 7.1 Postinstallation Guide in the Access Manager 7.1 documentation library: http://docs.oracle.com/cd/E19462-01/ for information about configuring the permissions to the server policy file for the web container on which Access Manager will be deployed.

In addition to the policy changes, follow the steps described in “Deploying an Access Manager 7.1 WAR File in IBM WebSphere Application Server” also in the Access Manager 7.1 Postinstallation Guide.

Considerations for Single WAR Deployment with Weblogic 9.2

For BEA WebLogic Server 9.2, the following JVM property needs to be added in the BEA WebLogic Server instance start script, startWebLogic.sh:

JAVA_OPTIONS= "-Djavax.xml.soap.MessageFactory=com.sun.xml.

messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl"

After you obtain the Access Manager 7.1 patch 1 single WAR, see Adding Access Manager Permissions to the Server Policy File in Sun Java System Access Manager 7.1 Postinstallation Guide for information on configuring the permissions to the server policy file for the web container on which Access Manager will be deployed.

Applying Patch 1 for Single WAR Deployment

The application of patch 1 is required if you already have an RTM version of the Access Manager single web-application deployed and wish to redeploy the Access Manager patch 1 web application. If there is no prior deployment of Access Manager, then Access Manager single web-application (WAR) provided under the zip_install_dir/applications directory can be used.

The patch is provided in a separate directory, zip_install_dir/patch. In this directory, there is a README provided with instructions on running the patch utility.

The patch utility and related files provided in the ZIP file are only for applying the patch to Access Manager single web-application downloaded from the SUN's download site. This patch will not operate with the Access Manager single WAR web-application generated by using the Java Enterprise Systems 5 “Configure Later” option with DEPLOY_LEVEL=10.

After you have successfully applied the patch, copy the following property in the configured instance's AMConfig.properties file and then restart the container:

com.sun.identity.url.readTimeout=30000

This patch does not support the patch application to the JavaEE SDK Access Manager WAR file.

Known Issues with Patch 1 WAR Deployment

This section lists the known issues with the Access Manager 7.1 patch 1 WAR deployment.

Modifying SAML source ID in WAR deployment for Access Manager 7.1 Patch 1 (CR 6582972)

This issue will only occur when you already have a RTM version of Access Manager single web-application deployed and would now want to redeploy Access Manager patch 1 web-application. After you have successfully un-deployed the RTM version of Access Manager and redeployed the patch 1 version of Access Manager, follow the steps outlined under the "Workaround" section. If you are deploying Access Manager patch 1 web-application without any prior installation of Access Manager in your environment, then the outlined workaround is not required. Additionally, this workaround is applicable only when using SAML v.1.

Workaround

1. Extract the Access Manager 7.1 patch 1 ZIP file into a directory, for example am71_patch1_dir.

2. Run the following command to generate the SAML source ID:

   java --classpath am71_patch1_dir/sdk/amclientsdk.jar com.sun.identity.saml.common.SAMLSiteID/server_protocol://server_host:server_port/server_deploy_uri

   A Base64 encoded SAML source ID is displayed. Keep this display open.

3. Log into the Access Manager console as the top-level administrator.

4. Go to Federation > SAML > Site Identifiers and click the Instance ID link for the server

5. In the Site ID field, replace the old value (SAML_SITEID) with the source ID generated in the previous step and click Save when finished.

6. Click Save again.

amAdmin from amAdminTools.zip Single WAR does not work with IBM JDK WebSphere 6.1 (CR 6618861)

Currently there is no support to run Access Manager's CLI tools with a non-Sun JDK.