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:
Solaris Operating System (Solaris OS) on SPARC based systems: 120954-12
Solaris OS on x86 platforms: 120955-12
Linux systems: 120956-12
Microsoft Windows systems: 124296-12
HP-UX systems: 126371-12
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 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
CR# 6926203 Distributed Authentication UI server deployment validates goto URLs
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:
Solaris SPARC and x86 systems: 119725
Linux: 120834
Windows and platforms other than Solaris and Linux systems: 138905
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:
After you install patch 12, make sure you run the updateschmema.sh or updateschema.bat script and then restart the Access Manager web container.
Log in to the Access Manager Administration Console.
Click Configuration, Authentication, and then Core.
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.
Click Save.
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.
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.
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.
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.
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.
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
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:
Solaris systems: AccessManager-base/SUNWam
Linux systems: AccessManager-base/identity
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
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:
Solaris SPARC systems: patch-home-directory/120954-09
Solaris x86 systems: patch-home-directory/120955-09
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.
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
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.
The requirements to install the Windows patch include:
Access Manager 7 2005Q4 must be installed on the Windows system. For information about installation, see the Sun Java Enterprise System 2005Q4 Installation Guide for Microsoft Windows.
To run the patch scripts, ActivePerl 5.8 (or later) is required on the Windows system.
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:
Logon to the Windows system as a member of the Administrators group.
Create a directory to download and unzip the Windows patch file. For example: AM7p8
Download and unzip the 124296-09.zip file in the directory from the previous step.
Stop all Java ES 2005Q4 services.
Run the AM7p8\scripts\prepatch.pl script.
Run AM7p8\124296-09.exe to install the patch.
Run the AM7p8\scripts\postpatch.pl script.
Restart the Java ES 2005Q4 services.
Redeploy the Access Manager applications. See Post-Installation Considerations for more information.
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
Restart the Java ES 2005Q4 services.
To back out the Windows patch:
Logon to the Windows system as a member of the Administrators group.
Run the Uninstall_124296-09.bat file.
Run the AM7p8\scripts\postbackout.pl script.
Redeploy the Access Manager applications.
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.
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.
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
CR# 6436409: Redeploying the Distributed Authentication and Client SDK WAR Files
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:
console.war
password.war
services.war
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:
Properties files:
Solaris systems: AccessManager-base/SUNWam/locale/*.properties
Linux systems: AccessManager-base/identity/locale/*.properties
Windows systems: AccessManager-base\locale\*.properties
Tag library descriptors:
Solaris systems: AccessManager-base/SUNWam/web-src/applications/WEB-INF/*.tld
Linux systems: AccessManager-base/identity/web-src/applications/WEB-INF/*.tld
Windows systems: AccessManager-base\web-src\applications\WEB-INF\*.tld
The web.xml file and the files used to construct it (WEB-INF/web.xml and WEB-INF/*.xml)
Application specific files: JSP (*.jsp) files, images (*.gif) files, and style sheets - background colors, font sizes, etc. (*.css) files
To make sure that all custom changes are preserved, follow these steps. Before you make changes to a file, always backup the file first.
Install the patch.
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
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.
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
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.
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
After you run the amconfig script, restart the Access Manager processes. For example:
# cd /opt/SUNWam/bin # ./amserver stop # ./amserver start
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\.
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.
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:
Building the Distributed Authentication WAR file: Technical Note: Using Access Manager Distributed Authentication
Building the Client SDK WAR file: Installing the Client SDK in Sun Java System Access Manager 7 2005Q4 Developer’s Guide
Deploying the Client SDK WAR file: To Deploy amclientwebapps.war in Sun Java System Access Manager 7 2005Q4 Developer’s Guide
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
CR# 6872718: Persistent XSS attacks are prevented in Access Manager
CR# 6843487: Access Manager session cookies can be marked as HTTPOnly
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:
Solaris SPARC systems: 122983
Solaris x86 systems: 122984
Linux: 122985
To use the saml2setup installer with the update option, follow these steps:
Install the new Access Manager or SAML v2 patch.
If you installed an Access Manager patch in Step 1:
Run amconfig to generate a new amserver.war.
Update the SAML v2 staging directory with the new amserver.war.
Reapply any necessary customizations for your deployment.
Run the saml2setup installer with the update option as follows:
saml2setup update -s installation-configuration-properties-file
Redeploy the modified WAR file.
Restart the Access Manager or Federation Manager web container.
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.
Patch 11 prevents potential persistent cross-site scripting (XSS) attacks in Access Manager.
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 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
CR#6804391 and CR#6777889 Access Manager SecurID authentication process no longer crashes
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.
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 patch 9 (revision 09) fixes a number of problems, as listed in the README file included with the patch.
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# 6691106: Multiple SiteMonitor threads could be running for checking the same site
CR# 6697260: New property to set policy agent application session idle timeout
CR# 2151598: Delegation privileges cannot be defined for a filtered role
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:
In the Admin Console, go to Realms, Edit Realm - realm-name.
Add amhost.realm-name.example.com to the Realm/DNS aliases.
Restart the Access Manager server.
Log in using the following URL:
http://amhost.realm-name.example.com:port/amserver/UI/Login
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:
com.sun.identity.urlchecker.retry.interval specifies the time interval in milliseconds between retries for a URL connection. Default is 500 milliseconds (0.5 seconds).
com.sun.identity.urlchecker.retry.limit specifies the maximum number of retries for the URL connection if a connection failure occurs. Default is 3 retries.
The fix for this problem also uses the following property, which was added for patch 5:
com.sun.identity.urlchecker.sleep.interval specifies the time interval in milliseconds that the site status check should sleep. Default is 30000 milliseconds (30 seconds).
The patch does not add these new properties to the AMConfig.properties file. To use these properties with values other than the default values:
For each property that you want to set, add the property and its value to the AMConfig.properties file.
Restart the Access Manager web container for the values to take effect.
Patch 8 includes this new property:
com.iplanet.am.session.agentsessionidletime sets the maximum idle timeout in minutes for policy agent sessions. The minimum value is 30 minutes.
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.
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:
Create an XML file with the FILTEREDROLE subject type. For example:
<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE Requests PUBLIC "-//iPlanet//Sun Java System Access Manager 2005Q4 Admin CLI DTD//EN" "jar://com/iplanet/am/admin/cli/amAdmin.dtd"> <Requests> <SchemaRequests serviceName="sunAMDelegationService" SchemaType="Global" i18nKey=""> <AddDefaultValues> <AttributeValuePair> <Attribute name="SubjectIdTypes"/> <Value>FILTEREDROLE</Value> </AttributeValuePair> </AddDefaultValues> </SchemaRequests> </Requests>
Note: The XML encoding used in this example is ISO-8859-1. You might need to use a different encoding depending on your environment.
Use the amadmin command to load the XML file you created in Step 1 into Directory Server. For example:
# cd /opt/SUNWam/bin # ./amadmin -u amadmin -w pwfile -t new-filteredrole.xml
where:
pwfile contains the amadmin password.
new-filteredrole.xml is the new XML file you created in Step 1.
Restart the Access Manager server web container.
Now, when you log in to the Admin Console, the filtered role will appear under the Privileges tab.
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
CR# 6612609: Session failover works if network cable is disconnected from Message Queue server
CR# 6570409: Interaction service behind load balancer works correctly as Identity Provider
CR# 6545176: Redirect URLs can be dynamically set in post authentication processing SPI plug-in
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
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.
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.
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 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
Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout method
Access Manager SDK falls back to primary Directory Server after primary comes back up
Microsoft IIS 6.0 post-authentication plug-in supports SharePoint Server
CR# 6379325: Accessing Console during session failover throws null pointer exception
CR# 6508103: On Windows, clicking Help in the Admin Console returns an application error
CR# 6564877: Access Manager 7 patch installation overwrites SAML v2 files
Known Issues and Limitations in Patch 6
Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout method
Access Manager SDK falls back to primary Directory Server after primary comes back up
Microsoft IIS 6.0 post-authentication plug-in supports SharePoint Server
CR# 6379325: Accessing Console during session failover throws null pointer exception
CR# 6508103: On Windows, clicking Help in the Admin Console returns an application error
Before you install patch 6, it is recommended that you upgrade or patch the following components:
If you are using Sun Java System Web Server 6.1 SP5 or earlier, upgrade to Web Server 6.1 SP7, which you can download from this site:
http://www.sun.com/download/products.xml?id=45c90ca9
Follow the upgrade process as described in Upgrade in Sun Java System Web Server 6.1 SP7 Release Notes.
Download and install the latest security patch for NSS, JSS, and NSPR from SunSolve Online: http://sunsolve.sun.com.
Solaris 8 SPARC platforms: 119209
Solaris 8 x86 platforms: 119210
Solaris 9 SPARC platforms: 119211
Solaris 9 x86 platforms: 119212
Solaris 10 SPARC platforms: 119213
Solaris 10 x86 and AMD64 platforms: 119214
Windows systems: 124392
HP-UX systems: 124379
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.
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 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:
Solaris systems: /var/opt/SUNWam/logs
Linux and HP-UX systems: /var/opt/sun/identity/logs
Windows systems: C:\Sun\JavaES5\identity\logs
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
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.
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 7 2005Q4 patch 6 now supports Microsoft Windows Internet Explorer 7.
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:
For a temporary solution, refresh the browser, or log out and then back into the Console.
For a permanent solution, deploy the Access Manager Console on a separate Access Manager instance that does not participate in the session failover.
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:
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
Restart the Application Server instance.
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
Support for specific application idle session timeout values
CDC Servlet can be deployed on a Distributed Authentication UI server
Realm can be specified when CDC servlet redirects to the Access Manager login URL
Certificate Authentication can use UPN value to map user profile
Post authentication processing of logout occurs in a multiple-server environment
User no longer must authenticate twice in authentication chain
Known Issues and Limitations in Patch 5
CR# 6527528: Patch removal leaves XML files with amldapuser password in clear text
CR# 6527516: Full server on WebLogic requires JAX-RPC 1.0 JAR files to communicate with client SDK
CR # 6523499: Patch 5 amsilent file is readable by all users on Linux systems
CR# 6520016: Patch 5 SDK-only install overwrites the samples makefiles
CR#6515502: LDAPv3 repository plug-in does not always handle Alias Search Attribute correctly
CR# 6515383: Distributed Authentication and J2EE agent do not work in same web container
CR# 6508103: Online help returns application error with Application Server on Windows systems
CR# 6507383 and CR# 6507377: Distributed Authentication requires explicit goto URL parameter
CR# 6402167: LDAP JDK 4.18 causes LDAP client/Directory Server problems
CR# 6352135: Distributed Authentication UI server files are installed in incorrect location
CR# 6513653: Issue with com.iplanet.am.session.purgedelay property setting
Globalization (g11n) Issues
Documentation Updates
Document that Access Manager cannot revert from Realm Mode to Legacy Mode (6508473)
Document more information about disabling persistent searches (6486927)
Document Access Manager supported and unsupported privileges (2143066)
Document Windows Desktop SSO configuration for Windows 2003 (6487361)
Document steps to set up Distributed Authentication UI server passwords (6510859)
Online Help for “To create a new site name” needs more information (2144543)
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.
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.
Patch 5 (and later) includes the updateschema.sh script to load the following files to update the Directory Server service schema:
AddLDAPFilterCondition.xml
amPolicyConfig_mod_ldfc.xml
accountLockoutData.xml
accountLockout.ldif
idRepoServiceAddAttrSchemaRequest_Cache.xml
wsf1.1_upgrade.xml
amAuth_mod.xml
amAuthCert_mod.xml
In previous Access Manager patch releases, you were required to load these files manually.
To run the updateschema.sh script:
Log in as or become superuser (root).
Change to the patch directory.
Run the script. For example, on Solaris systems:
# cd /120954-07 # ./updateschema.sh
On Windows systems, the script is updateschema.pl.
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
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
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.
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:
Agents protecting the application must be configured to enforce URL policy decisions from Access Manager.
Agents must be configured to run in self policy decision cache mode. See the following properties:
For web agents: com.sun.am.policy.am.fetch_from_root_resource
For J2EE agents: com.sun.identity.policy.client.cacheMode
The Access Manager AMConfig.properties file must specify a policy component evaluation order such that Condition is evaluated last. See the following property:
com.sun.identity.policy.Policy.policy_evaluation_weights
The application access allowed by the agent based on a locally cached decision will not be known to the Condition on Access Manager. Therefore, the actual application idle timeout will be between the application idle timeout to the application idle timeout minus the agent cache duration.
To use this feature:
Add an Authentication Scheme Condition to the policies protecting the application that requires the application specific session idle timeout.
Specify the Application Name and Timeout Value in the Authentication Scheme Condition.
Use the same Application Name and Time Out value in all the policies that apply to the resources for the application.
Specify the Timeout Value in minutes. If the value is 0 or greater than the session idle timeout value specified in the session service, the value is ignored, and the timeout from session service will apply.
For example, consider a policy http://host.sample.com/hr/*, with this Authentication Scheme Condition:
Authentication Scheme: LDAP
Application Name: HR
Timeout Value: 10
If there are multiple policies defined to protect resources of the HR application, you must add the Condition to all of the policies.
When a user in a distinct session attempts to access the HR application protected by the Access Manager agent, that user is prompted to authenticate for the LDAP scheme (if the user is not yet authenticated).
If the user has already authenticated to the LDAP scheme, that user is allowed access only if the time is less than 10 minutes since the time the last authentication or if the time is less than 10 minutes since that user's last access time to the HR application. Otherwise, the user is prompted to authenticate to the LDAP scheme again to access the application.
The 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:
Modify the agent's AMAgent.properties file to point to the CDC Servlet on the Distributed Authentication side (client). For example, for web agents, change the following property:
com.sun.am.policy.agents.config.cdcservlet.url= http://DAhost.DAdomain:DAport/DISTAUTH_DEPLOY_URI/cdcservlet
Define policies as necessary in Access Manager for resources that need to be protected by the agent. For example, if agent is at host.example.com:80, define a policy for the resource as http://host.example.com:80/*.
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
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 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 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.
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:
Add the properties and their values to the AMConfig.properties file. For Policy Agents, add these properties to the AMAgents.properties file.
Restart the Access Manager web container for the values to take effect.
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.
Patch 5 includes these changes to the performance tuning scripts:
Tuning script removes unnecessary ACIs from Directory Server
Tuning scripts can tune the Distributed Authentication UI server web container
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.
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.
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:
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.
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.
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.
Review the tuning recommendations in the debug log file. If needed, make changes to the amtune-env file based on this run.
To make tuning changes, set AMTUNE_MODE=CHANGE in the amtune-env file.
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.
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.
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.
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:
Windows scripts are written in Perl and require Active Perl 5.8 to run.
If you are tuning Directory Server, after running amtune-prepareDSTuner.pl script, you must copy the amtune-utils.pl, amtune-directory.pl, remacis.ldif, and amtune-samplepassordfile files to the Directory Server system, because the script cannot compress these files.
A script to tune the Windows operating system is not available.
Support for zones is not provided.
Before running a script, you must set the $BASEDIR parameter to the Access Manager installation directory in the amtune-env.pl file.
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.
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:
DESGenKey.java generates a unique key used to encrypt and decrypt the user's password.
ReplayPasswd.java reads the encryption key value from the com.sun.am.replaypasswd.key property in the AMConfig.properties file, encrypts the password, and assigns it to the sunIdentityUserPassword session property.
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:
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
Assign the encryption key value from Step 1 to the com.sun.am.replaypasswd.key property in the AMConfig.properties file.
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:
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.
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.
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.
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.
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:
Solaris systems: /etc/opt/SUNWam/config/xml
Linux and HP-UX systems: /etc/opt/sun/identity/config/xml
Workaround: Edit the amAuthLDAP.xml and amPolicyConfig.xml files and delete the clear text password.
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:
On the Access Manager server, login as or become superuser (root).
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.
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
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:
Apply patch 5.
Modify the amsilent file and redeploy the first Access Manager instance.
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:
Solaris systems: /etc/opt/SUNWam/config
Linux systems: /etc/opt/sun/identity/config
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.
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:
Run the amconfig script with DEPLOY_LEVEL=14 to uninstall the SDK and unconfigure the web container.
Run the amconfig script with DEPLOY_LEVEL=4 to re-install the SDK and reconfigure the web container.
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
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.
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.
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:
The URL is relative, and no corresponding page is available at the Distributed Authentication UI server
The URL is absolute, and the browser cannot reach the URL.
Workaround: Always specify an explicit goto URL parameter for a Distributed Authentication UI server.
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:
Solaris OS, SPARC and x86 platforms: 119725-04
Linux OS: 120834-02
The patches are available on SunSolve Online: http://sunsolve.sun.com.
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.
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.
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.
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
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:
In the AMConfig.properties file, set the property to the new value. For example:
com.iplanet.am.session.purgedelay=5
Restart the Access Manager web container for the new value to take effect.
Access Manager 7 2005Q4 patch 4 (revision 04) fixes the following problems:
CR# 6463796: Disabling iPlanetAMClientDetection service for genericHTML prevents access to any Access Manager HTML page
CR# 6463779: Distributed Authentication amProfile_Client and Access Manager Server amProfile_Server get filled with harmless exceptions
CR# 6463730: Cross-site scripting (XSS) vulnerability exists with the goto and gx-charset parameters
CR# 6435889: Method Session.getSession fails because RestrictedTokenContext is not set
Known Issues and Limitations in Patch 4
CR# 6470055: Distributed Authentication UI server performance improvement
CR# 6455079: Password reset service reports notification errors when a password is changed
To improve performance in reading, searching, and comparing user attributes for a Distributed Authentication UI server user, follow these steps:
In the Makefile.distAuthUI file, change the application user name from anonymous to another user. For example:
APPLICATION_USERNAME=user1
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";)
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:
Change the from address label. For example:
fromAddress.label=<Identity-Server@amhost.example.com>
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 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
CR# 6460974 Default Distributed Authentication Application User should not be amadmin
CR# 6460576 No link for the User Service under Filtered Role in console online Help
CR# 6452320: Exceptions are thrown when using polling with client SDK
CR# 6442905 SSOToken of authenticated user can be unintentionally revealed to rogue sites
CR# 6440697: Distributed Authentication should run as non-amadmin user
CR# 6440695: Distributed Authentication UI servers with a load balancer
CR# 6440651: Cookie replay requires com.sun.identity.session.resetLBCookie property
CR# 6440648: com.iplanet.am.lbcookie.name property assumes default value of amlbcookie
CR# 6440641: com.iplanet.am.lbcookie.value property is deprecated
CR# 6429610: Unable to create SSO token in ID-FF SSO use case
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:
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.
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); }
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.
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:
On the Distributed Authentication UI client machine, run "cat /dev/null > distAuth/amProfile_Client" every few hours, depending on the traffic volume.
On the Access Manager server, run "cat /dev/null > /var/opt/SUNWam/debug/amProfile_Server" every few days, instead of every few hours.
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.
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
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:
Stop the server.
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
Restart the server.
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.
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:
Backup your Access Manager 6 DIT.
Run the ampre70upgrade script.
Install Access Manager 7 2005Q4 with the Configure Later option.
Undeploy the Access Manager Web applications.
Deploy the Access Manager Web applications.
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.
Run the amupgrade script.
Redeploy the Access Manager Web applications, because of the Access Manager 7 patch 3 changes.
Access the Access Manager Console.
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.
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.
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.
To create a Distributed Authentication administrator other than the default administrative user (amadmin) for Distributed Authentication application authentication, follow this procedure:
Create an LDAP user for the Distributed Authentication administrator. For example:
uid=DistAuthAdmin,ou=people,o=am
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.
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
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'
For the Policy Agent, add the property to the AMAgent.properties file.
For the Access Manager server, add the property to the AMConfig.properties file.
Note: This property is required only if you have implemented Access Manager session failover.
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.
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.
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.
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
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 ...) { ... } ... }
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:
LoginModuleSample.java
LoginModuleSample.xml
testExtWebSite.jsp
To implement this feature:
Create a custom authentication module using the sample LoginModuleSample.java.
Load the module into an Access Manager server.
Construct the RedirectCallback in the XML file using the sample LoginModuleSample.xml.
To test the module, use the sample testExtWebSite.jsp file for the external Web site.
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:
A user invokes the authentication process/login page for the custom authentication module.
The user enters the credentials (user name and password) and submits a request to the custom authentication module.
The custom authentication module redirects the user to an external provisioning/credit card site with the required user information along with the request.
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.
The custom authentication module validates the user based on the status returned in Step 4 and returns the corresponding status to the authentication service.
The user authentication completes with either success or failure.
Workaround: To fix this problem, apply latest version of the “Core Mobile Access” patch, depending on your platform:
Solaris OS on SPARC based systems: 119527
Solaris OS on x86 platforms: 119528
Linux systems: 119529
After applying the patch, restart the Web container.
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
CR# 6283582: Num of login failures are not shared across Access Manager instances
CR# 6236892: Image/Text place holder while CDCServlet is processing the AuthNResponse after login
CR# 6363157: New property disables persistent searches if absolutely required
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:
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
Restart the Access Manager Web container for the values to take effect.
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 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.
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.
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
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.
The following new properties are added to AMConfig.properties file and are read by the CDCServlet:
com.iplanet.services.cdc.WaitImage.display causes an image to be displayed in the browser while a user is waiting for the protected page in a CDSSO scenario, if set to true. Default is false.
com.iplanet.services.cdc.WaitImage.name specifies the image name. Default is waitImage.gif. This image be copied from the login_images directory.
com.iplanet.services.cdc.WaitImage.width specifies the image width. Default is 420.
com.iplanet.services.cdc.WaitImage.height specifies the image height. Default is 120.
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.
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).
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 (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:
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.
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).
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.
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.