Sun OpenSSO Enterprise 8.0 Release Notes

OpenSSO Enterprise 8.0 Issues

For more information about OpenSSO Enterprise issues, see:

https://opensso.dev.java.net/servlets/ProjectIssues

Web Container and Server Issues

CR 6935896: Undeploying OpenSSO Enterprise on Sun GlassFish 2.1 using the CLI is unsuccessful

Trying to undeploy OpenSSO Enterprise 8.0 on Sun GlassFish 2.1 or Sun Java System Application Server 9.1 Update 2 is not successful and returns an “Invalid user or password” error (reported by CR 6808492). Subsequent attempts also fail with the same error message.

Workaround. This problem has been fixed in OpenSSO Enterprise 8.0 Update 1 Patch 3 (patch ID 141655-04). The following workaround applies to OpenSSO Enterprise 8.0 deployments before patch 3:

  1. In the appSrvr_install_directory/domains/domain1/config/domain.xml file, add the following entry under the java-config attribute:

    <jvm-options>
    -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false
    </jvm-options>
  2. Restart the GlassFish or Application Server instance.

  3. Undeploy OpenSSO Enterprise 8.0 using the GlassFish or Application Server asadmin undeploy command.

4077: OpenSSO Enterprise configuration on WebLogic Server requires new ldapjdk.jar

OpenSSO Enterprise configuration fails on WebLogic Server because weblogic.jar bundles an older ldapjdk.jar file.

Sun provides a new ldapjdk.jar file that includes security and performance related fixes. You must provide the following workaround for both WebLogic Server 9.2 and WebLogic Server 10.

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

  1. Extract ldapjdk.jar from opensso.war in a temporary directory using the following command:

    jar xvf opensso.war WEB-INF/lib/ldapjdk.jar

  2. Copy the above extracted ldapjdk.jar to the WebLogic lib directory.

    For example, for WebLogic Server 10 on Solaris or Linux systems: BEA_HOME/weblogic_10.0/server/lib

    Or, for WebLogic Server 9.2 on Windows:BEA_HOME\weblogic92\server\lib

  3. Prefix the path to this ldapjdk.jar to the existing classpath. by editing the startup script used to start WebLogic Server. In the following examples, BEA_HOME is where WebLogic Server is installed.

    For WebLogic 9.2 on Windows, edit:

    BEA_HOME\weblogic92\samples\domains\wl_server\bin\startWebLogic.cmd

    Change set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% to:

    set CLASSPATH=BEA_HOME\weblogic92\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%
    

    For WebLogic 10 on Windows, edit:

    BEA_HOME\wlserver_10.0\samples\domains\wl_server\bin\startWebLogic.cmd

    Change set CLASSPATH=%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH% to:

    set CLASSPATH=
    BEA_HOME\wlserver_10.0\server\lib\ldapjdk.jar;%CLASSPATH%;%MEDREC_WEBLOGIC_CLASSPATH%

    For WebLogic 9.2 MP2 on Solaris or Linux, edit:

    /bea/weblogic92/samples/domains/wl_server/bin/ startWebLogic.sh

    or

    /usr/local/bea/user_projects/domains/base_domain/bin/startWebLogic.sh

    Change CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" to:


    CLASSPATH=
    "BEA_HOME/weblogic92/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"

    For WebLogic 10 on Solaris or Linux, edit:

    /bea/wlserver_10.0/samples/domains/wl_server/bin/startWebLogic.sh

    or

    /bea/user_projects/domains/wl10_domain/bin/startWebLogic.sh

    Change CLASSPATH="${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}" to

    CLASSPATH=
    "BEA_HOME/wlserver_10.0/server/lib/ldapjdk.jar${CLASSPATH}${CLASSPATHSEP}${MEDREC_WEBLOGIC_CLASSPATH}"
  4. Restart the server.

  5. Configure OpenSSO Enterprise.

WebLogic Server StuckThreadMaxTime value is exceeded during configuration

