Sun Java System
Access Manager 7.1 Release Notes

October 2010

Part Number 819-4683-24

The Sun Java System Access Manager 7.1 Release
Notes contain important information available for the Sun Java Enterprise
System (Java ES) release, including new Access Manager features and known
issues with workarounds, if available. Read this document before you install
and use this release.

Updated with new information for the Documentation Updates section; Missing information when configuring Access Manager
in SSL mode and Access Manager supports non-ASCII character passwords if Directory
Server is configured to support them.

About Sun Java System Access Manager 7.1

Sun Java System Access Manager is part of the Sun Identity Management
infrastructure that allows an organization to manage secure access to Web
applications and other resources both within an enterprise and across business-to-business
(B2B) value chains.

Access Manager provides these main functions:

Centralized authentication and authorization services using
both role-based and rule-based access control

Single sign-on (SSO) for access to an organization's Web-based
applications

Logging of critical information including administrator and
user activities by Access Manager components for subsequent analysis, reporting,
and auditing.

Access Manager 7.1 Patch Releases

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

Solaris SPARC systems: 126356-05

Solaris x86 systems: 126357-05

Linux: 126358-05

Windows: 126359-05

WAR file deployments (all platforms): 140504-05

Note –

Access Manager 7.1 patches are cumulative. You can install the
latest 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.

Access Manager 7.1 Patch 5

Access Manager 7.1 patch 5 fixes a number of problems, as listed in
the README file included with the patch. For a list of the patch IDs, see Access Manager 7.1 Patch Releases. Patch 5 also
includes the following new features and changes:

Time to Live (TTL) is implemented for the Service
Management (SMS) cache (6973683)

Patch 5 includes the following new properties to implement the TTL for
the SMS cache. The TTL is the period of time before data in the SMS cache
is discarded.

com.sun.identity.sm.cache.ttl.enable enables
the TTL function for the SMS cache, if set to true.

com.sun.identity.sm.cache.ttl specifies
the time in minutes before data in the cache is discarded. The default is
30 minutes.

To use these new properties, add them with appropriate values to the AMConfig.properties file and then restart the Access Manager web
container.

Retry mechanism is implemented in the PLL server
(6963531)

Patch 5 includes the following new properties to implement the retry
mechanism in the PLL server:

com.sun.identity.notification.retry.limit enables
the Access Manager 7.1 server to repeat sending notifications until the notification
is delivered successfully. The default is 3 retries, if the value is set to
any nonnumeric character. A value of 0 (zero) specifies that no retries are
sent.

com.sun.identity.notification.retry.interval species
the time interval in milliseconds between re-sending the retries, if com.sun.identity.notification.retry.limit is set to a nonnumeric character (or not set). The default is 500
milliseconds.

To use these new properties, add them with appropriate values to the AMConfig.properties file and then restart the Access Manager web
container.

The Access Manager 7.1 Readme file included with the patch now lists
the required LDAP JDK patches. For more information, see the patch 5 Readme
file.

HttpServletRequest and HttpServletResponse are available
with Distributed Authentication User Interface (6677966)

Patch 5 allows you to access the HttpServletRequest object
and modify the HttpServletResponse object through a custom
authentication module for Access Manager 7.1 server deployments with the Distributed
Authentication User Interface (DAUI), as well as for Access Manager 7.1 server
deployments without the DAUI.

To use this new feature, you must modify your existing custom authentication
modules using the authentication SPI framework. (If you don't want to use
this feature, your existing custom authentication modules do not need to be
modified. The current APIs for getHttpServletRequest and getHttpServletResponse will continue to be supported but only for
Access Manager 7.1 server deployments without the DAUI.)

Changes to custom authentication modules include both JAVA class files
and callback XML files. No UI changes are required. Patch 5 adds these new
callbacks:

If you open multiple browser tabs in the same browser instance to access
the Access Manager login page, the new com.sun.identity.authentication.mutiple.tabs.used property prevents the “Too many authentication attempts”
error.

To use this new property, add it with a value of true to
the AMConfig.properties file and restart the Access Manager
web container.

New property sets idle time out for policy agent
sessions (6697260)

The new com.iplanet.am.session.agentsessionidletime property
sets the maximum idle timeout in minutes for policy agent sessions. The default
value is 0, which causes policy agent sessions to never time out. The minimum
value is 30 minutes. A value between 0 and 30 minutes will be reset to 30.

To use this new property, add it with a value appropriate for your deployment
to the AMConfig.properties file and restart the Access
Manager web container.

Access Manager session cookies can be marked as HTTPOnly (6843487)

The new com.sun.identity.cookie.httponly property
allows 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 help
to prevent cross-site scripting (XSS) attacks.

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

You must also set this property on the client side. For example, for
a Distributed Authentication UI server deployment, set it to true in
the AMDistAuthConfig.properties file.

ampassword utility has new options
to hash and encrypt a password (6850818)

Support for Windows Desktop SSO authentication is added for a Distributed
Authentication UI server deployment and the Access Manager 7.0 and later Client
SDK. This CR was verified for the following Access Manager 7.1 deployment
scenarios:

Access Manager 7.1 server with a version 7.1 Distributed Authentication
UI server deployment with the Access Manager 7.0 and later Client SDK on Windows
XP and Windows 2003

CDC Servlet inserts custom HTTP response header (6800246)

In patch 4, if you integrate Cross-Domain Single Sign-On (CDSSO) with
programmatic clients, the CDC Servlet inserts an extra HTTP response header
(which is not configurable). For example, with a web agent installed in CDSSO
mode, viewing a response on “Live HTTP Headers”, you will see
the Cdcservlet_auto_post: true header. This change allows
custom applications to easily distinguish the auto submitting form and to
process the information accordingly.

