test

Sun Java System Access Manager 7 2005Q4 Release Notes

Access Manager 7 2005Q4 Patch Releases

The latest revisions of the Access Manager 7 2005Q4 patches are available for download from SunSolve Online: http://sunsolve.sun.com. The most recent patch IDs are:

Note –

Patch 12 is the last patch for Sun Java System Access Manager 7 2005Q4. For more information, see the “Lifetime Support Policy: Oracle Fusion Middleware Products” at http://www.oracle.com/us/support/library/lifetime-support-middleware-069163.pdf.

Access Manager 7 2005Q4 patches are cumulative. You can install a patch without first installing an earlier patch. However, if you did not install an earlier patch, review the new features and issues in the earlier patch sections to determine if any of the features and issues apply to your deployment.

Information about Access Manager 7 2005Q4 patches includes:

Access Manager 7 2005Q4 Patch 12

Access Manager 7 patch 12 (revision 12) fixes a number of problems, as listed in the README file included with the patch. Patch 12 also includes these issues and changes:

CR# 6916733: updateschema script checks for LDAP JDK version 4.21 or later

Access Manager 7 patch 9 and later requires LDAP JDK (ldapjdk.jar) version 4.21 or later.

With patch 12, the updateschema.sh or updateschema.pl script checks the LDAP JDK version. If the version is older than 4.21 or not defined, the script displays a message that you should install the latest LDAP JDK patch.