If you are configuring WebLogic Server 9.2 MP2 or 10 using the Configurator and you take longer than 600 seconds to finish the configuration, the following error is returned to the terminal and WebLogic Server domain and server logs:

<Error> <WebLogicServer> <BEA-000337> <[STUCK] Exe 
cuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy 
for "681" seconds working on the request "Http Request: /opensso/setup/setSetup 
Progress", which is more than the configured time (StuckThreadMaxTime) of "600" 
seconds. Stack trace: ... 

This error occurs because the WebLogic Server has exceeded its “Stuck Thread Max Time:” default value of 600 seconds.

Workaround. If the Configurator does not respond, restart it. Also, consider setting the WebLogic Server “Stuck Thread Max Time” value from its default 600 seconds to a larger value such as 1200 seconds. Use the WebLogic Console to change this value (base_domain > Environment > Servers > Admin Server > Configuration/Tuning).

4099: ID-WSF sample with JDK 1.4 WAR returned exception

On WebLogic Server 8.1, opensso-client-jdk14.war configured for ID-WSF returned an error when looking for service.

Workaround. Add following JAR files under weblogic-home/jdk142_08/jre/lib/endorsed:

To obtain these JAR files, contact your Sun representative.

4094: Multi-server setup fails when amadmin password and directory manager password for configuration data store are not the same

This issue occurs only if the following conditions are met:

Workaround. There are two parts to this workaround:

  1. Make sure your configuration Directory Server bind dn password is same as the amadmin password.

  2. Configure the second and additional OpenSSO Enterprise servers. To perform the second server installation and point to the first OpenSSO Enterprise server's configuration directory, simply access the Configurator page of the second OpenSSO Enterprise server and enter the amadmin password, cookie domain, and other details for Step 1 and Step 2.

    For Step 3, do not select the Add to Existing Deployment. Instead, select the first instance option and provide the same Directory Server name, port, DN, password, and encryption key of your first server. Then, proceed with the configuration as usual.

4055: Error occurred after adding an advanced property in console

Adding an advanced property in the Console caused OpenSSO Enterprise server to return an error. This problem can occur after adding any advanced configuration property.

Workaround. If you change the default server configuration in the Console, you must restart the OpenSSO Enterprise server web container.

3858: Out of memory exceptions occur under heavy load with JDK 1.5 and 1.6 SunPKCS11 provider

JDK 1.5 and 1.6 contain a list of PKCS11 providers. The default is sun.security.pkcs11.SunPKCS11 (see the provider list below). Under a heavy load, this provider will generate an Out of Memory Exception (OOME) for the web container and cause the container to crash. At minimum, the following scenarios are impacted:

The issue is currently under investigation and might impact other web container platforms not listed above.

Workaround. Remove the SunPKCS11 provider from the provider list in the java.security file for the JVM. For example, if the security provider section in your java.security file (found in JDK_Path/jre/lib/security/) looks like:

security.provider.1=sun.security.pkcs11.SunPKCS11 \
   ${java.home}/lib/security/sunpkcs11-solaris.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider

Change it to:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider

Note. This workaround can lower your performance because the provider used now is not as optimized as the SunPKCS11 provider. It also prevents you from using hardware security tokens if the SunPKCS11 provider is required.

3837: Configuration fails on Oracle Application Server 10g

With Oracle Application Server 10g version 10.1.3.1 as the web container, OpenSSO configuration failed with an exception error.

Workaround. Before you configure OpenSSO, add the following JVM option to the “Server Properties” for the target Oracle Application Server 10g server instance:

-Doc4j.jmx.security.proxy.off=true

2222: Password reset and account lockout services report notification errors

OpenSSO Enterprise submits email notifications using the unqualified sender name, Identity-Server, which returns error entries in the logs.

Workaround. Change the sender name from Identity-Server to Identity-Server@hostname.domainname in the following files:

Data Store Issues

4102: TTL for service management configuration is not working

Time to live (TTL) for service management configuration is not working because the TTL property is not being initialized.

4085: OpenSSO Enterprise is unable to store the CRL in the LDAP directory

After getting the certificate revocation list (CRL) from the CRL distribution point extension, OpenSSO Enterprise does not store the CRL in the LDAP directory.

3827: Replication configuration hangs on second GlassFish instance

In this scenario, OpenSSO Enterprise is deployed on two GlassFish (or Application Server 9.1) instances on Windows Vista server. During the configuration of the second OpenSSO Enterprise instance, replication of the configuration using the “Add to Existing Deployment” option hangs.

Workaround. This issue still exists on Windows Vista systems. For Windows systems other than Vista, add the following GlassFish (or Application Server 9.1) JVM option:

-Dcom.sun.enterprise.server.ss.ASQuickStartup=false

3350, 2867: LDAP Follows Referral should be disabled for Active Directory Data Store

An Active Directory data store sometimes hangs the system. This problem can also occur when you are creating a new Active Directory data store.

Workaround. In the OpenSSO Enterprise Admin Console, disable LDAP Follows Referral for the Active Directory data store:

  1. Click Access Control, top-level-realm, Data Stores, ActiveDirectory-data-store-name.

  2. Uncheck Enabled for the LDAP Follows Referral.

  3. Save your changes.

Failover does not occur for Access Manager SDK (AMSDK) plug-in

If OpenSSO Enterprise is configured with the AMSDK plug-in and the directory server is set up for MMR, failover does not occur if a directory server instance goes down.

Authentication Issues

4103: Windows Desktop SSO authentication module returns “No Configuration Found” error

If you configure a Windows Desktop SSO authentication module to perform a Kerberos authentication from Internet Explorer 6.0 on Windows Server 2003, the “No configuration found" error is returned.

4100: Certificate authentication with CRL checking fails

If you configure Certificate authentication and enable “Match Certificate to CRL” the authentication fails. See also the related issue 4085: OpenSSO Enterprise is unable to store the CRL in the LDAP directory.

4054: amadmin authentication fails with URL org parameter

If the OpenSSO Enterprise Admin (amadmin) creates a new realm (such as myorg) and later tries to log in to the new realm as follows:

http://host:port/opensso/UI/Login?org=myorg

OpenSSO Enteprise returns an Authentication Failed error.

Workaround. As amadmin, you can log in only to the root realm (and only to Data Store or Application modules).

1781: amadmin login fails for non Data Store authentication

If you change the authentication module for the root realm to anything besides DataStore, amadmin will not be able to log into the Console.

Workaround. Log in using http://host.domain/deployurl/UI/Login?module=DataStore.

Policy Issues

3952: Server samples are missing the policy samples link

The index.html under host:port/uri/samples displays:

1. Authentication Samples
2. ID-FF Sample
3. SAMLv2 Sample
4. Multi-Federation Protocols Sample

However, the following link to the policy samples is missing in index.html: host:port/uri/samples/policy/policy-plugins.html

Workaround: Open the host:port/uri/samples/policy/policy-plugins.html file in your browser.

3949: OCSP checking needs permission added to server.policy file

To enable OCSP checking for an OpenSSO web container that has enabled the Java Security Manager, add the following permission to the server.policy (or equivalent) file:

permission java.security.SecurityPermission "getProperty.ocsp.*";

3796: Creation of Fedlet in console failed in a console only deployment

If you generate a console only deployment, creating a Fedlet using the Console Common Tasks failed with an error message stating that there was no file or directory for sp-extended.xml. The com.iplanet.services.configpath property was not set by the console only Configurator.

Workaround. Edit the AMConfig.properties file and set the com.iplanet.services.configpath property to the configuration directory. For example:

com.iplanet.services.configpath=/consoleonly

2381: Access Manager Roles policy subject is supported only with Access Manager repository data store

The Access Manager Roles policy subject is supported only with the Access Manager Repository (AMSDK) data store. By default, this subject is disabled in the policy configuration. Therefore, enable the Access Manager Roles policy subject only if the data store type is configured to use the AMSDK plug-in.