Changes to the updateschema.sh script (6870576)

Patch 4 includes the following changes to the updateschema.sh script:

Removes the restriction of requiring the user to be superuser
(root) to execute the script.

Allows the user to specify whether Directory Server has SSL
enabled.

Validates the path of the ldapsearch and ldapmodify commands and prompts the user to specify the path if
they are incorrect.

Corrects the path to the amadmin utility
in an Access Manger 7.1 single WAR file deployment.

Known Issues in Access Manager 7.1 Patch 4

updateschema.pl script fails
with older version of ldapjdk.jar (6934848)

On Windows, the updateschema.pl script in Access
Manager 7.1 patch 3 and later requires the version 4.21 or later ldapjdk.jar file. In some old ldapjdk.jar files, the
version is not even defined in the META-INF/MANIFEST.MF file.
If the LDAP JDK version is older than 4.21 or not defined, the updateschema.pl script exits with an error.

updateschema script cannot run
successfully under certain circumstances in WAR file deployment (6934844)

If Access Manager 7.1 patch 4 is deployed from a WAR file, the updateschema script cannot run successfully for the following reasons:

On Solaris systems, the -B option is not
available for the version of the ldapsearch utility that
is called by the updateschema.sh script.

On Linux systems, the -Z option is not
available for the version of the ldapsearch utility that
is called by the updateschema.sh script.

On Windows, if you are running the updateschema.pl script,
you cannot specify that the Directory Server is SSL enabled.

Workarounds

On Solaris or Linux systems, edit the updateschema.sh script
and change the path for the ldapsearch utility to point
to a version that supports the -B and -Z options.
You might need to download a version of ldapsearch that
supports these options. Then, rerun the updateschema.sh script.

On Windows, enable non-SSL access to Directory Server and
rerun the updateschema.pl script.

Access Manager 7.1 Patch 3

Access Manager 7.1 patch 3 fixes a number of problems, as listed in
the README file included with the patch. Patch 3 also includes changes and
known issues:

Sun Java System LDAP JDK Patches are Available

Running the updateschema Script
is Required

Beginning with patch 3 (and any subsequent patches unless specifically
noted), you must run the updateschema.sh script on Solaris
and Linux systems or the updateschema.pl script on Windows.
The updateschema script updates the Sun Java System Directory
Server schema with any new attributes required by the patch.

Requirements for the updateschema.sh or updateschema.pl script include:

The updateschema.sh or updateschema.pl script requires JDK 1.5 or later. Therefore, set your JAVA_HOME environment variable to a JDK installation of 1.5 or later.

After you unzip the patchID.zip file,
the updateschema.sh or updateschema.bat script
is in the patchID directory,
where patchID is 126356-05,
126357-05, 126358-05, or 126359-05, depending on your platform.

For an Access Manager 7.1 installer (package-based) deployment, run
the updateschema script after you add the patch. The
script prompts you for the same Directory Server information as requested
for a WAR file deployment.

In patch 2, the amadmin user was prevented from logging
in to any authentication module other than the Data Store and Application
authentication modules. CR 6811036 in patch 3 removes this restriction, but
at the same time re-implements the original security fix to protect the authentication
for the amadmin user, which is considered as a special
or “internal” user.

An internal user such as amadmin must first authenticate
internally to the OpenSSO configuration data store before it can authenticate
to any authentication module. Hence you can login as amadmin to
any authentication module only if you can first successfully authenticate
to the configuration data store.

Note. Due to CR 6811036, if you log
in as amadmin to the Access Manager Admin Console and provide
an incorrect password, the “Your authentication module is denied' message
will be displayed instead of “Authentication Failed” (which was
displayed prior to patch 2).

New Property Prevents Sessions From Being Destroyed
After Session Upgrade

For a Distributed Authentication UI server deployment, Access Manager
7.1 patch 3 (CR 6700722) includes the new com.sun.identity.authentication.destroySessionAfterUpgrade property to prevent old sessions from being destroyed after a session
upgrade. Values for this property can be:

true (default): Old sessions are destroyed
immediately after a session upgrade.

false: Old sessions are not destroyed after
a session upgrade.

Note. This new property applies only
to a Distributed Authentication UI server and not to Access Manager 7.1 server.

To prevent sessions from being destroyed after a session upgrade:

Add this new property with a value of false in
the AMConfig.properties file. For example:

com.sun.identity.authentication.destroySessionAfterUpgrade=false

Restart the Distributed Authentication UI server.

New Property Allows SSO Token Restriction Other Than
an IP Address

Access Manager 7.1 patch 3 (CR 6496155) includes the new com.iplanet.dpro.session.dnRestrictionOnly property to enforce the DN as the SSO token restriction rather
then the IP address in cross-domain single sign-on (CDSSO) deployments and
cookie-hijacking prevention mode. Values for this property can be:

Access Manager 7.1 Patch 2

Note –

Considerations for patch 2 include:

Access Manager 7.1 WAR file deployments.
Patch 140504 is available on http://sunsolve.sun.com/ for
Access Manager 7.1 WAR file deployments. See the patch README file for more
information. (For consistency with other Access Manager 7.1 patches, “02”
is the first release of this patch.)

Sun provides a new ldapjdk.jar file that includes
security and performance related fixes for Access Manager 7.1 patch 2. However,
the Sun ldapjdk.jar won't be effective on WebLogic Server
because weblogic.jar bundles an older ldapjdk.jar file.

Workaround. Put the Sun ldapjdk.jar ahead of weblogic.jar in the CLASSPATH,
as follows:

