test

Sun Java System Access Manager 7.1 Release Notes

Access Manager 7.1 Patch 1

Access Manager 7.1 patch 1 fixes 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:

Support for specific application idle session timeout values

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

This feature is not currently supported for Distributed Authentication and Cross Domain Single Sign-on scenarios

Requirements to use this feature are:

To use this feature:

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

If there are multiple policies defined to protect resources of the HR application, you must add the Condition to all of the policies.

When a user in a distinct session attempts to access the HR application protected by the Access Manager agent, that user is prompted to authenticate for the LDAP scheme (if the user is not yet authenticated).

If the user has already authenticated to the LDAP scheme, that user is allowed access only if the time is less than 10 minutes since the time the last authentication or if the time is less than 10 minutes since that user's last access time to the HR application. Otherwise, the user is prompted to authenticate to the LDAP scheme again to access the application.

The Idle Session Timeout for a realm is configured for the highest value required by all applications. Shorter Idle Session Timeout requirements are enforced by the Policy Condition protecting the appropriate applications. However, if you define explicit "deny" policies to protect the application, it would break this protection. This is because the new the new Condition extends the idle timeout for the application, assuming that the access to the application is allowed if this Condition is satisfied. If the other "deny" policy is satisfied, the user can not access the application.

Application idle timeout of value 0 is treated as Integer.MAX_VALUE for the purposes of idle timeout enforcement.

Web Proxy Agent 2.2-01 in CDSSO mode does not work with Access Manager 7.1 Patch 1 (CR 6611841)

The Web Proxy Agent 2.2-01 in Cross Domain Single Sign-on mode does not work with Access Manager 7.1 Patch . The agentRootURL requirement was added as a security measure to ensure that CDC is handing off ssotoken cookie to trusted agents running at known URLs.

Workaround

  1. Create a new agent profile in the Access Manager server using the administration console.

  2. Set the Agent Key agentRootURL=http://<agenthost>:<agentport>/using the console.

  3. Get the encrypted password for the new agent profile using cryp_utilon the Agent

  4. Use the new agent username and corresponding encrypted password in the AMAgent.properties file.

Distributed Auth UI does not work with a WebSphere Application Server 5.1.1.12 server (CR 6625928)

In Patch 1, the

Distributed Authentication user interface does not work with a WebSphere Application Server 5.1.1.12 server.

Password file exposed in a temporary directory after Patch 1 re-deployment (CR 6640377)

After Access Manager Patch 1 applied to Access Manager 7.1 and re-deployed, several/tmp directories are created. In one of them, the permissions are incorrectly set so that the sun_ad_dirmgrpasswd is readable. These directories are automatically deleted when the deployment is completed, but they are exposed for a matter of time before hand. This is a potential security risk.

Workaround

Before re-deploying the patch, set umask 077. The files will then be created with the correct permissions.

LDAP Failover not working properly (CR 6611627)

LDAP failover does not work if the primary LDAP failover server is set to SSL and the secondary server is set to non-SSL. There is no workaround at this time.

amconfig does not tag-swap and re-register the monitoring framework descriptor (CR 6636710)

When Patch 1 is applied to a full Access Manager installation using the amconfig script to redeploy all of the web applications, amconfig does not tag swap the monitoring framework descriptor. As a result, the monitoring framework description at $CONFIG_DIR/com.sun.cmm.am.xml only contains tags.

Workaround

Back up the monitoring framework descriptor (Solaris locatoin is /etc/opt/SUNWam/config/com.sun.cmn.am.xml, Linux location is /etc/opt/sun/identity/config/com.sun.am.xml) before applying the patch. Once the patch is applied, replace the patched file with the original file in the same location.

amtune does not work if installed in a non-default directory (CR6640673)

The amtune script will not work if installed in a non-default directory. This occurs on all platforms. The script is defaulting to the LDAP installation directory when the package is not found on the system.

Workaround

Modify the amtune-directory so that LDAP_DIR points to the DSEE base directory:

DSADMIN=$LDAP_DIR/ds6/bin/dsadm

