test

Sun Java System Access Manager 7 2005Q4 Release Notes

Access Manager 7 2005Q4 Patch 3

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

New Features in Patch 3

Known Issues and Limitations in Patch 3

New Configuration Properties for Site Monitoring

The Access Manager site monitoring feature includes these new properties:

Property 

Description 

com.sun.identity.sitemonitor.interval

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

com.sun.identity.sitemonitor.timeout

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

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

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

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

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

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

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

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

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

Each implementation class must use the doCheckSiteStatus method.

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

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

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

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

New Property for Liberty ID-WSF Support

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

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

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

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

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

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

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

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

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

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

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

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

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

or

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

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

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

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

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

Workaround. None

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

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

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

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

  1. Stop the server.

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

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

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

  3. Restart the server.

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

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

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

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

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

Failed to get valid Sessions from the Specified server

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

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

  1. Backup your Access Manager 6 DIT.

  2. Run the ampre70upgrade script.

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

  4. Undeploy the Access Manager Web applications.

  5. Deploy the Access Manager Web applications.

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

  7. Run the amupgrade script.

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

  9. Access the Access Manager Console.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Access Manager site failover includes the following new properties:

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

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

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

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

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

    uid=DistAuthAdmin,ou=people,o=am

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

To implement this feature:

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

  2. Load the module into an Access Manager server.

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

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

  5. Login using this URL:

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

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

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

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

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

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

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

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

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

CR# 6324056: Federation fails when using artifact profile

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

After applying the patch, restart the Web container.