CR 6959610: OpenSSO 8.0 Update 2 samples should be removed in production environment
CRs 6944573, 6964648: New Java security permissions are required for WebLogic Server 10.3.3
CR 6967026: Configurator cannot connect to LDAPS-enabled directory server
CR 6956461:SecurID authentication fails on IBM WebSphere Application Server
CR 6959373: Web container requires a restart after running updateschema script
CR 6961419: Running updateschema.bat script requires a password file
CR 6972593: Java Oracle OpenSSO Fedlet single sign-on (SSO) fails on JBoss AS 5.0.x
SR 72335286 and CR 6929674: LDAP Referrals Do Not Work as Expected
General security concerns exist regarding using a HTTP Basic Authentication module. See http://en.wikipedia.org/wiki/Basic_access_authentication, the “Disadvantages” section. Be sure that you can address these security concerns before you consider using HTTP Basic Authentication in a production deployment.
To minimize random or unnecessary configuration changes through inadvertent sample program runs, remove the samples before you deploy OpenSSO 8.0 Update 2 in a production environment.
If you are deploying OpenSSO 8.0 Update 2 on Oracle WebLogic Server 10.3.3 with the security manager enabled, an additional Java security permission is required.
Workaround. Add the following permission to the WebLogic Server 10.3.3 weblogic.policy file:
permission java.lang.RuntimePermission "getClassLoader";
Due to an issue in earlier versions of Oracle WebLogic Server such as 10.3.0 and 10.3.1, certificate authentication with either LDAP checking or OSCP checking enabled fails.
Workaround. This problem has been fixed in WebLogic Server 10.3.3. To use certificate authentication with either LDAP checking or OSCP checking, use OpenSSO Update 2 with WebLogic Server 10.3.3.
In the Spanish version of OpenSSO 8.0 Update 2, you cannot access authentication certificates. When you go to Configuration > Authentication > Certificates, an error occurs. The following is displayed in the log "Caused by: java.lang.IllegalArgumentException."
Workaround. None.
Download the ojdbc6.jar file from the following URL:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html.
Create a staging area and change to that directory. For example:
mkdir /tmp/staging cd /tmp/staging |
Explode the opensso.war in the staging area.
jar xf opensso.war |
Change to the WEB-INF/lib directory.
Copy ojdbc6.jar into that directory. For example:
cp OJDBC6_DOWNLOAD_LOCATION/ojdbc6.jar |
Create an updated opensso.war file from the staging area. For example:
cd ../.. jar cf /tmp/opensso.war * |
Undeploy the current opensso.war.
Deploy the opensso.war file you created in Step 6.
Restart the OpenSSO web container instance.
By default, the OpenSSO configurator supports only the JCE/JSSE provider for SSL. However, you can use the OpenSSO administration console to manually enable JSS/NSS. If OpenSSO is deployed on Sun Web Server 7.0 or on GlassFish Enterprise Edition 2.1.0, then complete the following steps. For GlassFish Enterprise Edition 2.1.1 and later versions, see CR 6967026: Configurator cannot connect to LDAPS-enabled directory server.
If you want OpenSSO to connect to an LDAPS-enabled directory server, then the CA certificate for the LDAPS-enabled directory server must be already imported into the JVM trust store (by default JAVA_HOME/jre/lib/security/cacert).
Log in to the OpenSSO Administration Console as amadmin.
Click Configuration > Servers and Sites > Server Name instance.
Click Security.
Click Inheritance Settings.
Uncheck the Encryption class and Secure Random Factory Class properties.
Click Save, and then click Back to Server Profile.
Change Encryption class to com.iplanet.services.util.JSSEncryption.
Change Secure Random Factory Class to com.iplanet.am.util.JSSSecureRandomFactoryImpl.
Click Save, and then click the Advanced tab.
Change the com.iplanet.security.SSLSocketFactoryImpl property to com.iplanet.services.ldap.JSSSocketFactory.
Edit the following property and value:
Property Name: opensso.protocol.handler.pkgs
Property Value: com.iplanet.services.comm
Click Add, and add following property and value:
Property Name: com.iplanet.am.admin.cli.certdb.dir
Property Value: path-to-NSS-database
Click Save.
Restart the OpenSSO Enterprise 8.0 server instance.
If OpenSSO is deployed on GlassFish Enterprise Server 2.1.1 or later versions, then OpenSSO cannot connect to an LDAPS-enabled directory server instance with JSS/NSS. The problem occurs because OpenSSO and GlassFish Enterprise Server 2.1.1 and later versions do not use the same JSS version.
Workaround: Use the JSSE provider instead of the NSS provider for SSL.
If you deploy OpenSSO 8.0 Update 2 (opensso.war) in the WebLogic Server 10.3.3 administration console and click Start to allow OpenSSO 8.0 Update 2 to start receiving requests, exceptions are thrown in the console where the WebLogic Server domain was started.
Note: After you start OpenSSO 8.0 Update 2, it remains started and exceptions are not thrown again until OpenSSO 8.0 Update 2 is stopped and then restarted.
Workaround. Copy the saaj-impl.jar file from the OpenSSO 8 Update 2 opensso-client-jdk15.war file to the WebLogic Server 10.3.3 configuration endorsed directory, as follows:
Stop the Oracle WebLogic Server 10.3.3 domain.
If necessary, unzip the OpenSSO 8.0 Update 2 opensso.zip file.
Create a temporary directory and unzip the zip-root/opensso/samples/opensso-client.zip file in that directory, where zip-root is where you unzipped the opensso.zip file. For example:
cd zip-root/opensso/samples mkdir ziptmp cd ziptmp unzip ../opensso-client.zip
Create a temporary directory and extract the saaj-impl.jar file from opensso-client-jdk15.war. For example:
cd zip-root/opensso/samples/ziptmp/war mkdir wartmp cd wartmp jar xvf ../opensso-client-jdk15.war WEB-INF/lib/saaj-impl.jar
Create a new directory named endorsed under the WEBLOGIC_JAVA_HOME/jre/lib directory (if endorsed does not already exist), where WEBLOGIC_JAVA_HOME is the JDK that WebLogic Server is configured to use.
Copy the saaj-impl.jar file to the WEBLOGIC_JAVA_HOME/jre/lib/endorsed directory.
Start the WebLogic Server domain.
When OpenSSO is configured on IBM WebSphere Application Server 6.1 or AIX 5.3, a valid plain text password user can not be authenticated via a SecurID authentication module instance.
Workaround. None. Do not use plain text passwords on IBM WebSphere Application Server.
After you run the updateschema.sh or updateschema.bat script, you must restart the OpenSSO 8.0 Update 2 web container.
The updateschema.bat script executes several ssoadm commands. Therefore, before you run updateschema.bat on Windows systems, create a password file that contains the password user in clear text for the amadmin user. The updateschema.bat script prompts you for the path to the password file. Before the script terminates, it removes the password file.
When using OpenSSO Update 2 on the following browsers, the browser scroll does not work as designed: Microsoft Internet Explorer 7 and 8 on Windows 2003 or 2008.
Workaround. Maximize the browser window.
JBoss 5.x uses Tomcat 6.0.16 which does not support the special symbols in the OpenSSO iPlanetDirectoryPro cookie. This affects OpenSSO cookie-handling.
Workaround. See To Deploy OpenSSO on JBoss 5.0.
The minimum heap size should be set to at least 512M (-Xms256m), and maximum heap size should be set to 1024M (-Xmx1024m).
The MaxPermSize should be set to 256M (-XX:MaxPermSize=256m)
In the JBoss run.conf file (run.conf.bat on Windows), which is used to start up the JBoss instance, add the following JVM options:
-Dcom.iplanet.am.cookie.encode=true -Dcom.iplanet.am.cookie.c66Encode=true
If you do not set these properties, after entering your credentials in the OpenSSO console, you are directed back to the login page. After you've deployed and configured OpenSSO you can remove this entry in the run.conf file (or run.conf.bat on Windows). OpenSSO configures the cookie encode property during deployment.
Unjar the opensso.war.
Create text-file opensso.war/WEB-INF/jboss-web.xml.
Enter the following content in the file:
<!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 5.0//EN" "http://www.jboss.org/j2ee/dtd/jboss-web_5_0.dtd"> <jboss-web> <class-loading java2ClassLoadingCompliance='true'> <loader-repository> jbia.loader:loader=opensso <loader-repository-config> java2ParentDelegaton=true </loader-repository-config> </loader-repository> </class-loading> <resource-ref> <res-ref-name>jdbc/openssousersdb</res-ref-name> <jndi-name>java:jdbc/openssousersdb</jndi-name> </resource-ref> </jboss-web>
Create the WAR again.
Stop the JBoss server.
Create a directory under the mode that opensso will be deployed to.
Example: JBOSS_INSTALL_DIR>/server/$CONFIG/deploy/opensso.war
where $CONFIG is the mode such as default, all, or production.
Go to the opensso.war directory.
Example: JBOSS_INSTALL_DIR/server/$CONFIG/deploy/opensso.war
Explode the war to this directory.
jar -xvf WAR_FILE_LOCATION/opensso.war
Restart the JBoss container.
Deployment of opensso.war will succeed without errors.
OpenSSO 8.0 U2 installation on JBoss 5.0.0 is supported in exploded war mode only.
If you deploy and configure the opensso.war file on JBoss Application Server 5.0.0.0 and then restart the JBoss Application Server web container, OpenSSO 8.0 Update 2 displays the configurator page again instead of the login page.
Workaround. Deploy the opensso.war file in the JBoss AS deploy directory, as follows:
Stop the JBoss Application Server web container.
Edit the JBoss Application Server run.conf file by adding the following options:
-Dcom.iplanet.am.cookie.encode=true -Dcom.iplanet.am.cookie.c66Encode=true
Uncomment the line "admin=admin" in the following files:
JBOSS_INSTALL_DIR/server/$CONFIG/conf/props/jmx-console-users.properties
JBOSS_INSTALL_DIR/server/$CONFIG/deploy/management/console-mgr.sar/web-console.war/WEB-INF/classes/web-console-users.properties
Copy the opensso.war file to the following JBoss Application Server directory:
JBOSS_INSTALL_DIR/server/$CONFIG/deploy
where $CONFIG is the JBoss Application Server mode, such as default, all, or production.
Restart the JBoss Application Server web container.
Deploy the opensso.war file in the directory shown in Step 4.
If you deploy the Java Oracle OpenSSO Fedlet on JBoss Application Server 5.0.x, index.jsp doesn't display and Fedlet SSO fails with an IllegalStateException.
Workaround. Follow these steps.
Stop the JBoss AS web container. JBoss AS web container.
Add the following Java options in the JBoss AS 5.0 run.conf file: -
Djavax.xml.soap.MetaFactory= com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl -Djavax.xml.soap.MessageFactory= com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl -Djavax.xml.soap.SOAPConnectionFactory= com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnectionFactory -Djavax.xml.soap.SOAPFactory= com.sun.xml.messaging.saaj.soap.ver1_1.SOAPFactory1_1Impl
Start the JBoss AS web container.
When LDAP referrals are enabled, authentication fails for the user in the referral directory server. Authentication fails regardless of how the option "LDAP Follows Referral" is set. Also, the Subjects tab in the OpenSSO administration console does not display referral users.
These issues are due in part because of a known issue with the LDAP SDK (CR 6969674). Using LDAP SDK, LDAP referrals are not honored in OpenSSO.
Workaround. There are no workarounds at this time.