For more information, see Chapter 15, Enabling the Access Manager SDK (AMSDK) Identity Repository Plug-in, in Sun OpenSSO Enterprise 8.0 Installation and Configuration Guide.

Session Issues

3910: setup.bat of ssoSessionTools.zip fails to install tools

After you unzip ssoSessionTools.zip, running the setup.bat script fails to install the session scripts and returns the following error:

Unable to locate JRE meeting specification "1.4+"

Workaround. In the setup.bat script, remove -version:"1.4+" from the java.exe command and rerun the script.

2827: Configuring a site does not add the second server to the site

Session failover configuration does not add the second OpenSSO Enterprise instance to the assigned servers list.

Workaround. Use the OpenSSO Enterprise Console or ssoadm utility to manually add the second server instance to the servers list.

Command-Line Utilities Issues

4079: ssoadm import-svc-cfg command fails when using Directory Server as the configuration data store

Sometimes the import-svc-cfg subcommand fails because OpenSSO Enterprise cannot delete nodes in the Service Manager data store. The following scenarios can cause this problem:

  1. Configure OpenSSO Enterprise using a remote Sun Java System Directory Server as the configuration data store.

  2. Export the service XML file by using the ssoadm export-svc-cfg command.

  3. Re-import the service XML data obtained in Step 2 using the ssoadm import-svc-cfg command.

  4. When you are asked to delete the existing data, choose yes.

    The following error message is returned: Unexpected LDAP exception occurred.

Workaround. Re-execute the ssoadm import-svc-cfg command until it succeeds.

3955: Unable to execute the ssoadm command

You are unable to execute the ssoadm command with the get-realm due to this exception.

Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:
FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password
Logging configuration class "com.sun.identity.log.s1is.LogConfigReader" failed
com.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction:
FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password
AdminTokenAction:  FATAL ERROR: Cannot obtain Application SSO token.
Check AMConfig.properties for the following properties
       com.sun.identity.agents.app.username
       com.iplanet.am.service.password

Check if the amadmin password is different from the directory manager password for the service management data store. If yes, apply the following workaround.

Workaround. Modify the server configuration XML as follows:

  1. Log in to the OpenSSO Console as amadmin.

  2. Use the ssoadm.jsp get-svrcfg-xml to get the server configuration XML.

  3. Use encode.jsp to encode the amadmin password.

  4. Set the encoded password in the two places represented by amadmin-password in the XML. For example:

    <User name="User1" type="proxy">
                <DirDN>
                    cn=puser,ou=DSAME Users,dc=opensso,dc=java,dc=net
                </DirDN>
                <DirPassword>
                   amadmin-password
                </DirPassword>
            </User>
            <User name="User2" type="admin">
                <DirDN>
                    cn=dsameuser,ou=DSAME Users,dc=opensso,dc=java,dc=net
                </DirDN>
                <DirPassword>
                   amadmin-password
                </DirPassword>
            </User>
            <BaseDN>
                dc=opensso,dc=java,dc=net
            </BaseDN>
        </ServerGroup>
  5. Use the ssoadm.jsp set-svrcfg-xml to set the altered server configuration XML.

2905: jss4.jar entry is missing in the ssoadm classpath

After running the setup script for the ssoadm utility, trying to run ssoadm returns a NoClassDefFoundError error. This problem occurs for an upgraded OpenSSO Enterprise instance.

Workaround. To use JSS, add jss4.jar to the classpath and set the LD_LIBRARY_PATH environment variable. (If you are using the default JCE, jss4.jar is not required to be in the classpath.)

Client SDK Issues

4081: SMS cache is disabled by default on the Client SDK

For a Client SDK installation, the service management service (SMS) cache is disabled by default.

Workaround: For Web Services Security (WSS) applications, set com.sun.identity.sm.cache.enabled=false in the AMConfig.properties file; otherwise the fix for issue 3171 will not work.

For all other Client SDK applications, set com.sun.identity.sm.cache.enabled=true in the AMConfig.properties file to enable SMS caching, which can prevent performance problems.

4080: Client SDK Configurator puts the wrong shared secret in the AMConfig.properties file