amtune does not delete the world readable password file (CR 6640672)

The amtune script does not delete the password file after it completes. The file should be deleted after the completion of the script.

Workaround

Modify the set DSADMIN_PASSFILE attribute, or any directory that only the root user can read, in the amtune-env file before running the amtune script. For example:

DSADMIN_PASSFILE=/var/tmp/dspassfile

amtune should set thread pool size at 3 times the number of CPUs or cores for CMT servers (CR 6631123)

The optimal size of Access Manager's notification thread pool size (com.iplanet.am.notification.threadpool.size in AMConfig.properties) was 3 times the number of CPU's where Access Manager is deployed or the number of cores in cases of CMT servers like Niagara I and II (Sun Fire T1000/2000 and T5120/T5220 servers). The current amtune-identity sets the maximum number of thread pools at 28 regardless of number of CPU's and calculates the optimal value based on the available amount of memory.

Workaround

Increase the value in the com.iplanet.am.notification.threadpool.size property in AMConfig.properties by three times the number of CPU's or cores in cases of CMT servers (e.g., T1000/T2000 or T5210/T5220 servers), overriding the recommended values by amtune-identity script.

amsfo.pl does not work for Windows (CR 6629189)

For Access Manager Patch 1 for Windows, the amsfo.pl script does not work properly. There is no workaround at this time.

Not able to deploy WAR file generated by patch.bat if -l option is used for Windows (CR 6636474)

If you are deploying the WAR file using patch.bat, do not use the -l option as it will cause errors and fail to deploy.

amserveradmin.bat throwing errors for Access Manager 7.1 Patch for Windows (CR 6631526)

Executing the amserveradmin.bat batch file produces the following error message:


The system cannot find the path specified.
Loading amAdminConsole.xml
The system cannot find the path specified.
Loading amAuth.xml
The system cannot find the path specified.
Loading amAuthAnonymous.xml
The system cannot find the path specified.
Loading amAuthCert.xml
The system cannot find the path specified.

This is because after reconfiguring, tokens in this file are not getting tag swapped.

Workaround

In the amserveradmin.bat.template, set the value for AM_DIR to AM_DIR=c:\sun\identity. Rename the template file to amserveradmin.bat.

amsfo.pl script does not work for Session Failover in a Single War deployment for Windows (CR 6646519)

In a single WAR deployment for Windows, the session failover script, amsfo.pl, fails to start the amsessiondb client. In order to fix this, perform all of the steps described in the following workaround.

Workaround

  1. Edit the amsfo.conffile to replace the AMSESSIONDB_ARGS= parameter with AMSESSIONDB_ARGS="".

  2. Edit the amsfo.conf file to replace the $AM_HOME_DIR/.password with the absolute value of the .password file. For example:

    PASSWORDFILE=c:/was_session/sfo/.password

  3. Edit the amsfo.pl script to include the -javahome option for the following argument:

    $jmq_args = "-bgnd $broker_options -vmargs $broker_vm_args -name $broker_instance_name -port $broker_port -cluster $cluster_list -javahome $java_home";

    Set the java_home as defined in your environment, as it does not read it from the environment even though it is set there.

  4. Remove the /logs/jmq pid file.

Access Manager classpath not pointing to xml.sec.jar in Patch 1 for Windows (CR 6644461)

In Access Manager Patch 1 for Windows, the Access Manager classpath is not pointing to the patched version of the xmlsec.jar.

Workaround

Copy jes-install-dir\identity\lib\xmlsec.jar to jes-install-dir\share\lib\xmlsec.jar.

Post authentication plug-in supports Microsoft SharePoint (CR 6541695)

The Access Manager post-authentication plug-in (ReplayPasswd.java) has been modified in this patch release to read the com.sun.am.sharepoint_login_attr_name=sharepoint-login-value property. The value of this property indicates the user token that SharePoint uses for authentication.

For example, if “login” is the LDAP attribute that is mapped in both the places (Access Manager and SharePoint), then the property should be com.sun.am.sharepoint_login_attr_name=login.