Workaround for Access Manager 7.1 in Legacy
Mode. On systems running Access Manager 7.1 in Legacy Mode, in
Directory Server, add the sunRegisteredServiceName attribute
to the Data Store service and set the sunAMAuthDataStoreAuthLevel attribute
to the minimum value (zero), to ensure the creation of the Data Store authentication
module instance. For example, using ldapmodify:

Sub-realm administrator can log in as amadmin in
root realm (6761627)

If Access Manager 7.1 is installed in Realm mode and a sub-realm administrator
creates another amadmin user in the sub realm, the second amadmin can also log in to the root (top-level) realm.

Access Manager 7.1 patch 2 fixes this problem. As the consequence of
this fix, amadmin can log in to the Console using this
URL: http://amhost.example.com:port/amserver/UI/Login?module=DataStore

New com.sun.identity.appendSessionCookieInURL property
(6740071)

The new com.sun.identity.appendSessionCookieInURL property
determines whether Access Manager appends the session cookie to the URL for
zero page authentication. Set this property to false to
prevent Access Manager from appending the session cookie to the URL. For example,
if an application is filtering incoming URLs for special characters for security
reasons and a cookie contains a special character, then access is denied
The default value is true (cookie is appended).

SecurID authentication is supported on Solaris x86
systems (6621802)

The default Key Provider implementation (JKSKeyProvider)
uses JKS format. Access Manager now includes the following new configuration
property that allows the keystore type to be changed. For example, for PKCS12
format:

com.sun.identity.saml.xmlsig.storetype=PKCS12

To use this new property, add it the AMConfig.properties file
and restart the Access Manager web container.

Delegation privileges cannot be defined for a filtered
role (6486843)

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

Workaround. After you apply patch
2, follow these steps to update the Delegation Service (sunAMDelegationService) in the Directory Server schema:

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:

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

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

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

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

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

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.

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.

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

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

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

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

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.

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.

Web Security Service Issues Fixed

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.

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.

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.

Pre-Installation Considerations

Review the following section before applying the patch.

Installing and Configuring Access Manager

The Access Manager patches described in this document do not install
Access Manager. Before you install the patch, Access Manager 7.1 must be installed
on the server. For information about installation for Sun Java Enterprise
System 5, see following documents:

For a list of the Access Manager patches that are made obsolete by this
patch and any patches that you must install before you install this patch,
refer to the README file included with this patch.

Caution –

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

Patch Installation Instructions

Beginning with patch 3 (and any subsequent patches unless specifically
noted), you must run the updateschema.sh script on Solaris
and Linux systems or the updateschema.pl script on Windows.
The updateschema script updates the Sun Java System Directory
Server schema with any new attributes required by the patch.

Patch Installation Instructions For Solaris Systems

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/126356-05

Note –

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

patchadd -G /var/spool/patch/126356-05

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

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

The amsilent is based on the amsamplesilent file,
but with some required parameters set according to the Access Manager configuration
files on the system. The password parameters, however, contain default values.
Uncomment and modify the value of each password parameter and carefully check
values of other parameters in this file, as needed for your deployment.

The COMMON_DEPLOY_URI parameter, the URI prefix for
the common domain web application, also contains a default value. If you
have chosen a non-default value for this URI, make sure to update this value.
Otherwise, the redeployment of the web applications with amconfig and
the patch generated amsilent file will fail.

Then, run the following command (shown with Access Manager installed
in the default directory):

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

Caution –

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.

patchrm Command

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

# patchrm 126356-05

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.

Solaris 10 Zones

The Solaris 10 operating system introduced the new concept of “zones.”
Consequently, the patchadd command includes the new -G option,
which adds a patch only to the global zone. By default, the patchadd command
looks for the SUNW_PKG_ALLZONES variable in the pkginfo
of packages to be patched. However, for all Access Manager packages, the SUNW_PKG_ALLZONES variable is not set, and the -G option
is required if Access Manager 7.1 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.1 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:

Patch Installation Instructions For Linux Systems

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.

If the patch is installed on the Access Manager 7.1 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_AM71_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.

Installing the Windows Patch

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

Download and unzip the 126359-05.zip file
in the directory from the previous step.

Stop all Java Enterprise System 5 services.

Run the AM71p1\scripts\prepatch.pl script.

Run AM71p1\126359-05.exe to install the
patch.

Run the AM7p5\scripts\postpatch.pl script.

Restart the Java ES 5 services.

Redeploy the Access Manager applications.

Note –

If Access Manager is deployed to Web Server 7.0, make sure that
Web Server administration server is up and running

Backing Out the Windows Patch

To back out the Windows patch:

Logon to the Windows system as a member of the Administrators
group.

Run the Uninstall_126359-05.bat file.

Run the AM71p1\scripts\postbackout.pl script.

Redeploy the Access Manager applications.

Restart the Java ES 5 services.

Access Manager 7.1 Patch 1 Single WAR Deployment

Note –

Sun provides patch functionality for Access Manager 7.1 WAR deployments
on all platforms in patch 140504, which is available on http://sunsolve.sun.com/. See the patch README file
for more information. (For consistency with other Access Manager 7.1 patches, “02”
is the first release of this patch.)

This section describes new features, installation instructions and known
problems for Access Manager 7.1 patch 1 single WAR deployment.

New Container Versions Supported

The Access Manager 7.1 patch 1 now supports the following containers:

IBM WebSphere Application Server 6.1

BEA WebLogic Server 9.2

The version of Access Manager single web-application (WAR) supported
on these containers is located in zip_install_directory/applications/jdk14. zip_install_directory is
the directory to which you downloaded the .ZIP file for the WAR.

Note –

Even though WebLogic 9.2 is compatible with Sun's JDK version
1.5_04, not all of the classes required by Access Manager are present. Access
Manager single web-application, when deployed from zip_install_directory/applications/jdk15, will result in exceptions thrown
of missing classes. The deployment succeeds and the console is accessible,
but this causes issues with the clients. In general, zip_install_directory/applications/jdk14 should be used for non-Sun or
third party containers, even if their run time environment is JDK 1.5.x.