For security reasons, it is highly recommended that you download and install the latest LDAP JDK patch from SunSolve Online (http://sunsolve.sun.com/), depending on your specific platform:

CR# 6770231: Access Manager 7 Patch 12 validates goto URLs

After installing patch 12, Access Manager 7 2005Q4 server can validate a goto URL after a user logs in. This fix prevents a hacker from sending the user to an imposter site in order to steal the user's personal information.

To set valid goto URLs, follow these steps:

  1. After you install patch 12, make sure you run the updateschmema.sh or updateschema.bat script and then restart the Access Manager web container.

  2. Log in to the Access Manager Administration Console.

  3. Click Configuration, Authentication, and then Core.

  4. Under Valid goto URL domains, add each valid goto domain name, as follows:

    • A domain name starting with a dot (.) such as .example.com allows all hosts in the example.com domain to be used in a success redirect URL.

    • A domain name that does not start with a dot (.) such as example.com allows the host example.com to be used in a success redirect URL. For example, http://example.com would be valid, but http://host.example.com would not be valid.

    • If you don't add the entire domain to the list, you must add each individual agent host name being used.

    • You do not need to add domains for agents in CDSSO mode, because they are protected automatically.

  5. Click Save.

  6. Restart the Access Manager web container.

If you subsequently want to disable the goto URL validation, remove all entries from the Valid goto URL domains list. If a goto URL is found to be invalid, the user will be redirected to the default success login URL.

CR# 6926203 Distributed Authentication UI server deployment validates goto URLs

In a Distributed Authentication UI (DAUI) server deployment, Access Manager 7 patch 12 validates goto URLs on the DAUI server side. This fix is similar to the Access Manager server side fix described previously in CR 6770231. The DAUI server reads the valid domain list from Access Manager server and does not maintain its own list. After you install patch 12, make sure you restart the DAUI server.

Pre-Installation Considerations

Backing Up Files

Important If any of the files in your current installation are customized, back up those files before you install the patch. After you install the patch, compare the backed up files with the new files installed by this patch to identify the customizations. Merge the customizations with the new files and save them. For more information about how to handle customized files, read the following information.

Before you install a patch, also back up the following files.

Solaris Systems

  • AccessManager-base/SUNWam/bin/amsfo

  • AccessManager-base/SUNWam/lib/amsfo.conf

  • Files in the /etc/opt/SUNWam/config/xml/template/ directory:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml, amAuth.xml, amSession.xml

  • Files in the AccessManager-base/SUNWam/locale/ directory:

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Linux and HP-UX Systems

  • AccessManager-base/identity/bin/amsfo

  • AccessManager-base/identity/lib/amsfo.conf

  • Files in the /etc/opt/sun/identity/config/xml/template/ directory:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml, amAuth.xml, amSession.xml

  • Files in the AccessManager-base/identity/locale/ directory:

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

Windows Systems

  • AccessManager-base\identity\setup\AMConfigurator.properties

  • AccessManager-base\identity\bin\amsfo

  • AccessManager-base\identity\lib\amsfo.conf

  • Files in the AccessManager-base\identity\config\xml\template directory:

    idRepoService.xml, amSOAPBinding.xml, amDisco.xml, amAuthCert.xml, amAuth.xml, amSession.xml

  • Files in the AccessManager-base\identity\locale directory:

    amConsole.properties, amIdRepoService.properties, amAuthUI.properties, amAuth.properties, amPolicy.properties, amPolicyConfig.properties, amSessionDB.properties, amSOAPBinding.properties, amAdminCLI.properties, amSDK.properties, amAuthLDAP.properties, amSession.properties, amAuthContext.properties, amSAML.properties, amAuthCert.properties

AccessManager-base is the base installation directory. The default base installation directory depends on the platform:

  • Solaris systems: /opt

  • Linux and HP-UX systems: /opt/sun

  • Windows systems: javaes-install-directory\AccessManager. For example: C:\Program Files\Sun\AccessManager

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 2005Q4 must be installed on the server. For information about installation, see the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

If you are installing the patch on a Windows system, see the Sun Java Enterprise System 2005Q4 Installation 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 the Chapter 1, Access Manager 7 2005Q4 Configuration Scripts, in Sun Java System Access Manager 7 2005Q4 Administration Guide.

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.

Caution – Caution –

Access Manager patches (as with any other patches) should be tested on a staging or pre-deployment system before you put them into a production environment. Also, the patch installer might not update your customized JSP files properly, so you might need to make manual changes in these files in order for Access Manager to function properly.

Patch Installation Instructions

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/120954-12
Note –

If you are installing the Solaris patch on a Solaris 10 global zone, invoke the patchadd command with the -G argument. For example:

patchadd -G /var/spool/patch/120954-12

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:

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
Caution – Caution –

The amsilent file contains sensitive data such as administrator passwords in plain text, so make sure you secure the file as appropriate for your deployment.

After you run the amconfig script, execute the updateschema.sh script to load the XML and LDIF files. The updateschema.sh script is available after you install patch 11 in the following directory:

After you run the updateschema script, restart the Access Manager processes. For example:

# cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

Then, restart the Access Manager web container.

patchrm Command

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

# patchrm 120954-03

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.

See also Post-Installation Considerations for more information.

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 2005Q4 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 2005Q4 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 120954-09

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.

After you run the amconfig script, execute the updateschema.sh script (patch 5 and later patches) to load the XML and LDIF files. The updateschema.sh script is available after you install patch 11 in the patch-home-directory/120956-09/scripts directory.

After you run the amconfig and updateschema.sh scripts, restart the Access Manager web container.

If the patch is installed on the Access Manager 7 2005Q4 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_AM7_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.

See also Post-Installation Considerations for more information.

Patch Installation Instructions For Windows Systems

The requirements to install the Windows patch include:

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: AM7p8

  3. Download and unzip the 124296-09.zip file in the directory from the previous step.

  4. Stop all Java ES 2005Q4 services.

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

  6. Run AM7p8\124296-09.exe to install the patch.

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

  8. Restart the Java ES 2005Q4 services.

  9. Redeploy the Access Manager applications. See Post-Installation Considerations for more information.

  10. Run the AM7p8\scripts\updateschema.pl script to update the Directory Server service schema. The script validates your entries and then loads the files. The script also writes the following log file:

    javaes-install-directory\AccessManager\AM70Patch-upgrade-schema-timestamp

  11. Restart the Java ES 2005Q4 services.

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_124296-09.bat file.

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

  4. Redeploy the Access Manager applications.

  5. Restart the Java ES 2005Q4 services.

Note: If you back out the patch, the schema changes added by the AM7p8\scripts\updateschema.pl script are not removed from Directory Server. However, you do not need to remove these schema changes manually because they will not affect Access Manager functionality or usability after the patch is backed out.

Patch Installation Instructions For HP-UX Systems

To install or remove the HP-UX patch, use the swinstall and swremove commands. For example, to install the patch to a standalone system:

# swinstall /var/spool/patch/126371-09

Or, to remove the patch from a standalone system:

# swremove 126371-09

For information about the swinstall and swremove commands, refer to the swinstall and swremove man pages.

After you install or remove the patch, you must re-deploy the Access Manager applications as described in the Post-Installation Considerations section.

After you re-deploy the Access Manager applications, execute the updateschema.sh script (patch 5 and later patches) to load the XML and LDIF files. The updateschema.sh script is available after you install patch 11 in the patch-home-directory/120956-09/scripts directory. After you run the amconfig and updateschema.sh scripts, restart the Access Manager web container.

Note: If you remove the patch, the schema changes added by the updateschema.sh script are not removed from Directory Server. However, you do not need to remove these schema changes manually because they will not affect Access Manager functionality or usability after the patch is removed.

For more information about deploying Access Manager on HP-UX systems, see the Sun Java System Access Manager 7 2005Q4 Release Notes for HP-UX.

Post-Installation Considerations

Considerations after you install an Access Manager 7 2005Q4 patch include:

CR# 6254355: Access Manager patches do not deploy Access Manager applications in postpatch scripts

The patch installer might not preserve some of the customized WAR files, replacing them with non-customized versions. To help you identify and then manually update the customized contents of a WAR file, consider the following procedure.

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

On Windows systems, AccessManager-base is javaes-install-directory\AccessManager. For example: C:\Program Files\Sun\AccessManager

The WAR files that get patched are:

These files are located in AccessManager-base/SUNWam on Solaris systems and AccessManager-base/identity on Linux systems.

On Windows systems: the WAR files that get patched are located in AccessManager-base\.

The changeable content in a WAR file includes:

To make sure that all custom changes are preserved, follow these steps. Before you make changes to a file, always backup the file first.

  1. Install the patch.

  2. Expand the WAR files into a temporary directory. For example, with Access Manager installed in the default directory on Solaris systems:

    # cd temporary-directory 
# jar -xvf /opt/SUNWam/console.war
# jar -xvf /opt/SUNWam/services.war
# jar -xvf /opt/SUNWam/password.war

  3. Check the expanded files to see whether the patch installer made any changes to your customized files and manually add your original custom changes to the ones that got changed in the temporary directory. For your changes to the files under the AccessManager-base/web-src/ directory but not included in the patched WAR files, you do not need to redo your changes.

  4. Update the WAR files with the modified files. For example, with Access Manager installed in the default directory on Solaris systems:

    # cd temporary-directory
# jar -uvf /opt/SUNWam/console.war $path/$modified file
# jar -uvf /opt/SUNWam/services.war $path/$modified file
# jar -uvf /opt/SUNWam/password.war $path/$modified file

    For example, for Steps 2-4:

    # mkdir /tmp/war.tmp 
# cd /tmp/war.tmp
# jar -xvf /opt/SUNWam/services.war
# vi index.html
# jar -uvf /opt/SUNWam/services.war index.html

  5. Reuse the silent configuration file (amsilent) generated by the patch or create a new one based on the amsamplesilent template file, and then set the appropriate configuration variables in the file, including:

    • DEPLOY_LEVEL=21

    • DIRECTORY_MODE=5

    • Passwords for DS_DIRMGRPASSWD, ADMINPASSWD, and AMLDAPUSERPASSWD

    • Access Manager Web container variables

    On Windows systems, reuse the silent configuration file (amsilent) generated by the postpatch.pl script and make sure that AccessManager-base\setup\AMConfigurator.properties-tmp has valid values. Then rename this file to AccessManager-base\setup\AMConfigurator.properties.

    For more information about the Web container variables, see the amsamplesilent file in the /opt/SUNWam/bin directory on Solaris systems or the /opt/sun/identity/bin directory on Linux systems.

    On Windows systems, the configuration file is AccessManager-base\setup\AMConfigurator.properties.

  6. Run the amconfig script as shown below. Before you run amconfig, Directory Server and the Access Manager Web container must be running. For example, to run amconfig on a Solaris system, with Access Manager installed in the default base installation directory: 

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

  7. After you run the amconfig script, restart the Access Manager processes. For example:

    # cd /opt/SUNWam/bin
# ./amserver stop
# ./amserver start

  8. Make sure all your customized JSP files reside in the proper subdirectories under the AccessManager-base/SUNWam/web-src/ directory on Solaris systems or the AccessManager-base/identity/web-src/ on Linux systems, and that you have backed up all of your customized files.

    On Windows systems, the files are in AccessManager-base\web-src\.

  9. Restart the Access Manager Web container.

For more information about running the amconfig script, see the: Chapter 1, Access Manager 7 2005Q4 Configuration Scripts, in Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6436409: Redeploying the Distributed Authentication and Client SDK WAR Files

If you are using Distributed Authentication or the Client SDK, recreate and redeploy the Distributed Authentication WAR file and/or the Client SDK WAR file after you install the patch. For information, see the following documents:

Access Manager 7 2005Q4 Patch 11

Access Manager 7 patch 11 (revision 11) fixes a number of problems, as listed in the README file included with the patch. Patch 11 also includes these issues and changes:

CR# 6564877: Access Manager 7 patch installation overwrites SAML v2 files

If the SAML v2 plug-in is installed and you install a new SAML v2 plug-in patch or Access Manager 7 patch, the patch installation overwrites the existing SAML v2 related files, and you must reconfigure your SAML v2 deployment.

Workaround: Run the saml2setup installer with the update option to update a previously configured staging directory with new files from a patch installation directory and to regenerate a modified WAR file for redeployment. The update option prevents the unconfigure and configure routine, which removes your existing SAML v2 files.

Note: The saml2setup installer with the update option is available in the SAML v2 Plug-in for Federation Services patch 1 or later. Therefore, you must add the SAML v2 plug-in patch 1 or later to use this option. Although the update option was first available in patch 1, Oracle recommends that you always install the latest patch. The patch IDs are:

    To use the saml2setup installer with the update option, follow these steps:

  1. Install the new Access Manager or SAML v2 patch.

  2. If you installed an Access Manager patch in Step 1:

    1. Run amconfig to generate a new amserver.war.

    2. Update the SAML v2 staging directory with the new amserver.war.

    3. Reapply any necessary customizations for your deployment.

  3. Run the saml2setup installer with the update option as follows:

    saml2setup update -s installation-configuration-properties-file

  4. Redeploy the modified WAR file.

  5. Restart the Access Manager or Federation Manager web container.

  6. Do any postinstallation tasks required for the Access Manager or Federation Manager instance.

For information about the saml2setup installer, see Chapter 2, Installing the SAML v2 Plug-in for Federation Services, in Sun Java System SAML v2 Plug-in for Federation Services User’s Guide.

CR# 6872718: Persistent XSS attacks are prevented in Access Manager

Patch 11 prevents potential persistent cross-site scripting (XSS) attacks in Access Manager.

CR# 6843487: Access Manager session cookies can be marked as HTTPOnly

Patch 11 includes the new com.sun.identity.cookie.httponly property to allow 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 avoid cross site scripting (XSS) attacks.

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

Access Manager 7 2005Q4 Patch 10

Access Manager 7 patch 10 (revision 10) fixes a number of problems, as listed in the README file included with the patch.

Security Fixes. Patch 10 includes several important security fixes. Oracle recommends that you install patch 10 to prevent from being exposed to these security risks. Refer to the patch README file for a list of these fixes.

Patch 10 also includes these changes:

CR# 6813339: Access Manager reregisters Notification URL after a restart

Access Manager now reregisters the notification URL after a server restart if the following property is set in the server's AMConfig.properties file:

com.sun.identity.agents.reregisterNotificationUrls=true

The default value for this property is false. In a multi-server deployment, set this property for each Access Manager server.

CR#6804391 and CR#6777889 Access Manager SecurID authentication process no longer crashes

On Solaris SPARC systems, the SecurID authentication process (amsecuridd) now avoids crashes because the process no longer writes to a closed connection. These CRs also fix a problem that caused users to be denied access even when authentication was successful. Also, more debug messages are added for better analysis in case other amsecuridd process problems occur.

Access Manager 7 2005Q4 Patch 9

Access Manager 7 patch 9 (revision 09) fixes a number of problems, as listed in the README file included with the patch.

Access Manager 7 2005Q4 Patch 8

Access Manager 7 patch 8 (revision 08) fixes a number of problems, as listed in the README file included with the patch. Patch 8 also includes these changes:

CR# 6668882: Cannot access Console that was installed with upper and lower case characters in domain name

If Access Manager is installed with a domain name that contains both upper and lowercase characters, you cannot log in to the Console. For example, if the domain name is amhost.realm-name.Example.COM, you cannot log in using amhost.realm-name.example.com.

Workaround. There are two workarounds:

First, try logging in using the following URL:

http://amhost.realm-name.example.com:port/amserver/UI/Login?realm=realm-name

Or, add the realm-name to the Realm/DNS aliases:

  1. In the Admin Console, go to Realms, Edit Realm - realm-name.

  2. Add amhost.realm-name.example.com to the Realm/DNS aliases.

  3. Restart the Access Manager server.

  4. Log in using the following URL:

    http://amhost.realm-name.example.com:port/amserver/UI/Login

CR# 6691106: Multiple SiteMonitor threads could be running for checking the same site

The amNaming log sometimes indicates multiple SiteMonitor threads running for checking the same site.

To prevent this problem, patch 8 provides improved synchronization to prevent the creation of the multiple SiteMonitor threads for the same site. Patch 8 also includes these new configuration properties:

The fix for this problem also uses the following property, which was added for patch 5:

The patch does not add these new properties to the AMConfig.properties file. To use these properties with values other than the default values:

  1. For each property that you want to set, add the property and its value to the AMConfig.properties file.

  2. Restart the Access Manager web container for the values to take effect.

CR# 6697260: New property to set policy agent application session idle timeout

Patch 8 includes this new property:

By default, policy agent sessions never expire unless you set this property. To use this new property, add it with the maximum idle timeout value to the AMConfig.properties file and restart the Access Manager web container.

CR# 2151598: Delegation privileges cannot be defined for a filtered role

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

Workaround. After you apply patch 8, 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 Admin Console, the filtered role will appear under the Privileges tab.

Access Manager 7 2005Q4 Patch 7

Access Manager 7 patch 7 (revision 07) fixes a number of problems, as listed in the README file included with the patch.

Patch 7 includes these changes:

CR# 6637806: After restart, Access Manager sent an invalid application SSO token to an agent

After an Access Manager server restart, the Access Manager client SDK now sends a meaningful exception to an agent, so the agent can re-authenticate itself to get a new application session. Previously, after applying Access Manager 7 2005Q4 patch 5, the Access Manager client SDK sent a invalid application SSO token to the agent after an Access Manager server restart.

This problem has been fixed by duplicate CR 6496155. Patch 7 also provides an option (comp.iplanet.dpro.session.dnRestrictionOnly property) to send the application SSO token in a restrictive context. By default, agents send the IP address of the server where they are installed, but if strict DN checking is required, set this property in the AMConfig.properties file as follows:

com.iplanet.dpro.session.dnRestrictionOnly=true

CR# 6612609: Session failover works if network cable is disconnected from Message Queue server

In a session failover deployment, if each Access Manager instance and Message Queue broker are installed on the same server, session failover now works if a network cable is disconnected from one of the servers. By default the Message Queue imqAddressListBehavior connection factory attribute is set to PRIORITY, which causes Message Queue to try addresses in the order in which they appear in the broker address list (for example: localhost:7777,server2:7777,server3:7777). If the attribute is set to RANDOM, the addresses are tried in random order.

To set this attribute to RANDOM, set the following parameter in the amsessiondb script:

-DimqAddressListBehavior=RANDOM

For information about the Message Queue PRIORITY and RANDOM attributes, see Broker Address List in Sun Java System Message Queue 3.7 UR1 Administration Guide.

CR# 6570409: Interaction service behind load balancer works correctly as Identity Provider

In a deployment with two servers connected with a load balancer and functioning as a single Identity Provider, you must set the following properties in the AMConfig.properties file:

com.sun.identity.liberty.interaction.lbWspRedirectHandler
com.sun.identity.liberty.interaction.trustedWspRedirectHandlers

The com.sun.identity.liberty.interaction.interactionConfigClass is the only class currently supported. Thus, by default, the interaction configuration class bundled with Federation Liberty is used to access the interaction configuration parameters.

CR# 6545176: Redirect URLs can be dynamically set in post authentication processing SPI plug-in

Redirect URLs can now be dynamically set in post authentication processing SPI plug-ins for login success, login failure, and logout. If a post processing plug-in is not executed, the redirect URL set in the post processing SPI is not used, and redirect URLs set by any other means will be executed as before.

For information, see the com.iplanet.am.samples.authentication.spi.postprocess.ISAuthPostProcessSample.java sample.

Access Manager 7 2005Q4 Patch 6

Access Manager 7 patch 6 (revision 06) fixes a number of problems, as listed in the README file included with the patch. Patch 6 also includes the following new features, issues, and documentation updates.

New Features in Patch 6

Known Issues and Limitations in Patch 6

Note –

Before you install patch 6, it is recommended that you upgrade or patch the following components:

Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout method

To support the setReadTimeout method, the AMConfig.properties file has the following new property for you to set the read time-out 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.

Access Manager SDK falls back to primary Directory Server after primary comes back up

If Sun Java System Directory Server is configured for multi-master replication (MMR), the Access Manager SDK now falls back to the primary Directory Server after the primary server goes down and then comes back up. Previously, the Access Manager SDK continued to access the secondary Directory Server even after the primary server came back up.

To support this new behavior, Access Manager has the following new property in the AMConfig.properties file:

com.sun.am.ldap.fallback.sleep.minutes

This property sets the time in minutes that a secondary Directory Server instance sleeps before it falls back to the primary server after the primary server comes back up. The default is 15 minutes.

The com.sun.am.ldap.fallback.sleep.minutes property is hidden. To set this property to a value other than the default (15 minutes), explicitly add it to the AMConfig.properties file. For example, to set the value to 7 minutes:

com.sun.am.ldap.fallback.sleep.minutes=7

For the new value to take effect, restart the Access Manager web container.

Multiple Access Manager instances log to separate log files

Multiple Access Manager instances running on the same host server can now log to separate log files in different logging subdirectories by setting the following new property in the AMConfig.properties file:

com.sun.identity.log.logSubdir

Unless you change the default logging directory in the Admin Console, the default logging directories are:

The first Access Manager instance always logs to the default logging directory. To specify different logging subdirectories for additional Access Manager instances, set the com.sun.identity.log.logSubdir property in the AMConfig.properties file for each additional Access Manager instance.

For example, if you have three instances, am-instance-1, am-instance-2, and am-instance-3, all running on the same Solaris host server, set the property as follows:

com.sun.identity.log.logSubdir=am-instance-2
com.sun.identity.log.logSubdir=am-instance-3

The com.sun.identity.log.logSubdir property is hidden. You must explicitly add this property to the AMConfig.properties file as needed and restart the Access Manager web container for subdirectory values to take effect.

The Access Manager instances then log to the following directories:

/var/opt/SUNWam/logs/log-files-for-am-instance-1
/var/opt/SUNWam/logs/am-instance-2/log-files-for-am-instance-2
/var/opt/SUNWam/logs/am-instance-3/log-files-for-am-instance-3

Access Manager 7 allows multiple cookie domains

To support multiple cookie domains, Access Manager has the following new property:

com.sun.identity.authentication.setCookieToAllDomains

The default is true. This new property is hidden. To set the value to false, explicitly add the property to the AMConfig.properties file, and restart the Access Manager web container.

Microsoft IIS 6.0 post-authentication plug-in supports SharePoint Server

The Microsoft Internet Information Services (IIS) 6.0 authentication plug-in now supports the Microsoft Office SharePoint Server. A user can login to Access Manager with either a user ID or login name. SharePoint Server, however, accepts a login name, which causes problems when the user specifies a user ID.

To allow a login to SharePoint Server, the post-authentication plug-in (ReplayPasswd.java) now uses the following new property:

com.sun.am.sharepoint_login_attr_name

This new property indicates the user attribute that SharePoint Server uses for authentication. For example, the following property species the common name (cn) for authentication: 

com.sun.am.sharepoint_login_attr_name=cn

The post-authentication plug-in reads the com.sun.am.sharepoint_login_attr_name property and gets the corresponding attribute value for the user from Directory Server. The plug-in then sets the authorization headers to allow the user to access SharePoint Server.

This property is hidden. To set the property, explicitly add it to the AMConfig.properties file, and then restart the Access Manager web container for the value to take effect.

Access Manager supports Internet Explorer 7

Access Manager 7 2005Q4 patch 6 now supports Microsoft Windows Internet Explorer 7.

CR# 6379325: Accessing Console during session failover throws null pointer exception

In this scenario, multiple Access Manager servers are deployed in session failover mode behind a load balancer configured for cookie-based sticky request routing. The Access Manager administrator accesses the Access Manager Console through the load balancer. When the administrator logs into the Console, the session is created on one of the Access Manager servers. If that server goes down, the Console session fails over to another Access Manager server, as expected. The administrator, however, sometimes experiences intermittent null pointer exceptions on the browser and in the web-container error log.

The issue affects only the active Access Manager Console session at the time of the failover and not the functioning of the Access Manager servers.

Workaround: To prevent these intermittent null pointer exceptions:

CR# 6508103: On Windows, clicking Help in the Admin Console returns an application error

On Windows 2003 Enterprise Edition with Access Manager deployed on Sun Java System Application Server in locales other than English, clicking Help in the Admin Realm Mode Console returns an application error.

Workaround:

  1. Copy the javaes-install-dir\share\lib\jhall.jar file to the %JAVA_HOME%\jre\lib\ext directory.

    where javaes-install-dir is the Windows installation directory

  2. Restart the Application Server instance.

Access Manager 7 2005Q4 Patch 5

Access Manager 7 patch 5 (revision 05) fixes a number of problems, as listed in the README file included with the patch. Patch 5 also includes the following new features, issues, and documentation updates.

New Features in Patch 5

Known Issues and Limitations in Patch 5

Globalization (g11n) Issues

Documentation Updates

Support for HP-UX Systems

Patch 126371 provides support for HP-UX systems. For more information see:

For information about installation on HP-UX systems, see the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

Support for Microsoft Windows Systems

Patch 124296 provides support for Windows systems. For more information see:

For information about installation on Windows systems, see the Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows.

New updateschema.sh script to load LDIF and XML files

Patch 5 (and later) includes the updateschema.sh script to load the following files to update the Directory Server service schema:

In previous Access Manager patch releases, you were required to load these files manually.

To run the updateschema.sh script:

  1. Log in as or become superuser (root).

  2. Change to the patch directory.

  3. Run the script. For example, on Solaris systems:

    # cd /120954-07 
# ./updateschema.sh

    On Windows systems, the script is updateschema.pl.

  4. When the script prompts you, enter these items:

    • Directory Server host name and port number

    • Directory Server admin user DN and password

    • amadmin DN and password

  5. The script validates your entries and then loads the files. The script also writes the following log file:

    • Solaris systems: /var/opt/SUMWam/logs/AM70Patch.upgrade.schema.timestamp

    • Linux systems: /var/opt/sun/identity/logs/AM70Patch.upgrade.schema.timestamp

  6. After the script finishes, restart the Access Manager web container.

Note If you back out patch 5, the schema changes added by the updateschema.sh script are not removed from Directory Server. However, you do not need to remove these schema changes manually because they will not affect Access Manager functionality or usability after the patch is backed out.

Support for specific application idle session timeout values

Patch 5 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.

Requirements to use this feature are:

To use this feature:

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

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.

CDC Servlet can be deployed on a Distributed Authentication UI server

The CDC Servlet can coexist with a Distributed Authentication UI server in the DMZ to enable Cross-Domain Single Sign-On (CDSSO). The Access Manager server can be deployed behind a firewall, and all access to Access Manager to achieve CDSSO is handled by the CDC Servlet in the Distributed Authentication UI server. To enable CDSSO, refer to the specific policy agent documentation and perform these additional steps:

Realm can be specified when CDC servlet redirects to the Access Manager login URL

You can now specify a realm name to the CDC servlet, so that when the redirect to the Access Manager login URL occurs, the realm name is included, and the user can logo into the specific realm. For example:

com.sun.am.policy.agents.config.cdcservlet.url=
    http://lb.example.com/amserver/cdcservlet?org=realm1

Certificate Authentication can use UPN value to map user profile

Previously, Certificate Authentication used only the dn component in the subjectDN to map a user profile. Access Manager now allows the user principal name (UPN) value in SubjectAltNameExt for profile mapping.

Post authentication processing of logout occurs in a multiple-server environment

Post authentication processing now occurs when a user logs out of a different server from the one originally logged into in a multiple-server environment, either with or without session failover configured.

SAML supports a new name identifier SPI

SAML now supports a new name identifier service provider interface (SPI), so that a site can customize the name identifier in the SAML assertion. A site can implement the new NameIdentifierMapper interface to map a user account to a name identifier in the subject of a SAML assertion.

New Configuration Properties for Site Monitoring

The Access Manager site monitoring feature includes the following new properties to allow you to specify the behavior of the site status check.

Property 

Description 

com.sun.identity.urlchecker.invalidate.interval

Time interval in milliseconds for recognizing a down or non-responding site. 

Default: 70000 milliseconds (70 seconds). 

com.sun.identity.urlchecker.sleep.interval

Time interval in milliseconds that the site status check should sleep. 

Default: 30000 milliseconds (30 seconds). 

com.sun.identity.urlchecker.targeturl

Different target URL for checking the Access Manager process status. 

Default: "/amserver/namingservice".

The patch does not add these properties to the AMConfig.properties file. To use these new properties with values other than the default values:

  1. Add the properties and their values to the AMConfig.properties file. For Policy Agents, add these properties to the AMAgents.properties file.

  2. Restart the Access Manager web container for the values to take effect.

User no longer must authenticate twice in authentication chain

Consider the following scenario. A site configures an authentication chain with three LDAP modules. All modules are set to SUFFICIENT, and both the iplanet-am-auth-shared-state-enabled and iplanet-am-auth-store-shared-state-enabled options are set to true. For example:

<AttributeValuePair>
   <Value>A-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>B-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
   <Value>C-LDAP SUFFICIENT iplanet-am-auth-shared-state-enabled=true
iplanet-am-auth-store-shared-state-enabled=true</Value>
</AttributeValuePair>

Patch 5 adds the new iplanet-am-auth-shared-state-behavior-pattern option to the module options with two possible values: tryFirstPass (default) and useFirstPass.

To prevent a user from having to enter the user ID and password twice to get authenticated (as described in the previous scenario), set this new option to useFirstPass for all modules in the chain. Previously, a user who existed only in the third LDAP instance was required to enter a user ID and password twice to get authenticated.

Changes to Performance Tuning Scripts

Patch 5 includes these changes to the performance tuning scripts:

See also CR# 6527663: Default value for com.sun.identity.log.resolveHostName property should be false instead of true.

Tuning scripts support a password file

Patch 5 allows you to specify passwords for the tuning scripts in a text file. Previously, you could enter passwords only as a command-line argument, which could cause security issues. To use a password file, set the following variables, as needed, in the file:

DS_ADMIN_PASSWORD=DirectoryServer-admin-password
AS_ADMIN_PASSWORD=ApplicationServer8-admin-password

For example, to tune Application Server 8:

# ./amtune-as8 password-file

where password-file contains AS_ADMIN_PASSWORD set to the Application Server 8 administrator password.

The tuning scripts use the -j password-file option when they call the ldapmodify, ldapsearch, db2index, and dsconf Directory Server utilities.

Tuning script removes unnecessary ACIs from Directory Server

If Access Manager 7 2005Q4 is installed in Realm Mode, delegation privileges are used to determine access permissions, and therefore some Directory Server ACIs are not needed. Access Manager 7 2005Q4 patch 5 allows you to remove the unnecessary ACIs by running the amtune-prepareDSTuner script. This script reads a list of ACIs from the remacis.ldif file and then calls the ldapmodify utility to remove them.

You can run the amtune-prepareDSTuner script to remove the unnecessary ACIs on Solaris, Linux, HP-UX, and Windows systems. For more information, including how to run the script, see Technical Note: Sun Java System Access Manager ACI Guide.

Tuning scripts can tune the Distributed Authentication UI server web container

After you deploy the Distributed Authentication UI server on a web container, you can tune the web container by running the Access Manager tuning scripts. The following tuning scripts set the JVM and other tuning options for the respective web container:

Table 2 Access Manager Web Container Tuning Scripts

Web Container 

Tuning Script 

amtune-ws61

Web Server 6.1 

amtune-as7

Application Server 7 

amtune-as8

Application Server Enterprise Edition 8.1 

To tune a web container for a Distributed Authentication UI server:

  1. Because Access Manager server is not installed on the system where the Distributed Authentication UI server is deployed, copy the appropriate web container tuning script (shown in the previous table), amtune-env configuration file, and amtune-utils script from an Access Manager server installation. If you want to tune the Solaris or Linux operating system, copy the amtune-os script too.

  2. Edit the parameters in the amtune-env configuration file to specify the web container and tuning options. To run the script in REVIEW mode, set AMTUNE_MODE=REVIEW in the amtune-env file.

  3. Run the web container tuning script in REVIEW mode. In REVIEW mode, the script suggests tuning changes based on values in the amtune-env file but does not make any actual changes to the deployment.

  4. Review the tuning recommendations in the debug log file. If needed, make changes to the amtune-env file based on this run.

  5. To make tuning changes, set AMTUNE_MODE=CHANGE in the amtune-env file.

  6. Run the tuning script in CHANGE mode to make the tuning changes to the deployment.

For more information about running the tuning script to tune an Access Manager web container, see Chapter 2, Access Manager Tuning Scripts, in Sun Java System Access Manager 7 2005Q4 Performance Tuning Guide.

Single amtune-os script tunes both Solaris OS and Linux OS

Patch 5 includes a single amtune-os script to tune both the Solaris OS and Linux OS. The script determines the OS type from the uname -s command. Previously, Access Manager provided separate amtune-os scripts to tune each OS.

Tuning scripts run to completion in a Solaris 10 local zone

If Access Manager is installed in a Solaris 10 local zone, all tuning scripts except amtune-os can run in the local zone. In a local zone, the amtune-os script displays a warning message but does not tune the OS. The script then continues running any other tuning scripts that you have requested. Previously, in a local zone, the amtune-os script would abort, and any subsequent tuning scripts that you requested would not run.

In a Solaris 10 global zone, the amtune script invokes amtune-os to tune the OS as well as any other scripts that you have requested to run.

Tuning scripts are available for Windows systems

Patch 5 includes tuning scripts for Windows systems. Running the tuning scripts on a Windows system is similar to running the scripts on a Solaris system or Linux system, with these differences:

Tuning Considerations for Sun Fire T1000 and T2000 Servers

If Access Manager is installed on a Sun Fire T1000 or T2000 server, the Patch 5 tuning scripts for Web Server 6.1 and Application Server 8 set the JVM GC ParallelGCThreads parameter to 8:

-XX:ParallelGCThreads=8

This parameter reduces the number of garbage collection threads, which could be unnecessarily high on a 32–thread capable system. However, you can increase the value to 16 or even 20 for a 32 virtual CPU machine such as a Sun Fire T1000 or T2000 server, if it minimizes full garbage collection activities.

Also, for Solaris SPARC systems with a CMT processor with CoolThreads technology, in the /etc/opt/SUNWam/config/AMConfig.properties file, it is recommended that you add the following property at the end of the file:

com.sun.am.concurrencyRate=value

The default value is 16, but you can set this property to a lower value, depending on the number of cores in the Sun Fire T1000 or T2000 server.

Basic Authentication in the IIS 6.0 Policy Agent

To enable Basic Authentication in the Microsoft Internet Information Services (IIS) 6.0, the policy agent must obtain the user's name and password. Patch 5 includes the following new classes to enable this functionality using DES encryption of the user's password:

To use the Basic Authentication in IIS 6.0, you must perform steps on both the Access Manager server side and the IIS 6.0 policy agent side.

On the Access Manager server side:

  1. Execute DESGenKey.java to generate a unique encryption key for password encryption and decryption. On Solaris systems, the DESGenKey.java file is located under the com/sun/identity/common directory, included in am_sdk.jar in the /opt/SUNWam/lib directory. For example, the following command generates an encryption key:

    # cd /opt/SUNWam/lib
# java -cp am_sdk.jar com.sun.identity.common.DESGenKey

  2. Assign the encryption key value from Step 1 to the com.sun.am.replaypasswd.key property in the AMConfig.properties file.

  3. Deploy ReplayPasswd.java as a post authentication plug-in. Use the complete class name when you configure the plug-in: com.sun.identity.authentication.spi.ReplayPasswd.

On the IIS 6.0 policy agent side:

  1. Assign the encryption key value from the server side to the com.sun.am.replaypasswd.key property in the AMAgent.properties file. Both the Access Manager server and the IIS 6.0 policy agent must use the same encryption key.

  2. Enable Basic Authentication in IIS 6.0 Manager.

The IIS 6.0 policy agent reads the encrypted password from the session response, decrypts the password from the com.sun.am.replaypasswd.key property, and sets the authentication headers, to allow the Basic Authentication to work.

For information about the IIS 6.0 policy agent, see the Sun Java System Access Manager Policy Agent 2.2 Guide for Microsoft Internet Information Services 6.0.

CR# 6567746: On HP-UX systems, Access Manager patch 5 reports incorrect errorCode value if password retry count is exceeded

When a user's account is locked, Access Manager 7 2005Q4 patch 5 on HP-UX systems reports errorCode = null instead of errorCode = 107 if the password retry count is exceeded.

Workaround. None.

CR# 6527663: Default value for com.sun.identity.log.resolveHostName property should be false instead of true

Before you run the amtune-identity tuning script, it is recommended that you add the following property set to false to the AMConfig.properties file:

com.sun.identity.log.resolveHostName=false

A value of false minimizes the impact of resolving host names and thus can improve performance. However, if you want the client machine's hostname to be printed in the amAuthentication.access log, set the value to true.

CR# 6527528: Patch removal leaves XML files with amldapuser password in clear text

If you remove patch 5 from an Access Manager full server installation, the amAuthLDAP.xml and amPolicyConfig.xml files contain the amldapuser password in clear text. These files are in the following directory, depending on your platform:

Workaround: Edit the amAuthLDAP.xml and amPolicyConfig.xml files and delete the clear text password.

CR# 6527516: Full server on WebLogic requires JAX-RPC 1.0 JAR files to communicate with client SDK

In Access Manager 7 2005Q4 patches, the Access Manager configuration script for BEA WebLogic Server (amwl81config) adds the JAX-RPC 1.1 JAR files to the classpath for the WebLogic instance. While this modification is beneficial to products such as Sun Java System Portal Server, a full server installation (DEPLOY_LEVEL=1) deployed on WebLogic Server cannot communicate with a client SDK installation, and exceptions will subsequently occur.

If Access Manager 7 2005Q4 server is installed on BEA WebLogic Server, the CLASSPATH in the startWebLogic.sh script must be set to the location of the JAX-RPC 1.0 JAR files to communicate with Access Manager client SDK.

Workaround: Before applying the Access Manager patch, set the CLASSPATH in the startWebLogic.sh script for the WebLogic Server instance to use the JAX-RPC 1.0 JAR files instead of the JAX-RPC 1.1 JAR files:

  1. On the Access Manager server, login as or become superuser (root).

  2. Edit the startWebLogic.sh script and replace the CLASSPATH to use the JAX-RPC 1.0 JAR files. For example:

Current value:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-spi.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-impl.jar:

New value:

CLASSPATH=/etc/opt/SUNWam/config:
AccessManager-base/AccessManager-package-dir/lib/jax-qname.jar:
AccessManager-base/AccessManager-package-dir/lib/namespace.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc_1.0/jaxrpc-api.jar:
AccessManager-base/AccessManager-package-dir/lib/jaxrpc-ri.jar:

where AccessManager-base is the base installation directory. The default value is /opt on Solaris systems and /opt/sun on Linux and HP-UX systems. AccessManager-package-dir is the Access Manager package directory.

5. Restart the WebLogic Server instance.

CR # 6523499: Patch 5 amsilent file is readable by all users on Linux systems

On Linux systems. the postpatch script creates the /opt/sun/identity/amsilent file with permissions of 644, which allows read access by all users.

Workaround: After executing the installpatch script, change the permissions on the amsilent file to allow read and write access only to the owner. For example:

# chmod 600 /opt/sun/identity/amsilent

CR# 6520326: Applying patch 5 to a second Access Manager instance on a server overwrites serverconfig.xml for first instance

In this deployment scenario, two Access Manager instances are deployed on the same host server, with each instance on a different web container instance. You then follow these steps:

  1. Apply patch 5.

  2. Modify the amsilent file and redeploy the first Access Manager instance.

  3. Modify the amsilent again for the second Access Manager instance, and then redeploy that instance.

If NEW_INSTANCE=false in the amsilent file, the serverconfig.xml file for the first Access Manager instance is overwritten with information from the second Access Manager instance. A subsequent restart of the first Access Manager instance fails. The serverconfig.xml file is in the following directory depending on your platform:

Workaround: When you deploy the second Access Manager, set NEW_INSTANCE=true in the amsilent file. The serverconfig.xml file for the second Access Manager instance is then updated with the correct information, and the serverconfig.xml file for the first Access Manager instance is not overwritten.

CR# 6520016: Patch 5 SDK-only install overwrites the samples makefiles

Applying patch 5 to an SDK-only machine overwrites the samples makefiles.

Workaround: Applying patch 5 to an SDK-only machine does not require a reconfiguration; however, if you want to use the samples makefiles, follow these steps to update the LDIF and properties files (that is, perform tag swapping) for the samples makefiles:

  1. Run the amconfig script with DEPLOY_LEVEL=14 to uninstall the SDK and unconfigure the web container.

  2. Run the amconfig script with DEPLOY_LEVEL=4 to re-install the SDK and reconfigure the web container.

CR#6515502: LDAPv3 repository plug-in does not always handle Alias Search Attribute correctly

For most searches, this problem has been fixed. However, be careful when setting the Alias Search Attribute. The value of the alias search attributes must be unique across an organization. If more than one alias search attribute is set, it is possible that one entry in the data store matches one attribute, and another entry matches with the other attribute. In this situation, Access Manager server throws the following error:

An internal authentication error has occurred. Contact your system administrator.

Workaround: None

CR# 6515383: Distributed Authentication and J2EE agent do not work in same web container

A Distributed Authentication UI server and a J2EE policy agent do not work if they are installed in the same web container.

Workaround: Create a second web container instance and deploy the Distributed Authentication UI server and J2EE policy agent on different instances of the container.

CR# 6508103: Online help returns application error with Application Server on Windows systems

If you deploy Access Manager on Sun Java System Application Server on a Windows system, clicking Help in the left panel of the help screen for the Realm Mode console returns an application error.

Workaround: Copy the javaes-install-dir\share\lib\jhall.jar file to the JAVA_HOME\jre\lib\ext directory and then restart Application Server.

CR# 6507383 and CR# 6507377: Distributed Authentication requires explicit goto URL parameter

If an explicit goto URL parameter is not specified, a Distributed Authentication UI server attempts to redirect to the goto on a success URL specified in Access Manager. This redirect can fail for these reasons:

Workaround: Always specify an explicit goto URL parameter for a Distributed Authentication UI server.

CR# 6402167: LDAP JDK 4.18 causes LDAP client/Directory Server problems

Access Manager 7 2005Q4 was released with LDAP JDK 4.18 as part of the Java ES 2005Q4 release, which resulted in a number of Access Manager and Directory Server connection problems.

Workaround: Apply one of the following Sun Java System LDAP Java Development Kit patches:

The patches are available on SunSolve Online: http://sunsolve.sun.com.

CR# 6352135: Distributed Authentication UI server files are installed in incorrect location

On Solaris systems, the Java ES installer installs the Distributed Authentication UI server Makefile.distAuthUI, README.distAuthUI, and amauthdistui.war files in an incorrect location: /opt/SUNComm/SUNWam.

Workaround: Copy these files to their correct location: /opt/SUNWam.

Note: Any Distributed Authentication UI server problems fixed in a patch will go into the /opt/SUNComm/SUNWam/amauthdistui.war file, so whenever you apply a patch to the Access Manager server and then rebuild and deploy the WAR file, you must also copy these files to the /opt/SUNWam directory.

CR# 6522720: Search in console online help does not work for multibyte characters on Windows and HP-UX systems

If Access Manager is installed in a locale that uses multibyte characters (such as Japanese) on a Windows or HP-UX system, a search in the console online help with keywords entered using multibyte characters does not work.

Workaround: None

Patch 6 update: Access Manager 7 2005Q4 patch 6 fixes this problem on Windows systems. However, the problem still exists on HP-UX systems.

CR# 6524251: Multibyte characters in output messages are garbled during Access Manager configuration on Windows systems

If Access Manager is installed in a locale that uses multibyte characters (such as Japanese or Chinese) on a Windows system, during Access Manager configuration, words are garbled in output messages at the terminal window.

Workaround: None, but this problem does not affect the configuration itself.

CR# 6526940: Property keys appear instead of message text during patch 5 installation in non-English locales on Windows systems

If you install patch 5 (124296-05) in a non-English locale on a Windows system, some strings in the install panels appear as property keys instead of the actual message text. Examples of property keys are PRODUCT_NAME, JES_Patch_FinishPanel_Text1, and JES_Patch_FinishPanel_Text2.

Workaround: None

CR# 6513653: Issue with com.iplanet.am.session.purgedelay property setting

The Access Manager amtune script sets the com.iplanet.am.session.purgedelay property to 1, in order to allow as many Access Manager sessions as possible. This property specifies the number of minutes to delay the purge session operation. For clients such as Sun Java System Portal Server, however, a value of 1 might not be sufficient.

Workaround: Reset the com.iplanet.am.session.purgedelay property after you run the amtune script:

  1. In the AMConfig.properties file, set the property to the new value. For example:

    com.iplanet.am.session.purgedelay=5

  2. Restart the Access Manager web container for the new value to take effect.

Access Manager 7 2005Q4 Patch 4

Access Manager 7 2005Q4 patch 4 (revision 04) fixes the following problems:

Known Issues and Limitations in Patch 4

CR# 6470055: Distributed Authentication UI server performance improvement

To improve performance in reading, searching, and comparing user attributes for a Distributed Authentication UI server user, follow these steps:

  1. In the Makefile.distAuthUI file, change the application user name from anonymous to another user. For example: 

    APPLICATION_USERNAME=user1

  2. In Directory Server, add the new user (user1 in the example) and ACI to allow reading, searching, and comparing user attributes. The following example adds the new ACI:

    dn:ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com 
changetype:modify add:aci 
aci: (target="ldap:///ou=1.0,ou=SunAMClientData,ou=ClientData,dc=example,dc=com")
(targetattr = *")(version 3.0; 
acl "SunAM client data access to a Distributed Auth App User"; 
allow (read, search, compare) 
userdn =  "ldap:///uid=user1,ou=people,dc=example,dc=com";)

CR# 6455079: Password reset service reports notification errors when a password is changed

When a password is changed, Access Manager submits the email notification using the unqualified sender name Identity-Server, which results in error entries in the amPasswordReset logs. For example:

07/19/2006 10:26:04:010 AM PDT: Thread[service-j2ee,5,main]
ERROR: Could not send email to user [Ljava.lang.String;@999262
com.sun.mail.smtp.SMTPSendFailedException: 553 5.5.4 <Identity-Server>...
Domain name required for sender address Identity-Server

Workaround: Change the from address to include the fully qualified domain name of the host server in the amPasswordResetModuleMsgs.properties file:

  1. Change the from address label. For example:

    fromAddress.label=<Identity-Server@amhost.example.com>

  2. Change the lockOutEmailFrom property to insure that lockout notifications use the correct from address. For example:

    lockOutEmailFrom=<Identity-Server@amhost.example.com>

    The amPasswordResetModuleMsgs.properties file is in the AccessManager-base/SUNWam/locale directory on Solaris systems and the AccessManager-base/identity/locale directory on Linux systems.

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

Access Manager 7 2005Q4 Patch 3

Access Manager 7 patch 3 (revision 03) fixes a number of problems, as listed in the README file included with the patch. Patch 3 also includes the following new features and known issues:

New Features in Patch 3

Known Issues and Limitations in Patch 3

New Configuration Properties for Site Monitoring

The Access Manager site monitoring feature includes these new properties:

Property 

Description 

com.sun.identity.sitemonitor.interval

Interval time in milliseconds for site monitoring. The site monitoring feature checks each site's availability within the specified time interval. Default: 60000 milliseconds (1 minute). 

com.sun.identity.sitemonitor.timeout

Timeout in milliseconds for site availability checking. The site monitoring feature waits for the specified timeout value for a response from the site. Default: 5000 milliseconds (5 seconds).  

The patch does not add these properties to the AMConfig.properties file. To use these new properties with values other than the default values:

  1. Add the properties and their values to the AMConfig.properties file in the following directory, depending on your platform:

    • Solaris systems: /etc/opt/SUNWam/config

    • Linux systems: /etc/opt/sun/identity/config

    For Policy Agents, add these properties to the AMAgents.properties file.

  2. Restart the Access Manager Web container for the values to take effect.

Custom implementation. In addition, the com.sun.identity.sitemonitor.SiteStatusCheck class allows you to customize your own implementation for checking site availability using the following interface:

package com.iplanet.services.naming.WebtopNaming$SiteStatusCheck

Each implementation class must use the doCheckSiteStatus method.

public interface SiteStatusCheck { 
public boolean doCheckSiteStatus(URL siteurl);
}

Liberty Identity Web Services Framework (ID-WSF) 1.1 Support

The default version of ID-WSF in Access Manager 7 patch 3 is WSF1.1. There is no separate configuration needed to trigger the ID-WSF, except that the samples need to use the new security mechanisms. The new security mechanisms for the ID-WSF1.1 are:

urn:liberty:security:2005-02:null:X509
urn:liberty:security:2005-02:TLS:X509
urn:liberty:security:2005-02:ClientTLS:X509
urn:liberty:security:2005-02:null:SAML
urn:liberty:security:2005-02:TLS:SAML
urn:liberty:security:2005-02:ClientTLS:SAML
urn:liberty:security:2005-02:null:Bearer
urn:liberty:security:2005-02:TLS:Bearer
urn:liberty:security:2005-02:ClientTLS:Bearer

New Property for Liberty ID-WSF Support

The com.sun.identity.liberty.wsf.version property determines the Liberty ID-WSF framework when the framework cannot determine from the in-bound message or from the resource offering when Access Manager is acting as the WSC. Values can be 1.0 or 1.1. The default is 1.1.

Note The patch installation does not add the com.sun.identity.liberty.wsf.version property to the AMConfig.properties file (CR# 6458184). To use this new property, add it to the AMConfig.properties file with the appropriate value after you install the patch and then restart the Access Manager Web container.

After Access Manager 7 patch 3 is installed, run the following command to load the schema changes, shown with Access Manager installed in the default directory on Solaris systems:

# /opt/SUNWam/bin/amadmin -u amadmin -w amadmin_password 
-t /etc/opt/SUNWam/wsf1.1_upgrade.xml

The ID-WSF discovery registration can use these new security mechanisms when registering. Also, WSCs will automatically detect which version to use while communicating to WSPs. To configure for ID-WSF1.1, follow the Readme files for the Liberty ID-FF sample1 and the ID-WSF samples that are included with the product.

CR# 6463779 Distributed Authentication amProfile_Client log and Access Manager server amProfile_Server log are filled with harmless exceptions

Requests to Access Manager server via a Distributed Authentication UI triggers exceptions in the distAuth/amProfile_Client log and the Access Manager server debug/amProfile_Server log. After numerous sessions, the amProfile_Client log can grow to several gigabytes, and the Access Manager server amProfile_Server log can grow to several megabytes. No loss of functionality is caused by these exceptions in the logs, but they can cause a false alarm for users, and potentially the logs can fill up the hard disk space.

Workaround. Run cron jobs that will make the contents of the log files null. For example:

CR# 6460974 Default Distributed Authentication Application User should not be amadmin

If you are deploying a Distributed Authentication UI server, the Distributed Authentication administrator should not be amadmin. The default Distributed Authentication Application User in the Makefile.distAuthUI file is amadmin and subsequently in the AMConfig.properties file after the distAuth.war file is deployed on the client side. The amadmin user has an AppSSOToken that expires after the amadmin session time runs out, which can cause a FATAL ERROR in the amSecurity log file (located by default in the /tmp/distAuth directory).

Workaround. Specify UrlAccessAgent as the Distributed Authentication Application User. For example:

Before deploying the distAuth.war file in the client Web container, change the following parameters in the Makefile.distAuthUI file:

APPLICATION_USERNAME=UrlAccessAgent
APPLICATION_PASSWORD=shared-secret-password or amldapuser-password

or

After deploying the distAuth.war file in the client Web container, change the following properties in the AMConfig.properties file for each Access Manager server:

com.sun.identity.agents.app.username=UrlAccessAgent
com.iplanet.am.service.password=shared-secret-password or amldapuser-password

See also CR# 6440697: Distributed Authentication should run as non-amadmin user.

CR# 6460576 No link for the User Service under Filtered Role in console online Help

The Access Manager Console online Help does not have a link for the User Service under Filtered Role. In the online Help, go to Contents, Filtered Role, and “To Create a Filtered Role”. Page down and, depending on the identity type you selected, a list of services is displayed, but a User Service link is not available.

Workaround. None

CR# 6460085 Server on WebSphere is not accessible after running reinstallRTM and redeploying Web applications

After applying Access Manager 7 patch 3 for a DEPLOY_LEVEL=1 deployment on IBM WebSphere Application Server 5.1.1.6 on Red Hat Linux AS 3.0 Update 4, the reinstallRTM script was run to restore the RTM RPMs. The Web applications were then redeployed after editing the amsilent file generated by the reinstallRTM script. WebSphere was restarted using the stopServer.sh and startServer.sh scripts. When accessing the login page, however, WebSphere displayed a 500 error, related to the amlcontroller filter.

This problem occurred because the new server.xml file generated by the reinstallRTM script was corrupt.

Workaround. The server.xml file backed up by the amconfig script is still valid. Use this previous copy, as follows:

  1. Stop the server.

  2. Replace the corrupted server.xml with the copy that was backed up by the amconfig script.

    The server.xml file that was backed up by the amconfig script will have the name server.xml-orig-pid, where pid is the process ID of the amwas51config script. The file is located in this directory:

    WebSphere-home-directory/config/cells/WebSphere-cell
/nodes/WebSphere-node/servers/server-name

  3. Restart the server.

CR# 6455757: sunISManagerOrganization marker class must be added to an organization before an upgrade

An organization in an Access Manager DIT that was created before the Access Manager 7 release might not have the sunISManagerOrganization object class. Also, an organization created by a product other than Access Manager will not have the sunISManagerOrganization object class in its definition.

Workaround. Before you upgrade to Access Manager 7 2005Q4, make sure that all organizations in the DIT have the sunISManagerOrganization object class in their definition. If necessary, manually add this object class before you upgrade.

CR# 6454489: Access Manager 7 2005Q4 Patch 2 upgrade causes an error in the Console Current Sessions tab

An upgrade caused the following error on the Current Sessions tab in the Access Manager Console:

Failed to get valid Sessions from the Specified server

This problem applies to deployments that are upgrading from Access Manager 6 versions that have a root suffix of the form o=orgname.

Workaround. After installing Manager 7 2005Q4, apply Manager 7 Patch 3 and then run the amupgrade script to migrate the data, as follows:

  1. Backup your Access Manager 6 DIT.

  2. Run the ampre70upgrade script.

  3. Install Access Manager 7 2005Q4 with the Configure Later option.

  4. Undeploy the Access Manager Web applications.

  5. Deploy the Access Manager Web applications.

  6. Apply Access Manager 7 patch 3, but don't apply the XML/LDIF changes. The XML/LDIF changes must be applied after running the amupgrade script in the next step.

  7. Run the amupgrade script.

  8. Redeploy the Access Manager Web applications, because of the Access Manager 7 patch 3 changes.

  9. Access the Access Manager Console.

CR# 6452320: Exceptions are thrown when using polling with client SDK

When you deploy the Access Manager client SDK (amclientsdk.jar) and enable polling, errors such as the following can occur:

ERROR: Send Polling Error:
com.iplanet.am.util.ThreadPoolException: 
amSessionPoller thread pool's task queue is full.

Such errors can occur after you deploy a Distributed Authentication UI server, J2EE agents, or in any situation where you deploy the Access Manager client SDK on a client machine.

Workaround. If you have only a few hundred concurrent sessions, add following properties and values in either the AMConfig.properties file or the AMAgents.properties file:

com.sun.identity.session.polling.threadpool.size=10
com.sun.identity.session.polling.threadpool.threshold=10000

For thousands or tens of thousands of sessions, the values should be set the same as those for notification in the Access Manager AMConfig.properties file after running the amtune-identity script. For example, for a machine with 4 GB of RAM, the Access Manager amtune-identity script sets the following values:

com.sun.identity.session.notification.threadpool.size=28
com.sun.identity.session.notification.threadpool.threshold=76288

Set similar values on the client side in the AMAgent.properties or AMConfig.properties file when the Distributed Authentication UI server or the Access Manager client SDK is deployed on a client machine with 4 GB of RAM.

CR# 6442905 SSOToken of authenticated user can be unintentionally revealed to rogue sites

An authenticated Access Manager user can unintentionally reveal the SSOToken to a rogue site by clicking on a URL from the rogue site.

Workaround. Always create a unique agent user profile in Access Manger for all participating Policy Agents to make sure that the site is not rogue. Also, make sure that none of these unique agent users use the same password as the shared secret password or amldapuser password. By default, Policy Agents are authenticated to the Access Manager Application authentication module as the UrlAccessAgent user.

For more information about creating an agent using the Access Manager Admin Console, see Agents in Sun Java System Access Manager 7 2005Q4 Administration Guide.

CR# 6441918: Site monitor interval and time-out properties

Access Manager site failover includes the following new properties:

com.sun.identity.sitemonitor.interval
com.sun.identity.sitemonitor.timeout

For more information, see New Configuration Properties for Site Monitoring.

CR# 6440697: Distributed Authentication should run as non-amadmin user

To create a Distributed Authentication administrator other than the default administrative user (amadmin) for Distributed Authentication application authentication, follow this procedure:

  1. Create an LDAP user for the Distributed Authentication administrator. For example:

    uid=DistAuthAdmin,ou=people,o=am

  2. Add the Distributed Authentication administrator to the list of special users. For example:

    com.sun.identity.authentication.special.users=cn=dsameuser,
ou=DSAME Users,o=am|cn=amService-UrlAccessAgent,ou=DSAME Users,
o=am|uid=DistAuthAdmin,ou=People,o=am

    Add this property to the AMConfig.properties file of all Access Manager servers, so that the Distributed Authentication administrator's AppSSOToken does not expire when the session expires.

CR# 6440695: Distributed Authentication UI servers with a load balancer

If your deployment includes a load balancer in front of multiple Distributed Authentication UI servers, set the following properties in the AMConfig.properties file after you deploy the WAR file.

com.iplanet.am.lbcookie.name=DistAuthLBCookieName
com.iplanet.am.lbcookie.value=DistAuthLBCookieValue

CR# 6440651: Cookie replay requires com.sun.identity.session.resetLBCookie property

For cookie replaying to work properly for Access Manager session failover, add the com.sun.identity.session.resetLBCookie property with a value of true for both the Policy Agent and the Access Manager server. For example:

com.sun.identity.session.resetLBCookie='true'

Note: This property is required only if you have implemented Access Manager session failover.

CR# 6440648: com.iplanet.am.lbcookie.name property assumes default value of amlbcookie

By default, a Policy Agent and Access Manager servers assume a load balancer cookie name of amlbcookie. If you change the name of the cookie on the back-end server, you must use the same name in the AMAgent.properties file for the Policy Agent. Also, if you are using the Access Manager client SDK, you must also use the same cookie name used by the back-end server.

CR# 6440641: com.iplanet.am.lbcookie.value property is deprecated

Access Manager no longer supports the com.iplanet.am.lbcookie.value property on servers to customize the load balancer cookie. Instead, Access Manager now uses the server ID, which is configured as part of session configuration, for the cookie value and for the name to be replayed by the agent.

CR# 6429610: Unable to create SSO token in ID-FF SSO use case

After setting up the Liberty Identity Federation Framework (ID-FF) sample 1, Federation succeeded, but SSO failed.

Workaround. Add the uuid of dsameuser to the com.sun.identity.authentication.special.users property in the AMConfig.properties file. For application authentication, dsameuser needs a non-expiring SSO token for the Access Manager server.

CR# 6389564: Repetitious successive queries on role memberships of user in an LDAP v3 data store during Access Manager login

When a user logs into Access Manager, repetitive LDAP searches on the user's nsRoleDN attribute occur.

Workaround. After the Access Manager 7 patch 3 is installed, run the following command shown with Access Manager installed in the default directory on Solaris systems:

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/idRepoServiceAddAttrSchemaRequest_Cache.xml

CR# 6385185: Authentication module must be able to override the “goto” URL and specify a different URL

An authentication module can override the “goto” URL and request re-direction to a different URL of an external Web site to get the user status validated.

To override the “goto” URL after the authentication is complete, set the property shown in the following example in the SSOToken. You set this property using the onLoginSuccess method of the PostProcess class implementing the AMPostAuthProcessInterface. For example, OverridingURL is the URL that overrides the “goto”URL:

public class <..> implements AMPostAuthProcessInterface {  
...
    public void onLoginSuccess(...) {
        try {
            ssoToken.setProperty("PostProcessSuccessURL", OverridingURL);
         } catch (Exception ...) {
         ...         }
...
}

CR# 6385184: Re-direct from within a custom authentication module when SSO Token is still in invalid state

New RedirectCallback for custom authentication module allows redirection to an external Web site via the Authentication UI to get a user validated. If the authentication is successful, the user is then redirected back to the original Access Manager server URL. Sample files include:

To implement this feature:

  1. Create a custom authentication module using the sample LoginModuleSample.java.

  2. Load the module into an Access Manager server.

  3. Construct the RedirectCallback in the XML file using the sample LoginModuleSample.xml.

  4. To test the module, use the sample testExtWebSite.jsp file for the external Web site.

  5. Login using this URL:

    http://example.com/amserver/UI/Login?module=LoginModuleSample

The user name and password are redirected to the external Web site for validation. If the name and password are valid, the authentication is successful and the user is then redirected back to the original Access Manager server URL.

For example, consider this scenario, where the deployment is using a custom authentication module to access a provisioning/credit card site:

  1. A user invokes the authentication process/login page for the custom authentication module.

  2. The user enters the credentials (user name and password) and submits a request to the custom authentication module.

  3. The custom authentication module redirects the user to an external provisioning/credit card site with the required user information along with the request.

  4. The external provisioning/credit card site checks the user's status and returns the request with either success or failure, which is set as part of the returned request.

  5. The custom authentication module validates the user based on the status returned in Step 4 and returns the corresponding status to the authentication service.

  6. The user authentication completes with either success or failure.

CR# 6324056: Federation fails when using artifact profile

Workaround: To fix this problem, apply latest version of the “Core Mobile Access” patch, depending on your platform:

After applying the patch, restart the Web container.

Access Manager 7 2005Q4 Patch 2

Access Manager 7 2005Q4 patch 2 (revision 02) fixed a number of problems, as listed in the README file included with the patch. Patch 2 also includes the following new features and known issues:

New Features in Patch 2

Known Issues and Limitations in Patch 2

New Properties for the User Management, Identity Repository, and Service Management Caches

Patch 2 includes the following new properties for the User Management (Access Manager SDK), Identity Repository (IdRepo), and Service Management caches. These properties allow you to enable and disable the different caches independently, based on your deployment requirements, and to set the time to live (TTL) for the cache entries.

Table 3 New Properties for the User Management, Identity Repository, and Service Management Caches

Property 

Description 

New Properties to Enable and Disable Caches

com.iplanet.am.sdk.caching.enabled

Global property that enables (true) or disables (false) the Identity Repository (IdRepo), User Management, and Service Management caches. If true, or if the property is not present in the AMConfig.properties file, all three caches are enabled.

Note The following three properties to enable or disable the specific caches apply only if the previous global property is set to false.

com.sun.identity.amsdk.cache.enabled

Enables (true) or disables (false) only the User Management (Access Manager SDK) cache. 

com.sun.identity.idm.cache.enabled

Enables (true) or disables (false) only the Identity Repository (IdRepo) cache. 

com.sun.identity.sm.cache.enabled

Enables (true) or disables (false) only the Service Management cache. 

New User Management Cache Properties for TTL

com.iplanet.am.sdk.cache.entry.expire.enabled

Enables (true) or disables (false) the expiration time (as defined by the following two properties) for the User Management cache. 

com.iplanet.am.sdk.cache.entry.user.expire.time

Specifies the time in minutes that user entries for the User Management cache remain valid after their last modification. That is, after this specified time elapses (after the last modification or read from the directory), the data for the entry that is cached will expire. Then, new requests for data for these entries must be read from the directory. 

com.iplanet.am.sdk.cache.entry.default.expire.time

Specifies the time in minutes that non-user entries for the User Management cache remain valid after their last modification. That is, after this specified time elapses (after the last modification or read from the directory), the data for the entry that is cached will expire. Then, new requests for data for these entries must be read from the directory. New Identity Repository Cache Properties for TTL  

com.sun.identity.idm.cache.entry.expire.enabled

Enables (true) or disables (false) the expiration time (as defined by the following property) for the IdRepo cache.  

com.sun.identity.idm.cache.entry.default.expire.time

Specifies the time in minutes that non-user entries for the IdRepo cache remain valid after their last modification. That is, after this specified time elapses (after the last modification or read from the repository), the data for the entry that is cached will expire. Then, new requests for data for these entries must be read from the repository. 

Using the New Caching Properties

The Access Manager 7 2005Q4 patches do not automatically add the new caching properties to the AMConfig.properties file.

To use the new caching properties:

  1. With a text editor, add the properties and their values to the AMConfig.properties file in the following directory, depending on your platform:

    • Solaris systems: /etc/opt/SUNWam/config

    • Linux systems: /etc/opt/sun/identity/config

  2. Restart the Access Manager Web container for the values to take effect.

New Property for Federation Service Provider

The new com.sun.identity.federation.spadapter property defines the implementation class for com.sun.identity.federation.plugins.FederationSPAdapter, which is used to add application specific processing during Federation processing on the Service Provider side.

See also CR# 6385696: Existing and new IDPs and SPs are not visible.

LDAP Filter Condition Support

LDAP Filter Condition support is added in patch 2. A policy administrator can now specify an LDAP filter in the Condition while defining a policy. The Policy is applied to the user only if the LDAP entry of the user satisfies the LDAP filter specified in the Condition. The LDAP entry of the user is looked up from the directory specified in the Policy Configuration service.

To register and use the LDAP Filter Condition, run following commands after the Access Manager 7 patch 2 is installed shown with Access Manager installed in the default directory on Solaris systems:

# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-s /etc/opt/SUNWam/AddLDAPFilterCondition.xml
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/amPolicyConfig_mod_ldfc.xml

Patch 5 Note If you added Access Manager 7 2005Q4 Patch 5 and ran the updateschema.sh script, you do not need to load these files using amadmin. For more information see New updateschema.sh script to load LDIF and XML files.

CR# 6283582: Num of login failures are not shared across Access Manager instances

After Access Manager 7 patch 2 is installed, run following commands, shown with Access Manager installed in the default directory in Solaris systems:

# cd DirectoryServer-base/shared/bin
# ./ldapmodify -h DirectoryServerHost -p DirectoryServerPort 
-D "cn=Directory Manager" -w DirectoryMangerPassword 
-a -f /etc/opt/SUNWam/accountLockout.ldif
# /opt/SUNWam/bin/amadmin -u amadmin 
-w amadmin_password 
-t /etc/opt/SUNWam/accountLockoutData.xml

The default value of DirectoryServer-base is /var/opt/mps/serverroot on Solaris systems and /var/opt/sun/directory-server on Linux systems.

Patch 5 Note If you added Access Manager 7 2005Q4 Patch 5 and ran the updateschema.sh script, you do not need to load these files using amadmin. For more information see New updateschema.sh script to load LDIF and XML files.

CR# 6293673: Need to retain the original session information when sending out session timeout notification

The new com.sun.identity.session.property.doNotTrimList property in the AMConfig.properties file can contain list of comma separated session property names. Once a session is timed out, the properties defined in this list will not be trimmed off, so that they can be accessed before the session is purged. For example:

com.sun.identity.session.property.doNotTrimList=UserId,HostName

CR# 6244578: Access Manager should warn user that the browser cookie support is disabled/not available

The new com.sun.identity.am.cookie.check property in the AMConfig.properties file indicates whether the server should check for the cookie support / cookie enabled in the browser. A value of true causes the server to check for the cookie support / cookie enabled in the browser and to throw an error page if the browser does not support or has not enabled cookies. This value should be set to false (which is the default) if the server is expected to support cookie-less mode for authentication functionality.

CR# 6236892: Image/Text place holder while CDCServlet is processing the AuthNResponse after login

The following new properties are added to AMConfig.properties file and are read by the CDCServlet:

CR# 6363157: New property disables persistent searches if absolutely required

The new com.sun.am.event.connection.disable.list property in the AMConfig.properties file specifies which event connection can be disabled. Values (case insensitive) can be:

aci - Changes to the aci attribute, with the search using the LDAP filter (aci=*)

sm - Changes in the Access Manager information tree (or service management node), which includes objects with the sunService or sunServiceComponent marker object class. For example, you might create a policy to define access privileges for a protected resource, or you might modify the rules, subjects, conditions, or response providers for an existing policy.

um - Changes in the user directory (or user management node). For example, you might change a user's name or address.

For example, to disable persistent searches for changes to the Access Manager information tree (or service management node):

com.sun.am.event.connection.disable.list=sm

To specify multiple values, separate each value with a comma.

Caution – Caution –

Persistent searches cause some performance overhead on Directory Server. If you determine that removing some of this performance overhead is absolutely critical in a production environment, you can disable one or more persistent searches using the com.sun.am.event.connection.disable.list property.

However, before disabling a persistent search, you should understand the limitations described above. It is strongly recommended that this property not be changed unless absolutely required. This property was introduced primarily to avoid overhead on Directory Server when multiple 2.1 J2EE agents are used, because each of these agents establishes these persistent searches. The 2.2 J2EE agents no longer establish these persistent searches, so you might not need to use this property.

For more information, see Document more information about disabling persistent searches (6486927).

CR# 6385696: Existing and new IDPs and SPs are not visible

The new com.sun.identity.federation.spadapter property in the AMConfig.properties file specifies the default implementation of the federation service provider adapter where the application can get assertions and response information. For example:

com.sun.identity.federation.spadapter=com.sun.identity.federation.plugins.FSDefaultSPAdapter

Access Manager 7 2005Q4 Patch 1

Access Manager 7 2005Q4 patch 1 (revision 01) fixed 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:

Creation of Debug Files

Access Manager debug files are created by default in the debug directory, even when com.iplanet.services.debug.level property in the AMConfig.properties file is set to error. Before Access Manager 7 patch 1 was released, a debug file was created only when the first debug message was logged to the file.

Support for Roles and Filtered Roles in the LDAPv3 Plug-in

Access Manager 7 patch 1 adds support for roles and filtered roles in the LDAPv3 plug-in, if the data is stored in Sun Java System Directory Server. For more information, see Document the roles and filtered roles support for LDAPv3 plug-in (6365196).

CR# 6320475: com.iplanet.am.session.client.polling.enable on server side must not be true

The com.iplanet.am.session.client.polling.enable property in the AMConfig.properties file on the server side is set to false by default and should never be reset to true.

CR# 6358751: Access Manager 7 patch 1 apply fails if the there are embedded spaces in the encryption key

If the password encryption key contains spaces, applying the patch fails.

Workaround. Use a new encryption key that includes no spaces. For the detailed steps to change the encryption key, see: Appendix B, Changing the Password Encryption Key, in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide.