Workarounds: Jazz Team Server problems in Collaborative Lifecycle Management 4.0.5

Build basis: Collaborative Lifecycle Management 4.0.5

Workaround summary

When Collaborative Lifecycle Management is used in a distributed environment, the OAuth window refuses log in and returns an HTTP status 403 error because the user ID does not have the correct roles.

More information

Problem

The Jazz Team Server must complete a user synchronization with remote applications. If you try to authorize an application with a user ID that is not synchronized yet, the HTTP status 403 error is shown.

Workaround

Log out of the application, wait a few minutes to let any pending user synchronization complete, and then try reauthenticating. If the problem persists, contact your server administrator to check the log file of the remote application to see if the user synchronization occurred.

Workaround summary

When Collaborative Lifecycle Management is used in a distributed environment, the OAuth window refuses log in and returns an HTTP status 403 error when the user ID has the correct roles assigned, because the Jazz Team Server identifies the request as a cross-site request forgery (CSRF) attack.

More information

Problem

When single sign-on (SSO) is not configured for two Jazz-based servers, and an operation in the web client that requires server-to-server communication is performed, such as viewing a remote viewlet on a dashboard or link to projects, an OAuth window opens to authenticate the remote server.

If valid SSL certificates are not installed on the servers, browsers warn you before showing pages, including those in the OAuth windows. In Microsoft Internet Explorer 10, if you click to see the warning content, you can click Yes to allow collaboration between the servers, which results in another security warning. If you click to see the content for this second warning, instead of the window closing as expected, the window shows an HTTP status 403 error and a message that permission was denied because the request might have been forged by a malicious web site.

Workaround

To resolve this issue, install valid SSL certificates on the servers. Self-signed certificates can be used. This certificate must have a valid host name (not local host) because the servers are communicating across host name boundaries. For more information on this process, see Installing a security certificate.

Related information

• Jazz Foundation Work Item 285627

Workaround summary

The Eclipse client uses ISO-8859-1 as the default character encoding for basic authentication credentials. This setting can be reconfigured when the character encoding is inappropriate for a remote server.

More information

Problem

The default character encoding for basic authentication varies between server implementations, which might affect how the server handles non US-ASCII characters. The Eclipse client uses the common ISO-8859-1 as the default character encoding; however, this might cause a basic authentication failure if a server is expecting a different character encoding.

Workaround

To get the Eclipse client to authenticate with a server using basic authentication and an unexpected character encoding, open the eclipse.ini file of the Eclipse client and edit it. Inside the file, under -vmargs, add the following string:

-Dcom.ibm.team.repository.transport.client.basic.auth.credential.charset=[CHARACTER ENCODING]

Substitute [CHARACTER ENCODING] with the proper encoding. Common encodings are ISO-8859-1, US-ASCII, UTF-8, and Cp1252.

Related information

• Jazz Foundation Work Item 280217