Applying Patch 1 for Single WAR Deployment

The application of patch 1 is required if you already have an RTM version
of the Access Manager single web-application deployed and wish to redeploy
the Access Manager patch 1 web application. If there is no prior deployment
of Access Manager, then Access Manager single web-application (WAR) provided
under the zip_install_dir/applications directory
can be used.

The patch is provided in a separate directory, zip_install_dir/patch. In this directory, there is a README provided
with instructions on running the patch utility.

The patch utility and related files provided in the ZIP file are only
for applying the patch to Access Manager single web-application downloaded
from the SUN's download site. This patch will not operate with the Access
Manager single WAR web-application generated by using the Java Enterprise
Systems 5 “Configure Later” option with DEPLOY_LEVEL=10.

After you have successfully applied the patch, copy the following property
in the configured instance's AMConfig.properties file
and then restart the container:

com.sun.identity.url.readTimeout=30000

This patch does not support the patch application to the JavaEE SDK
Access Manager WAR file.

Known Issues with Patch 1 WAR Deployment

This section lists the known issues with the Access Manager 7.1 patch
1 WAR deployment.

This issue will only occur when you already have a RTM version of Access
Manager single web-application deployed and would now want to redeploy Access
Manager patch 1 web-application. After you have successfully un-deployed
the RTM version of Access Manager and redeployed the patch 1 version of Access
Manager, follow the steps outlined under the "Workaround" section. If you
are deploying Access Manager patch 1 web-application without any prior installation
of Access Manager in your environment, then the outlined workaround is not
required. Additionally, this workaround is applicable only when using SAML
v.1.

Access Manager 7.1 uses the Java ES Monitoring Framework to capture
statistics and service-related data such as the following:

Number of attempted, successful, and failed authentications

Policy caching statistics

Policy evaluation transaction times

Web Service Security

Access Manager 7.1 extends authentication capabilities to web services
in the following ways:

Inserts tokens to outgoing messages

Evaluates incoming messages for security tokens

Enables point-and-click selection of Authentication providers
for new applications

Single Access Manager WAR file deployment

Access Manager includes a single WAR file you can use to deploy Access
Manager services consistently to any supported container on any supported
platform. The Access Manager WAR file can coexist with the Java Enterprise
System installer, which deploys multiple JAR, XML, JSP, HTML, GIF, and various
properties files.

Support for delegation in logging module - controlling which
Identities are authorized to write to or read from the log files.

Support JCE Based SecureLogHelper - making
it possible to use JCE (in addition to JSS) as a security provider for Secure
Logging implementation

Deprecation Notification and Announcement

Sun Java(TM) System Access Manager 7.1 identity management APIs and
XML templates enable system administrators to create, delete, and manage identity
entries in Sun Java System Directory Server. Access Manager also provides
APIs for identity management. Developers use the public interfaces and classes
defined in the com.iplanet.am.sdk package to integrate
management functions into external applications or services to be managed
by Access Manager. Access Manager APIs provide the means to create or delete
identity-related objects as well as to get, modify, add, or delete the objects'
attributes from Directory Server.

The Access Manager com.iplanet.am.sdk package, commonly
known as AMSDK, will not be included in a future Access Manager release. This
includes all related APIs and XML templates. No migration options are available
now, and no migration options are expected to be available in the future.
The user provisioning solutions provided by Sun Java System Identity Manager
are compatible replacements that you can start to use now. For more information
about Sun Java System Identity Manager, see http://www.oracle.com/us/products/middleware/identity-management/oracle-identity-manager/index.html.

Hardware and Software Requirements

The following table shows the hardware and software that are required
for this release.

Table 2 Hardware and Software Requirements

Component

Requirement

Operating system (OS)

Solaris10 on SPARC, x86, and x64 based
systems, including support for whole root local and sparse root zones.

Java ES Silent Installation Using a State File

Java ES installer silent installation is a non-interactive mode that
allows you to install Java ES components on multiple host servers that have
similar configurations. You first run the installer to generate a state file
(without actually installing any components) and then edit a copy of the state
file for each host server where you plan to install Access Manager and other
components.

To select Access Manager in Legacy (6.x) mode, set the following parameter
(along with other parameters) in the state file before you run the installer
in silent mode:

“Configure Now” Installation Option in
Graphical Mode

If you are running the Java ES Installer in graphical mode with the “Configure
Now” option, on the “Access Manager: Administration (1 of 6)”
panel, select “Legacy (version 6.x style)”, which is the default
value.

“Configure Now” Installation Option in
Text-Based Mode

If you are running the Java ES Installer in text-based mode with the “Configure
Now” option, for Install type (Realm/Legacy) [Legacy] select Legacy, which is the default value.

“Configure Later” Installation Option

If you ran the Java ES Installer with the “Configure Later“
option, you must run the amconfig script to configure Access
Manager after installation. To select Legacy (6.x) mode, set the following
parameter in your configuration script input file (amsamplesilent):

There is a known issue with the single WAR deployed on Weblogic 8.1,
with JAX-RPC initialization. In order for Access Manager to communicate with
the client SDK, you need to replace the JAX-RCP 1.1 jar files with JAX-RPC
1.0 jar files.

Workaround:

There are two ways to obtain the WAR file. One is through the Java Enterprise
System 5 installer with Access Manager set to the Configure Later option,
the other is from Sun's download site.

If you have generated the WAR file through the Java Enterprise System
5 installer with the Configure Later option:

Remove the following JAXRPC 1.1 .jar files
from AccessManager-base/SUNWam/web-src/WEB-INF/lib:

jaxrpc-api.jar

jaxrpc-spi.jar

jaxrpc-impl.jar

Copy the following .jar files from their
respective locations to AccessManager-base/SUNWam/web-src/WEB-INF/lib:

Remove the same .jar files from the /tmp/am-staging/WEB-INF/lib in the staging area.

Update the Webshpere instance's server.xml.
Make the changes to jvmEntries in server.xml if your default instance location is/opt/WebSphere/AppServer/config/cells/node-name/nodes/node-name/servers/server1, as shown below:

Changes required for Distributed Authentication to
work with Access Manager single War for Weblogic and Webshpere (6554372)

The Distributed Authentication WAR requires additional jar files for
parsing for both Weblogic 8.1 and Websphere 5.1 because the container is version
JDK14. The JDK14 .jar files are located in the following
directory of the .zip file:

Single WAR Configurator fails against DS (6562076)

Access Manager deployed as a single WAR fails to configure on Directory
Server 6 with a single component root suffix, for example. dc=example.
However, it works with multi component root suffix, for example dc=example,dc=com. After running the configurator with configuration datastore
as Sun Java System Directory server, it is always advised to go and edit the serverconfig.xml to replace the cn=directory manager
with less privileged user, such as cn=dsameuser. This
user should be available in the directory server with proper access permissions
to the Access Manager service tree.

Workaround: Use the multi component
root suffix, for example dc=example,dc=com.

Multi-server configuration of AM Single WAR on same
host throws exception (6490150)

When configuring the second instance of Access Manager single WAR on
the same host against Directory Server, it throws an exception while updating
the Organization Alias. This issue does not occur if the second instance configured
is on a different host.

The Required Services functionality is not supported in Realm Mode.
Required Services are services that are dynamically added to user entries
when the entries are created. Required Services are not supported for users
created under the Access Control tab (that is, using the realm feature) because
these users will be under the services node. This scenario applies to an Access
Manager 7.1 installation in Legacy Mode or the coexistence of Access Manager
7.1 in Legacy Mode with Sun OpenSSO Enterprise 8.0.

However, the Required Services functionality is supported as follows:

Access Manager 7.1 Legacy Mode with the old Console.

Access Manager 7.1 Legacy Mode with the new Console for users
created under the Directory Manager tab (that is, using the legacy feature)
and for users dynamically created using the amadmin CLI
under the User Management DIT and not the realm DIT.

The problem occurs after you install Access Manager, Messaging Server,
and Calendar Server and configure them to work together, and then install
the Java Enterprise System 5 120955-01 patch. The user encounters a login
error. The error is due to an incompatibility between Policy Agent 2.1 properties
and AMSDK. There is no workaround at this time.

If Access Manager is configured on a Web Server 7.0 instance using a
64–bit JVM, the user encounters a Server Error message when accessing
the console login page. The Web Server error log contains a StackOverflowError exception.

Workaround: Modify the Web Server
configuration by following these steps:

Log in to the Web Server administration console as the Web
Server administrator.

Click Edit Configuration.

In the Platform field,
select 64, then click Save.

Click the Java tab, and then click the JVM Settings tab.

Under Options, look for the minimum heap size entry (for example
: -Xms). The minimum heap size value should be at least 512m. For example,
if the heap size value is not -Xms512m or greater, then change the value to
at least -Xms512m.

The maximum heap size value should be at least 768m. If the
maximum heap size is not -Xmx768m or greater, then change the value to at
least -Xmx768m.

Set the Java stack size to 512k or 768k by using -Xss512k or -Xss768k. You can leave it at the default
size for 64-bit JVM on Solaris Sparc (1024k) by leaving it blank.

Access Manager 7.1 legacy mode has the following incompatibilities in
the core authentication module from Access Manager 6 2005Q1:

Organization Authentication Modules are removed in legacy
mode.

The presentation of the “Administrator Authentication
Configuration” and “Organization Authentication Configuration”
has changed. In the Access Manager 7.1 Console, the drop-down list has ldapService selected by default. In the Access Manager 6 2005Q1
Console, the Edit button was provided, and the LDAP module was not selected
by default.

Workaround: None.

Delegated Administrator commadmin utility
does not create a user (6294603)

The Delegated Administrator commadmin utility with
the -S mail,cal option does not create a user in the default
domain.

Workaround: This problem occurs
if you upgrade Access Manager to version 7.1 but you do not upgrade Delegated
Administrator.

If you do not plan to upgrade Delegated Administrator, follow these
steps:

In the UserCalendarService.xml file,
mark the mail, icssubcribed, and icsfirstday attributes as optional instead of required. This file is located
by default in the /opt/SUNWcomm/lib/services/ directory
on Solaris systems.

In Access Manager, remove the existing XML file by running
the amadmin command, as follows:

Incorrect console redirection behind a load balancer
(6480354)

If you have Access Manager instances deployed behind a load balancer,
login to the Access Manager Console may be redirected to one of the Access
Manager instances rather than to the load balancer. The URL in the browser
also changes to the Access Manager instance. For example, this problem can
occur if you login into the Console using this URL:

http://loadbalancer.example.com/amserver/realm

This redirection can occur in both Realm mode and Legacy mode deployments.

There are two workarounds for this issue. You can use either one:

Login with either of the following URLs:

http://loadbalancer/amserver/UI/Login

http://loadbalancer/amserver

In AMConfig.properties, set the com.sun.identity.loginurl property to the name of the loadbalancer. This needs to be done
on each Access Manager Instance behind the load balancer.

If you install the Access Manager SDK without a web container by running
the Java ES 5 installer with the Configure Now option, the com.iplanet.am.notification.url property in the AMConfig.properties file is set to NOTIFICATION_URL. If you don't perform any additional web container configuration,
users will not receive notifications from the remote Access Manager server.