The post-authentication plug-in will read this property and retrieve the corresponding value from Directory Server. It will then replace this value as a session property. The IIS6 authentication plug-in is modified to read this new property and set authorization headers for Sharepoint to work.

Retrieving schema from Active Directory data store fails (CR 6542686)

Access Manager 7.1 would not successfully retrieve the schema if you are using the Active Directory datastore. Installing patch 1 will fix this issue. To incorporate the fix, load the am_remote_ad_schema.ldif file. This file is located at /etc/opt/SUNWam/config/ldif for Solaris systems, /etc/opt/sun/identity/config/ldif for Linux systems, and \identity\config\ldif for Windows systems.

Access Manager supports the JDK 1.5 HttpURLConnection setReadTimeout method (CR 6536635)

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

saml samples will not work if the saml module instance is created with lower case name "saml" (CR 6648342)

If a SAML instance is created with the name "saml", the amSAML authentication fails and the sample will not work.

G11n: CLI commands amhasetup and amserver are not localized (CR 6567135)

For EMEA locales, the amhasetup and amserver command line utilities return unlocalized output. For other languages, the output is localized.

G11n: The User sub-tab incorrectly translated in French language (CR 6633529)

After you have created a user in the User sub-tab of the Realm tab in the French language, the edited user message is incorrectly displayed as Modification de Utilisateur.

Web Security Service Issues Fixed

6543625 — UserName token authentication can authenticate against a configured LDAP module

The UserName token authentication is able to authenticate against a configured LDAP module. In previous releases, the UserName token authentication could only use the Access Manager file-based authentication realm.

6543626 — SOAPRequestHandler returns the SSOToken set in the Subject

SOAPRequestHandler now returns the SSOToken set in the Subject, in addition to X509 or UserName token that was used for authentication. The SSOToken is in the format usable to the PolicyEvaluator API.

6544177 — When using X509 token with an invalid certificate AM always accepts the cert even without root CA

When using X509 token with an invalid certificate, Access Manager always accepts the certificate, despite the fact that the root CA is not in the Keystore. this problem has been fixed.

6559603 — Boolean configuration flag for "request" signing

A web service user can now choose boolean configuration for SOAP request signing.

6543620 Access Manager Policy Agent profiles able to apply a digital signature to the service request for UserName token

Access Manager Policy Agent profiles can apply a digital signature to the service request and the service response. In previous releases, digital signature could be used only in case when X509 token is included into SOAP message for authentication.

6543623 Access Manager Policy Agent profiles able to encrypt SOAP request body and SOAP response body

Access Manager Policy Agent profiles are now able to encrypt SOAP request body and SOAP response body.

6570021 Encryption supports SOAP messages with extra spaces.

Access Manager now supports the encryption of SOAP message with extra spaces and new lines between XML elements of SOAP message. It is common to see SOAP messages with extra spaces and new lines inserted for better readability.

Removed ACIs that cause unnecessary performance degradation (CR 6484947)

The amtune script has been changed to enhance the performance of AM 7.1 by removing unnecessary ACI checks. You must run amtune after the patch installation to remove the ACIs.

6.3–based console online help not displayed win Application Server 8.2 (CR 6587213)

If you have installed Access Manager from the Java ES 5 update 1, and have it deployed with Application Server 8.2, the Access Manager console online help will not display. This only occurs in the 6.3–based Access Manager console, accessed by /amconsole.

Multiple passwords not required for amtune script

In Access Manager 7.1 Patch 1 you do not need to enter multiple passwords when executing individual amtune scripts. Only the wrapper amtune script which calls individual scripts needs multiple passwords. For instance, amtune-os and amtune-identity do not require any password. amtune-directory requires only Directory Manager password, while amtune-ws6, -ws7 and -as8 require the corresponding web container admin passwords.

amtune-os will not run in local zone

amtune-os will not run if the wrapper amtune script is run in a local zone on Solaris 10, or higher, but other individual amtune scripts will still run.