The Client SDK WAR file Configurator puts the wrong shared secret in the AMConfig.properties file.

Workaround. Copy the shared secret value and the password encryption key from the OpenSSO Enterprise server to the Client SDKAMConfig.properties file under the $HOME/OpenSSOCLient directory.

Federation and SAML Issues

3923: Creating an entity (IDP or SP) in Console Common Tasks page fails on Oracle Application Server

With OpenSSO Enterprise deployed on Oracle Application Server, creating an entity (IDP or SP) in the Console Common Tasks page causes an exception.

Workaround. When opensso.war is deployed on Oracle Application Server, disable the import option for the oracle.xml file in the deployment plan view (Deploy: Deployment Settings > Configure Class Loading > oracle.xml).

3065: Same context ID is used for all users in ID-FF log records

All ID-FF log records have same the context (or login) ID, even if they are for different users.

2661: logout.jsp did not compile on WebSphere Application Server 6.1

The logout.jsp file requires JDK 1.5, but the JDK source level for JSP files is set to JDK 1.3 on IBM WebSphere Application Server 6.1.

Workaround. See the workaround for 1977: SAMLv2 sample configure.jsp files fail on WebSphere Application Server 6.1.

1977: SAMLv2 sample configure.jsp files fail on WebSphere Application Server 6.1

On a WebSphere Application Server 6.1 instance, the /sample/saml2/sp/configure.jsp and /sample/saml2/idp/configure.jsp files fail to compile. The configure.jsp files require JDK 1.5, but the JDK source level for JSP files is set to JDK 1.3 on WebSphere Application Server 6.1.

Workaround: Edit the JSP engine configuration parameters to set the JDK source level to 1.5:

  1. Open the WEB-INF/ibm-web-ext.xmi file.

    JSP engine configuration parameters are stored either in a web module's configuration directory or in a web module's binaries directory in the WEB-INF/ibm-web-ext.xmi file:

    Configuration directory. For example:

    {WAS_ROOT}/profiles/profilename/config/cells/cellname/applications/
    enterpriseappname/deployments/deployedname/webmodulename/

    Binaries directory, if an application was deployed into WebSphere Application Server with the flag “Use Binary Configuration” flag set to true. For example:

    {WAS_ROOT}/profiles/profilename/installedApps/nodename/
    enterpriseappname/webmodulename/
  2. Delete the compileWithAssert parameter by either deleting the statement from the file or enclosing the statement with comment tags (<!— and –>).

  3. Add the jdkSourceLevel parameter with the value of 15. For example:

    <jspAttributes xmi:id="JSPAttribute_1" name="jdkSourceLevel" value="15"/>

    Note: The integer (_1) in JSPAttribute_1 must be unique within the file.

  4. Save the ibm-web-ext.xmi file.

  5. Restart the application.

For more information about the jdkSourceLevel parameter as well as other JSP engine configuration parameters, see:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.nd.doc/info/ae/ae/rweb_jspengine.html

Web Services Security (WSS) Issues

4057: Dynamic web service provider configuration with endpoint does not take effect

If you set up the proxy use case based on the loan sample for Web Services Security (WSS) and create two web service providers (WSP) with profile names other than wsp, an error occurs.

Workaround. For JAX-WS/web application based web services, use the static point end as the WSP name to support multiple web services. For EJB based web services, use the default WSP configuration.

Access Manager SDK (AMSDK) Issues

4139: With OpenSSO configured with AMSDK plug-in, session service assigned to a new role has conflict resolution level attribute issue

With OpenSSO Enterprise configured with the Access Manager SDK (AMSDK) plug-in, the session service assigned to a new role has a conflict resolution level attribute issue. Changing the conflict resolution level doesn't take effect on a user assigned with the role.

Workaround: Replace the cospriority attribute using a utility such as ldapmodify. For example:

ldapmodify -p 50389 -h dshost -D"cn=directory manager" -w dmpassword -c -f /tmp/mod

where /tmp/mod is:

dn:cn="cn=sfo1,dc=opensso,dc=java,dc=net",
cn=iPlanetAMSessionService,dc=opensso,dc=java,dc=net
changetype:modify
replace:cospriority
cospriority:4 

Upgrade, Compatibility, and Coexistence Issues

5801: During upgrade, updateschema.sh fails while executing ssoadm in a site configuration

If you are upgrading from OpenSSO Enterprise 8.0 to an OpenSSO 8.0 Update 1 patch release and OpenSSO Enterprise 8.0 has been configured as a site with a load balancer, the updateschema.sh script fails while executing the ssoadm utility.

Workaround. Before you run the updateschema.sh or updateschema.bat script:

  1. Install the ssoadm utility from the OpenSSO Enterprise Update 1 patch release.

  2. After you install the ssoadm utility, edit the ssoadm or ssoadm.bat utility by adding the following property to the java command:

    -D"com.iplanet.am.naming.map.site.to.server=
    http://loadbalancer.example.com:8080/opensso=http://sso1.example.com:8080/opensso"

    where loadbalancer is the load balancer for the OpenSSO Enterprise site, and sso1 is the OpenSSO Enterprise server where ssoadm or ssoadm.bat is installed.

For more information, see Chapter 3, Installing the OpenSSO Enterprise 8.0 Update 1 Admin Tools, in Sun OpenSSO Enterprise 8.0 Update 1 Release Notes.

4108: Incorrect encryption key used after configuring OpenSSO Enterprise against existing schema (DIT)

After configuring OpenSSO Enterprise against an existing schema (DIT) , you cannot log in to the console, because the encryption key entered during the configuration (the one from the old Access Manager or Federation Manager instance) is not used. Instead, a new incorrect encryption key is generated, which creates an incorrect serverconfig.xml file.

Workaround.

  1. Change to OpenSSO Enterprise config directory.

  2. Change the encryption key in the AMConfig.properties file with the correct value.

  3. Copy the backup copy of serverconfig.xml from the previous Access Manager or Federation Manager instance.

  4. Restart OpenSSO Enterprise server.

3962: Incorrect Console URL returned after authentication for non-admin user

If OpenSSO is configured with an Access Manager 7.1 Directory Server schema (DIT) in coexistence mode and a non-admin user logs in to the OpenSSO Console, the user is taken to an invalid URL. For example:

http://ssohost.example.com:8080/amserver/..amserver/base/AMAdminFrame.

Workaround. Edit the URL as follows:

protocol://host.domain:port/deploy_uri/idm/EndUser

For example:

http://ssohost.example.com:8080/amserver/idm/EndUser

3961: amadmin cannot log in to OpenSSO Console in coexistence mode

If OpenSSO is configured with an Access Manager 7.1 Directory Server schema (DIT) in coexistence mode, an attempt to log in as amadmin to the Console using LDAP authentication fails.

Workaround. To log in as amadmin to the OpenSSO Console in coexistence mode, add the module=DataStore query parameter. For example:

protocol://host.domain:port/deploy_uri/UI/Login/?module=DataStore

For example:

http://ssohost.example.com:8080/amserver/UI/Login/?module=DataStore

2348: Document Distributed Authentication UI server support

The OpenSSO Enterprise Distributed Authentication UI server component works only with OpenSSO Enterprise. The following scenarios are not supported:

830: ID-FF schema metadata is not backward compatible

If you are upgrading from a previous release of Access Manager or Federation Manager to OpenSSO Enterprise 8.0, ID-FF profiles do not work unless you also upgrade the Access Manager or Federation Manager schema.

Workaround. Before you try the ID-FF profiles, upgrade the Access Manager or Federation Manager schema. For more information about upgrading the schema, see the Sun OpenSSO Enterprise 8.0 Upgrade Guide.

Policy Agents Issues

3581: Policy evaluation with DNS condition fails for version 3.0 policy agents

For the version 3.0 policy agent for Sun Java System Application Server or GlassFish Application Server, policy evaluation with a DNS condition fails, because by default, the ServletRequest.getRemoteHost method returns an IP address instead of a host name.