If you deploy Access Manager 7.1 into a secure (SSL enabled) BEA WebLogic
8.1 SP4 instance, an exception occurs during the deployment of each Access
Manager web application.

Workaround: Follow these steps:

Apply the WebLogic 8.1 SP4 patch JAR CR210310_81sp4.jar, which is available from BEA.

In the /opt/SUNWam/bin/amwl81config script,
(Solaris systems) or /opt/sun/identity/bin/amwl81config script
(Linux systems), update the doDeploy function and the undeploy_it function to prepend the path of the patch JAR to the wl8_classpath, which is the variable that contains the classpath used to deploy and un-deploy the Access Manager web applications.

Find the following line containing the wl8_classpath:

wl8_classpath= ...

Immediately after the line you found in Step 2, add the following
line:

wl8_classpath=path-to-CR210310_81sp4.jar:$wl8_classpath

The amconfig script does not update
the realm/DNS aliases and platform server list entries (6284161)

In a multiple server deployment, the amconfig script
does not update the realm/DNS aliases and platform server list entries for
additional Access Manager instances.

Default Access Manager mode is realm in the configuration
state file template (6280844)

By default, the Access Manager mode (AM_REALM variable)
is enabled in the configuration state file template.

Workaround: To install or configure
Access Manager in Legacy mode, reset the variable in the state file:

AM_REALM = disabled

Performance Issues

In Realm mode, creation of a new group generates
Group Admin with ACIs that never get used (6485695)

If Access Manager is installed in Realm mode, whenever a new group is
created, Access Manager dynamically creates a new Group Admin with the ACIs
necessary to manage the group. In Realm mode, these Group Admin ACIs are not
used. Directory Server, however, still evaluates them while processing entries
under the suffix, which can degrade Access Manager performance, particularly
if a deployment creates a large number of groups.

Workaround: The workaround for this
problem involves two parts:

Preventing Access Manager from creating a Group Admin and
corresponding ACIs whenever a new group is created

Removing any existing Group Admin ACIs from Directory Server

Preventing Group Admin ACIs From Being Created

The following procedure prevents Access Manager from creating a Group
Admin and corresponding ACIs whenever a new group is created.

Note –

This procedure permanently prevents the creation of Group Admins
and corresponding ACIs whenever a new group is created. Use this procedure
only if this behavior is appropriate for your specific deployment.

Backup the amAdminConsole.xml file. This
file is located in the following directory, depending on your platform:

Restart the Access Manager web container. (If you plan to
remove ACIs from Directory Server, as described in the next procedure, wait
and restart the web container after you finish that procedure.)

Removing Existing Group Admin ACIs

Note –

The following procedure uses the ldapsearch and ldapmodify utilities to find and remove the Group Admin ACIs. If
your deployment is using Directory Server 6.0, you can also use the Directory
Server Control Center (DSCC) or the dsconf command to perform
these functions. For more information, see the Directory Server 6.0 documentation:

Portal Server and Access Manager are installed on the same server. With
Access Manager installed in Legacy mode, login to the new Access Manager Console
using /amserver. If you choose an existing user and try
to add services (such as NetFile or Netlet), the old Access Manager Console
(/amconsle) suddenly appears.

Workaround: None. The current version
of Portal Server requires the Access Manager 6 2005Q1 Console.

Console does not return the results set from Directory
Server after reaching the resource limit (6239724)

Install Directory Server and then Access Manager with the existing DIT
option. Login to the Access Manager Console and create a group. Edit the users
in the group. For example, add users with the filter uid=*999*.
The resulting list box is empty, and the console does not display any error,
information, or warning messages.

Workaround: The group membership
must not be greater than the Directory Server search size limit. If the group
membership is greater, change the search size limit accordingly.

This error becomes evident after the Java ES installer migration scripts
are run. The ContainerDefaultTemplateRole attribute is
not automatically added to the organization when the organization is migrated
from an existing directory information tree (DIT) or from another source.

Workaround: Use the Directory Server
console to copy the ContainerDefaultTemplateRole attribute
from another Access Manager organization and then add it to the affected organization.

Command Line Issue

Organization Admin role is fails to create a new
user with the amadmin command line utility (6480776)

An administrator assigned the Organization Admin role is not able to
create a new user with the amadmin command line utility due to incorrect logging
privileges.

Workaround: Both the Organization Admin and the Top-level admin may
set the permissions. To do so through the Administration Console:

Go to the organization to which the Organization Admin belongs.

Click on the Privileges tab.

Click on the Organization Admin Role link.

Select Read and write access to all log files or Write access to all log files.

After you install Access Manager, login as amadmin and
add the o, sunPreferredDomain, associatedDomain, sunOrganizationAlias, uid,
and mail attributes to the Unique Attribute List. If you
create two new organizations with the same name, the operation fails, but
Access Manager displays the “organization already exists” message
rather than the expected “attribute uniqueness violated” message.

Session and SSO Issues

System creates invalid service host name when load
balancer has SSL termination (6245660)

If Access Manager is deployed with Web Server as the web container using
a load balancer with SSL termination, clients are not directed to the correct
Web Server page. Clicking the Sessions tab in the Access Manager Console returns
an error because the host is invalid.

Workaround: In the following examples,
Web Server listens on port 3030. The load balancer listens on port 80 and
redirects requests to Web Server.

In the web-server-instance-name/config/server.xml file, edit the servername attribute to point
to the load balancer, depending on the release of Web Server you are using.

Using HttpSession with third-party
web containers

