Considerations for patch 2 include:
Access Manager 7.1 WAR file deployments. Patch 140504 is available on http://sunsolve.sun.com/ for Access Manager 7.1 WAR file deployments. See the patch README file for more information. (For consistency with other Access Manager 7.1 patches, “02” is the first release of this patch.)
LDAP JDK patches. Sun provides LDAP JDK (ldapjdk.jar) patches for security and performance related fixes, as described in Sun Java System LDAP JDK Patches.
Legacy mode. If you plan to use Access Manager 7.1 patch 2 in Legacy mode, see Creation of Data Store authentication module instance fails in Legacy mode (6764919).
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)
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)
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:
Download the new Sun LDAP JDK patch (ldapjdk.jar) for your platform, as described in the note under Access Manager 7.1 Patch 2.
Copy the Sun ldapjdk.jar to the WebLogic lib directory.
For example, on Windows:BEA_HOME\weblogic92\server\lib
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}" |
Restart WebLogic Server.
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
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
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).
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 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"
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 now supported on Solaris x86 systems (as well as on Solaris SPARC systems).
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.
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:
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.
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.
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 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