OpenSSO 8.0 Update 2 Patch 2

OpenSSO 8.0 Update 2 patch 2 is available as patch ID 141655-06 on the My Oracle Support site. Other information about this patch includes:

• What's New in OpenSSO 8.0 Update 2 Patch 2

• Known Issues in OpenSSO 8.0 Update 2 Patch 2

• Documentation Updates in OpenSSO 8.0 Update 2 Patch 2

What's New in OpenSSO 8.0 Update 2 Patch 2

• CR 7016248: Validation of gotoOnFail URLs

• CR 6993122: SAMLv2 implementation of NameIDPolicy interface without SPNameQualifier

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

CR 7016248: Validation of gotoOnFail URLs

OpenSSO 8.0 Update 2 Patch 2 can validate a gotoOnFail URL after a user fails authentication. This validation prevents a hacker from sending the user to an imposter site.

To set valid gotoOnFail URLs, follow these steps after you install patch 2:

1. If you patched an earlier version of OpenSSO 8.0, make sure you have run the updateschmema.sh or updateschema.bat script and then restarted the OpenSSO web container, as described in Running the updateschema Script.

2. In the OpenSSO Administration Console, click Access Control, realm-name, Authentication, and then Advanced Properties.

3. Under Valid gotoOnFail URL domains, add each valid goto domain name, as follows:

   • A domain name starting with a dot (.) such as .example.com allows all hosts in the example.com domain to be used in a failure redirect URL.

   • A domain name that does not start with a dot (.) such as example.com allows the host example.com to be used in a failure redirect URL.

     For example, http://example.com would be valid, but http://host.example.com would not be valid.

   • If you don't add the entire domain to the list, you must add each individual agent host name being used.

   • You do not need to add domains for agents in CDSSO mode, because they are protected automatically.

4. Click Save.

5. Log out of the console and restart the OpenSSO web container.

Additional Information

• If a gotoOnFail URL is found to be invalid, the user is redirected to the default login failure URL.

• If you subsequently want to disable the gotoOnFail URL validation, remove all entries from the Valid goto URL domains list.

CR 6993122: SAMLv2 implementation of NameIDPolicy interface without SPNameQualifier

OpenSSO 8.0 Update 2 Patch 2 provides an implementation of the NameIDPolicy interface without the SPNameQualifier attribute.

The SPNameQualifier attribute in the NameIDPolicy interface is optional in a SAMLv2 authentication request. In some instances, a service provider (SP) initiated SSO can fail because an identity provider (IDP) cannot recognize the SPNameQualifier attribute in NameIDPolicy of the authentication request.

This implementation is available in the following new class:

com.sun.identity.saml2.protocol.impl.NameIDPolicyImplWithoutSPNameQualifier

The default behavior (that is, to put the SPNameQualifier attribute in NameIDPolicy of the authentication request) does not change.

To use the new class, follow these steps:

1. In the OpenSSO Administration Console, click Configuration, Servers and Sites, server-name, and then Advanced.

2. Add the following new property and value:

   • Property: com.sun.identity.saml2.sdk.mapping.NameIDPolicy

   • Value: com.sun.identity.saml2.protocol.impl.NameIDPolicyImplWithoutSPNameQualifier

3. Click Save.

4. Logo out of the console and restart the OpenSSO server web container.

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

OpenSSO 8.0 Update 2 Patch 2 allows you to access the HttpServletRequest object and modify the HttpServletResponse object through a custom authentication module for OpenSSO server deployments with the Distributed Authentication User Interface (DAUI), as well as for OpenSSO 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 OpenSSO server deployments without the DAUI.)

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

• HttpRequestCallback: equivalent to the container HttpServletRequest object

• HttpResponseCallback: equivalent to the container HttpServletResponse object

For more information, see the OpenSSO Enterprise 8.0 Developer's Guide.

Known Issues in OpenSSO 8.0 Update 2 Patch 2

CR 7017520: Missing property in Policy Service causes HTTP status code 500

For OpenSSO 8.0 Update 2 Patch 1 and later releases, the Policy Service sometimes returns HTTP status code 500. This problem is caused by a missing app_sso_token_invalid key in the amPolicy.properties file.

Workaround:

1. In the OpenSSO-Deploy-base/WEB-INF/classes/amPolicy.properties file, add the following line:

   app_sso_token_invalid=Application sso token is invalid

   OpenSSO-Deploy-base represents the path where the web container deploys the opensso.war file.

2. Restart the OpenSSO web container.

Documentation Updates in OpenSSO 8.0 Update 2 Patch 2

• CR 7013849: Documentation update: WS-Trust certificate must be the same on client and server

• CR 7007193: Documentation update: REST Get method parameter passing is changed in OpenSSO 8.0 Update 2

CR 7013849: Documentation update: WS-Trust certificate must be the same on client and server

The Oracle OpenSSO STS Administrator's Guide requires additional information about the Private Key Alias in Chapter 4, Managing the Security Token Service:

http://download.oracle.com/docs/cd/E17842_01/doc.1111/e17844/tokenservice.htm

Private Key Alias

Behind the Private Key Alias, a real certificate exists in the client's keystore. The value of this certificate depends on the OpenSSO server configuration. For authentication between a web services client (WSC) and a web services provider (WSP) such as OpenSSO server to function properly, the certificates on the client and OpenSSO server must match.

On the client side, you must import the certificate from OpenSSO server into the client's certificate store database. This imported certificate can be under a different name than OpenSSO server, but the client and OpenSSO server must use the same certificate to communicate properly.

For more information about web services security, see the OpenSSO Enterprise 8.0 Administration Reference:

http://download.oracle.com/docs/cd/E19681-01/820-3886/index.html

CR 7007193: Documentation update: REST Get method parameter passing is changed in OpenSSO 8.0 Update 2

OpenSSO 8.0 Update 2 and later releases do not allow sensitive information such as a password in URLs using the REST identity interface. This change (CR 6940612) prevents sensitive information from appearing in browser history files and web server or proxy log files.

If you are using the REST identity interface, a URL that contains sensitive information such as a password returns an unsupported operation exception. For example, the follow URL contains the user's password and would return an exception:

https://opensso.example.com:80/opensso/identity/authenticate?username=user&password=user-password

In the OpenSSO Enterprise 8.0 Developer's Guide, Chapter 10, Using the REST Identity Interfaces, states that “the REST authenticate interface works with simple user name and password only.” However, in OpenSSO 8.0 Update 2 and later releases, sensitive information such as the password is not allowed in the URL and returns an exception.

Therefore, if you are using the REST identity interface with OpenSSO 8.0 Update 2 and later releases, use a POST operation to send the authentication data to OpenSSO server. POST data is usually not logged or stored as part of the browser history.