The default method of maintaining sessions for authentications is “internal
session” instead of HttpSession. The default invalid
session maximum time value of three minutes is sufficient. The amtune script
sets the value to one minute for Web Server or Application Server. However,
if you are using a third-party web container (IBM WebSphere or BEA WebLogic
Server) and the optional HttpSession, you might need to
limit the web container's maximum HttpSession time limit
to avoid performance problems.

Policy Issues

Deletion of dynamic attributes in Policy Configuration
Service causing issues in editing of policies (6299074)

The deletion of dynamic attributes in Policy Configuration Service causes
issues in editing of policies for this scenario:

Create two dynamic attributes in the Policy Configuration
Service.

Create a policy and select the dynamic attributes (from Step
1) in the response provider.

Remove the dynamic attributes in the Policy Configuration
Service and create two more attributes.

Try to edit the policy created in Step 2.

Results are: “Error Invalid Dynamic property being set.”
No policies were displayed in the list by default. After a search is done,
the policies are displayed, but you cannot edit or delete the existing policies
or create a new policy.

Workaround: Before removing the dynamic
attributes from the Policy Configuration Service, remove the references to
those attributes from the policies.

Error displayed when performing AMIdentity.modifyService
(6506448)

When using AMIdentity.modifyService to set desktop
service dynamic attribute on a realm, Access Manager returns a null pointer
exception.

Workaround:Add the following property
to AMConfig.properties and then restart the server.:

com.sun.am.ldap.connnection.idle.seconds=7200

Group members don't show up in selected list (6459598)

The problem occurs under the following conditions:

Define a realm with the following realm configuration:

Top-level realm is amroot. A subrealm is example.com.

The subrealm example.com has two data stores: exampleDB and exampledminDB.

The data store exampleDB contains all the
users starting at dc=example,dc=com. Supported LDAPv3 operations
is set to user=read,write,create,delete,service.

The data store exampleadminDB contains
an admin group for the realm. The admin group is DN: cn=example.com
Realm Administrators,ou=Groups,dc=example,dc=com. This group has
a single member, scarter. Supported LDAPv3 operations
is set to group=read,write,create,delete.

Click the Subjects tab, then Groups, then the entry for example.com Realm Administrators.

Click the User tab.

All the users in the exampleDB data store show up
as available, but scarter does not show up in the Selected
field.

Workaround: Add the operation user=read to the supported LDAPv3 operations in the exampleadminDB data store.

SSL Issue

The amconfig script fails when SSL certificate is
expired. (6488777)

If the Access Manager container is running in SSL mode, and the container
SSL certificate is expired, amconfig fails and may cause
classpath corruption.

Workaround: If you have already run amconfig with an expired certificate, and the classpath is corrupted,
first obtain a valid SSL certificate. Revert to the original domain.xml file, or a copy of the domain.xml file, in
which the classpath is not corrupted. Then rerun the amconfig command:

/opt/SUNWam/bin/amconfig -s $PWD/amsamplesilent

Samples Issue

Clientsdk samples directory contains unwanted makefile
(6490071)

Sample files are included in the Client SDK. These demonstrate how to
write stand-alone programs and how to write web applications. The samples
are located under the directory where you generated the Makefile.clientsdk, and in the following subdirectories:

.../clientsdk-samples/

.../clientsdk-webapps/

Clientsdk-samples includes samples for authentication, logging, policy
and SAML stand-alone programs. Clientsdk-webapps includes samples for user
management, service management, and policy programs. Each sample has a Readme.html
file with instructions on compiling and running the sample program.

In order to compile the samples, the makefile should be run in the corresponding
sub-directory. The Top-level makefile does not compile the samples in the
sub-directories.

Linux OS Issues

If you are running Application Server 8.1 on Red Hat Linux, the stack
size of the threads created by the Red Hat OS for Application Server is 10
Mbytes, which can cause JVM resource problems when the number of Access Manager
user sessions reaches 200.

Workaround: Set the Red Hat OS operating
stack size to a lesser value such as 2048 or even 256 Kbytes, by executing
the ulimit command before you start Application Server.
Execute the ulimit command on the same console that you
will use to start Application Server. For example:

Workaround: In zh_TW and es locales on HP-UX platform, Access Manager has to be configured
in "Config Later" mode only. Start the JavaES installer, install the Access
Manager product and exit the JavaES installer. Then invoke the Access Manager
configurator as shown below:

Administration console components displayed in English
in the zh locale (6470543)

When setting the browser locale to zh, the Administration
console components are displayed in English, for example the Version, Help
and Logout buttons.

Workaround: Set browser locale setting
to zh-cn instead of zh.

Current Value and New value are incorrectly displayed
in the console (6476672)

In the localized version of the Administration console, the labels for
the Current Value and New Value attributes are incorrectly displayed as label.current.value
and label.new.value, respectively.

Policy condition date must be specified according
to English custom (6390856)

Policy condition date format labels under the Chinese locale are not
displayed according to Chinese customs. Labels are proposing a date format
like English date format. Related fields also accept English date format values.

Workaround: For each field, follow
the date format example given in the field label.

Removing UTF-8 is not working in Client Detection
(5028779)

The Client Detection function is not working properly. Changes made
in the Access Manager 7.1 Console are not automatically propagated to the
browser.

Workaround: There are two workarounds:

Restart the Access Manager web container after you make a
change in the Client Detection section.

or

Follow these steps in the Access Manager Console:

Click Client Detection under the Configuration tab.

Click the Edit link for genericHTML.

Under the HTML tab, click the genericHTML link.

Enter the following entry in the character set list: UTF-8;q=0.5 (Make sure that the UTF-8 q factor is lower
than the other character sets of your locale.)

