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.