Workaround. Change the default behavior by setting the following property in the Application Server or GlassFish domain.xml file:

dns-lookup-enabled="true"

Or, if you prefer, set this property in the Application Server or GlassFish Admin console.

Internationalization Issues

4090: Non-English entitlements are garbled

Workaround: To view the localized entitlements, which are provided in .txt format, use a browser with the encoding specified for each locale in the browser as follows:

4051: Multi-byte trusted partner name is garbled in Console

In the OpenSSO Console, if you go to Federation > SAML1.x Configuration, and then create a new Trusted Partner with a multi-byte Name in the Common Settings section, the trusted partner name is garbled.

3993: End user page shows question marks for CCK and JA locales

On the Geronimo web container in CCK and JA locales, if you log in as a user other than amadmin, the Access Control, realm, General, EndUser page (http://host:port/deployuri/idm/EndUser) shows question marks.

3976: Online Help “Tips on Searching” shows 404 error in non-English locale

If you log in to the OpenSSO Console in a non-English locale such as French, click Help, and then “Tips on Searching”, the right Help panel shows a 404 error.

Workaround. To view “Tips on Searching” in English, set the browser language to English and then refresh the online Help window

3766: encode.jsp and ampassword -e differ with multi-byte (non-ASCII) characters

If a password file contain multi-byte (non-ASCII) characters, the ampassword utility does not return the correct encrypted value. However, encode.jsp does return the correct value.

Workaround. If you are using ampassword, use a password file that contain only ASCII characters. If the password contains multi-byte characters, use encode.jsp to encrypt the password:

  1. Log in to the OpenSSO Admin Console as amadmin.

  2. Specify the following URL: http://host.example.com:58080/deploy-uri/encode.jsp

  3. When you are prompted, enter the password and click Encode.

  4. Copy the encrypted password.

3763: Some non-ASCII characters are garbled when the web container is in C locale

If you start the web container in the C locale and set your browser to a language such as French, after you log in to the Admin Console, some characters are garbled.

3713: Password reset page is not localized for CCJK locales

For CCJK locales, the password reset page (http://host:port/deployuri/password) is not localized.

3590: Change location for dounix_msgs.po files

The dounix_msgs.po files for the Unix authentication module have not been translated because the Unix authentication module will not be included in a future OpenSSO Enterprise release. See Deprecation Notifications and Announcements.

1793: Authentication fails with multi-byte character for org or module in query parameter

If you try to log in to the OpenSSO Console using the org or module parameter with characters that are not UTF-8, the login fails. For example: http://host:port/deployuri/UI/Login?module=Japanese-string&gx_charset=UTF-8

Workaround. Use UTF-8 URLencoding characters such as %E3%81%A6 instead of native characters.

Localization Issues

4017: In Spanish locale, “2.2 Agents” is translated only as Agentes in Console

If the OpenSSO Console is in the Spanish locale, the 2.2 is missing from the translation of “2.2 Agents”.

3994: In Spanish locale, cannot access Certificate for Configuration > Authentication

If the OpenSSO Console is in the Spanish locale, clicking Configuration, Authentication, and then Certificate returns an error.

3971: In Chinese (zh_CN) locale, online help is in English

In the Chinese (zh_CN) locale. the Console online help text is displayed in English rather than Chinese. If you set your browser preferred language to zh_CN, only the online help text in the left tree will be English. If you set your browser preferred language to zh, all online help text will be English.

Workaround. Copy the zh_CN online Help contents to a new zh directory in the web container's webapps directory and the restart the web container.

For example for Apache Tomcat, copy /Tomcat6.0.18/webapps/opensso/html/zh_CN/* to a new directory named /Tomcat6.0.18/webapps/opensso/html/zh/. And then restart the Tomcat container.

3802: Problems in the French part of copyright notice

In the French part of the English copyright notice, “Etats-unis” is missing an accent, a space is missing after the comma at “armes nucléaires,des missiles”, and spaces should not be in “Etats - Unis”.