Multi-byte messages in log files in the /var/opt/SUNWam/logs directory
are displayed as question marks (?). Log files are in native
encoding and not always UTF-8. When a web container instance starts in a certain
locale, log files will be in native encoding for that locale. If you switch
to another locale and restart the web container instance, the ongoing messages
will be in the native encoding for the current locale, but messages from previous
encoding will be displayed as question marks.

Workaround: Make sure to start any
web container instances always using the same native encoding.

Access Manager supports non-ascii character passwords
if Directory Server is configured to support them (6661374)

Access Manager supports non-ascii characters in password fields only
if the Directory Server is configured to support them. The Sun Java System
Directory Server 7-Bit check plug-in should be disabled to let non-ascii characters
to be stored. This flag, by default, is enabled in Directory Server 5.2 and
should be disabled if non-ascii characters are needed to be entered in the userPassword entery. The 7-Bit Check Plug-in is disabled by default
in Directory Server versions 6.0 and above.

Document the roles and filtered roles support for
LDAPv3 plug-in (6365196)

After applying the respective patch, you can configure roles and filtered
roles for the LDAPv3 plug-in, if the data is stored in Sun Java System Directory
Server (fixes problem ID 6349959). In the Access Manager 7.1 Administration
console, in LDAPv3 configuration for the “LDAPv3 Plug-in Supported Types
and Operations” field, enter the values as:

role: read,edit,create,delete
filteredrole: read,edit,create,delete

You can enter one or both of the above entries, depending on the roles
and filtered roles you plan to use in your LDAPv3 configuration.

Document unused properties in the AMConfig.properties file (6344530)

The following properties in the AMConfig.properties file
are not used:

com.iplanet.am.directory.host
com.iplanet.am.directory.port

Document how to enable XML encryption (6275563)

To enable XML encryption for either Access Manager or Federation Manager
using the Bouncy Castle JAR file to generate a transport key, follow these
steps:

If you are using a JDK version earlier than JDK 1.5, download
the Bouncy Castle JCE provider from the Bouncy Castle site (http://www.bouncycastle.org/). For example, for
JDK 1.4, download the bcprov-jdk14-131.jar file.

If you downloaded a JAR file in the previous step, copy the
file to the jdk_root/jre/lib/ext directory.

For the domestic version of the JDK, download the JCE Unlimited
Strength Jurisdiction Policy Files from the Sun site (http://www.oracle.com/technetwork/java/index.html)
for your version of the JDK. For IBM WebSphere, go to the corresponding IBM
site to download the required files.

Copy the downloaded US_export_policy.jar and local_policy.jar files to the jdk_root/jre/lib/security directory.

If you are using a JDK version earlier than JDK 1.5, edit
the jdk_root/jre/lib/security/java.security file
and add Bouncy Castle as one of the providers. For example:

Previously, you had to start the SecurID authentication process (amsecuridd) manually. Now, the SecurID authentication process runs similar
to the other authentication modules, fully-contained within the Access Manager
7.1 server process.

The Java version of SecurID requires the following files:

authapi.jar (SecurID API) in the following
directory:

WAR file deployment: WEB-INF/lib directory

Installer (package-based) deployment: AccessManager-base/SUNWam/lib

log4j.properties, rsa_api.properties, and sdconf.rec files in the default /opt/ace/data directory.

To configure a SecurID authentication module:

Log in to the Access Manager 7.1 Administration console.

Under Access Control, click realm-name and
then Authentication.

Under Module Instances, click New and add a New Module Instance
with Type as SecurID.

Policy Agent 2.2 Collection

Redistributable Files

Sun Java System Access Manager 7.1 does not contain any files that you
can redistribute to non-licensed users of the product.

System Virtualization Support

System virtualization is a technology that enables multiple operating
system (OS) instances to execute independently on shared hardware. Functionally,
software deployed to an OS hosted in a virtualized environment is generally
unaware that the underlying platform has been virtualized. Sun performs testing
of its Sun Java System products on select system virtualization and OS combinations
to help validate that the Sun Java System products continue to function on
properly sized and configured virtualized environments as they do on non-virtualized
systems. For information about Sun support for Sun Java System products in
virtualized environments, see System Virtualization Support in
Sun Java Systems Products in http://docs.sun.com/coll/1292.2.

How to Report Problems and Provide Feedback

If you have problems with Access Manager or Sun Java Enterprise System,
contact Sun customer support using one of the following mechanisms:

This site
has links to the Knowledge Base, Online Support Center, and ProductTracker,
as well as to maintenance programs and support contact numbers.

The telephone dispatch number associated with your maintenance
contract

So that we can best assist you in resolving problems, please have the
following information available when you contact support:

Description of the problem, including the situation where
the problem occurs and its impact on your operation

Machine type, operating system version, and product version,
including any patches and other software that might be affecting the problem

Detailed steps on the methods you have used to reproduce the
problem

Any error logs or core dumps

Sun Welcomes Your Comments

Sun is interested in improving its documentation and welcomes your comments
and suggestions. Go to http://docs.sun.com/ and
click Send Comments.

Provide the full document title and part number in the appropriate fields.
The part number is a seven-digit or nine-digit number that can be found on
the title page of the book or at the top of the document. For example, the
part number of the Access Manager Release Notes is 819-4683-24.

Additional Sun Resources

You can find useful Access Manager information and resources at the
following locations:

Accessibility Features for People With Disabilities

Related Third-Party Web Sites

Third-party URLs are referenced in this document and provide additional,
related information.

Note –

Oracle is not responsible for the availability of third-party
Web sites mentioned in this document. Oracle does not endorse and is not responsible
or liable for any content, advertising, products, or other materials that
are available on or through such sites or resources. Oracle will not be responsible
or liable for any actual or alleged damage or loss caused by or in connection
with the use of or reliance on any such content, goods, or services that are
available on or through such sites or resources.