Getting Started With OpenSSO Express Build 7If you have not previously installed OpenSSO Enterprise, here are the basic steps to follow:
Hardware and Software Requirements For OpenSSO Express Build 7OpenSSO Express Build 7 supports all web containers supported in Sun OpenSSO Enterprise 8.0. Additionally, the following web containers are now supported: in Express Build 7:
All other hardware and software requirements are identical to the hardware and software requirements documented in the Sun OpenSSO Enterprise 8 Release Notes. OpenSSO Enterprise 8.0 DocumentationThe OpenSSO Enterprise 8.0 documentation is available on the following site: OpenSSO Enterprise 8.0 Documentation Center Check this site periodically to view the most recent documentation. What's New in OpenSSO Express Build 7OpenSSO Express Build 7 includes features such as access management, federation management, and web services security that are found in earlier releases of Sun OpenSSO. OpenSSO Enterprise also includes the new features described in this section. Using OpenDS as a User Data StoreYou can use OpenDS to store user profiles, authentication data, and policies. For more information see Using OpenDS as a User Data Store. Integrating Google Apps with OpenSSOIf you have a Premier Edition Google Apps account, you can enable access to Google web applications such as Gmail, Google Calendar, Google Docs, and Google Video, to name just a few, to users in your enterpise domain. For more information, see Integrating Google Apps with OpenSSO. Simplified OpenSSO WAR File CreationThe ability to create a specialized WAR file was present in OpenSSO Enterprise 8.0. In OpenSSO Express Build 7,the process has been simplified using the createwar.sh/createwar.bat script. For more information, see Creating a Specialized OpenSSO WAR. Enabling XML Signing and Encprytion in a FedletSee Enabling XML Signing and Encryption in a Fedlet. Using the Centralized SAML2 Error Conditions PageOpenSSO Express Build 7 provides a single page where you can view all SAML2 error conditions. This is useful when you are troubleshooting SAML2 configuration. For more information, see Centralized SAMLv2 Error Processing. About SAE Data Encryption SupportOpenSSO Express Build 7 supports Secure Attributes Exchange (SAE) data encryption. SAE is also known as Virtual Federation. For more information, see Encrypting Data in a Secure Attribute Exchange. Support for New Web Container VersionsOpenSSO Express Build 7 supports all web containers supported in OpenSSO Enterprise 8.0. Additionally, the following web containers are also supported:
New Policy Agent FeaturesFor the new features in version 3.0 policy agents, see one of these guides:
Enchancements to OpenSSO 8.0 Functionality
4112: New property prevents unnecessary service polling requests from policy agentsThe new com.iplanet.am.client.appssotoken.refreshtime property prevents policy agents in polling mode from sending unnecessary session service requests to the OpenSSO server. The default value is 3 minutes. Previously, these session service requests could cause unnecessary traffic between the agent and the OpenSSO server as well as create an extra load on OpenSSO server. 4322: New script simplifies creation of OpenSSO specialized WAR filesThe new createwar script simplifies the creation of specialized OpenSSO WAR files, including a Console only WAR, Distributed Authentication server UI WAR, OpenSSO server only WAR, and an IDP Discovery WAR. For more information, see Creating a Specialized OpenSSO WAR. 2680: exportmetadata.jsp supports signing of exported metadataexportmetadata.jsp, the JavaServer Page used for exporting SAMLv2 metadata, now supports signing of the exported metadata. 3468: Fedlet supports XML signing and decryption of encrypted elementsThe OpenSSO Fedlet now supports XML signing and decryption of encrypted Assertion, NameID, and Attribute elements. 3749: SP entity identifier (SPEntityID) is available to all authentication modules on IDPA service provider's (SP) entity identifier (SPEntityID) is now readily available to all authentication modules on the identity provider (IDP) side, allowing the identity provider to take specific action depending on the service provider's requesting authentication. 4572: Centralized page shows all SAML2 error conditionsSee Centralized SAMLv2 Error Processing 4574: SAE API can encrypt data being passed through the gatewayThe Secure Attribute Exchange API can now be used to encrypt the data being passed through the gateway. See Encrypting Data in a Secure Attribute Exchange 4087: CRL and OSCP checking support JSS-based logicCertificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP) checking now support the Network Security Services for Java (JSS) library, enabling FIPS mode on the web container Sun Java Web Server 7.0 release update 3 or later. 4251: Redirect callback support is added for Distributed Authentication Server UIRedirect callback support (RedirectCallback), which is used to redirect users to an external website as part of the authentication process, now works when the login is through a Distributed Authentication Server UI. 4371: CDCServlet removes the JavaScript enabled dependency for user's browserIf cross-domain single sign-on (CDSSO) is enabled for a policy agent, the CDCServlet can now redirect assertions (CDCRedirectServlet) for the agent, even if JavaScript is disabled for the user's browser. 3913: Policy agents send token other than the IP address in cookie hijacking modePreviously, in cookie hijacking mode, policy agents sent the IP address of the server where they were installed to the OpenSSO server. Now, the policy agent first sends the application SSO token. If the agent cannot obtain the application SSO token, the agent then sends the IP address to the OpenSSO server. If strict DN checking is required for a deployment, OpenSSO server includes the new The default value is false. If this property is set to true, the OpenSSO server performs strict DN checking. If the agent sends an IP address, the OpenSSO server considers the IP address to be an error. To set iplanet-am-session-dnrestrictiononly for strict DN checking:
4247: New property allows policy agent sessions to time outThe new com.iplanet.am.session.agentsessionidletime property sets the maximum idle timeout in minutes for policy agent sessions. The minimum value is 30 minutes. A value greater than 0 and less than 30 will be reset to 30. To set com.iplanet.am.session.agentsessionidletime:
4008: New authentication module added for WSS user name token password digestOpenSSO Epress Build 7 includes a new authentication module for the UserNameToken profile. This new module enables authentication between a web services client (WSC) and a web services provider (WSP), and handles both UserNameToken password digest and UserNameToken-Plain text password tokens. After you configure web services security (WSS) in the OpenSSO Admin Console, create an authentication chain as wssauthchain with the required authentication module as WSSAuthModule. 4394: Web services provider (WSP) caches user token nonceA WSP now caches the user token nonce to prevent replay attacks for validating the name token profiles. The WSP uses the in-memory cache that stores the cache indexed by the timestamp. The WSP also includes an interface for the persistent store of the state of the cache for failover situation. 4192: Policy Agent configuration key and value pair information now displayed together on one pageIn the OpenSSO administration console, go to Realms > Agents > Edit Agent, and then click Dump. A new page opens with configuration key and value pair information displayed. 4286: After upgrading from JES4, in co-existence mode, amadmin authenticates to configuration data storeA security fix (Issue 3924) prevents amadmin from logging in to any authentication module other than the DataStore and Application authentication modules. Known Issues Fixed in This ReleaseThe following were identified in OpenSSO Enterprise 8.0 as known issues. These issues are resolved in OpenSSO Express Build 7. Web Container and Server Issues
Data Store Issues
Authentication Issues
Session Issues
Command-Line Utilities Issues
Client SDK Issues
Federation and SAML Issues
Web Services Security (WSS) IssuesUpgrade, Compatibility, and Coexistence Issues
Policy Agents IssueInternationalization Issues
Localization Issues
Known Issues in This Release
6827245: Error message is displayed after SAML2 single sign-onAfter performing SAML2 single sign-on, you may see this error message displayed: ERROR: Can't get property: SAML2IDPSessionIndex This may occur at the Identity Provider when the user session idle time expires after performing single sign-on. Although this message displays as designed, the error condition does not cause any actual problem in your deployment. You can disregard this message. 4805: WindowsDesktopSSO authentication module does not work on IBM WebSphere Application ServerThe IBM JDK uses a different Kerberos module name, causing the WindowsDesktopSSO authentication module to fail. To remedy this problem:
4844: Fedlet single sign-on fails using IBM WebSphere Application Server 7.0The OpenSSO Fedlet may fail if deployed on IBM WebSphere 7.0. As a workaround, add the following JARs to the fedlet WEB-INF/lib directory:
You can obtain the JARs from the OpenSSO website https://opensso.dev.java.net/public/use/index.html#source. Download and extract opensso-sun-extlib.zip. 4727: Session backup performance degradesThe problem occurs when the Message Queue broker list in amsfo.conf is not identical to the Message Queue broker list in the session failover configuration. To view the session failover configuration, in the OpenSSO administration console, go to Configuration > Global > Session> Secondary Configuration Instance > Database URL. For example, if the Database URL entry is Be sure that the hosts are listed in the same order. In this example, the Database URL and the CLUSTER_LIST property should be set at 4727 : Using two Session Failover configurations can lead to performance problemsA typical deployment of Session Failover component consists of two dedicated machines, each hosting a Message Queue and a Berkeley database for storing user sessions. Each user session will be replicated to the Berkley databases. This dual-host setup is for redundancy reasons and not for load-sharing. Each additional Session Failover component host offers a gain in additional data redundancy, but no gain in processing capacity. In fact, the extra data replication overhead reduces the overall Session Failover component processing capacity. Due to a limitation in the Message Queue implementation, a dual-host deployment can support a substantially lower maximum throughput than a single-host Session Failover deployment. This is due to Message Queue-to-Message Queue communication overhead. When OpenSSO generates requests faster than Session Failover component can process, messages overflow and are rejected by the Session Failover component. This leads to stale and missing sessions stored in the Session Failover component. If the expected load is high, the best practice is to configure one of the following:
The advantage of the having two Session Failover component hosts in active-standby mode is that if the first host goes out of service, there is always a second host ready to replace it. Using a single Session Failover component host, having out-of-service hardware could result in the system running in a non-Session Failover mode for a long time. The impact of both workarounds is that if the only active Session Failover component stops or fails, then the stored sessions are lost until future user activities trigger new session updates. If an OpenSSO server also stops or fails during this period of time before sessions are fully restored, user sessions on that OpenSSO server cannot be restored from the Session Failover component. Users will be re-authenticated. For these reasons, do not to restart OpenSSO servers immediately after a Session Failover component restart or failover. Deprecation Notifications and Announcements
How to Report Problems and Provide FeedbackIf you have questions or issues with OpenSSO Enterprise, contact Sun Support Resources (SunSolve) at http://sunsolve.sun.com/. This site has links to the Knowledge Base, Online Support Center, and Product Tracker, as well as to maintenance programs and support contact numbers. If you are requesting help for a problem, please include the following information:
Additional Sun ResourcesYou can find additional useful information and resources at the following locations:
|
In This Article
|

