Tip: Changes to OAuth Authorization in RTC 3.0.1

Description of Changes

To increase security and reduce the chances that a malacious application could steal the credentials of a CLM logged-in user, the OAuth 1.0 protocol in CLM 3.0.1 was enhanced to add an extra level of trust checking when authorizing login from one CLM application to another.  If for any reason an application (“Application A”) requesting access to the protected resources of another (“Application B”) is not recognized as a registered application by the target application, the end-user is shown a dialog requesting confirmation that she will allow “Application A” to access “Application B”‘s protected resources.  The end-user then has the opportunity to deny access if she does not recognize the authority of the requesting application.

Note: This technote applies to both RTC 3.0.1 and RTC 2.0.0.2 iFix7

Technical Overview

A CLM application requests access to the protected resource of another application on behalf of the logged-in user via the OAuth 1.0 protocol. Typically each CLM application is registered as a “trusted” OAuth consumer of all other CLM applications, which means that once logged-in, the requesting application is automatically granted authorization to access the protected resources of the “trusted” application without an intervening dialog requesting authorization (perhaps “trusting” might be a more accurate description).  The minimizing of these authorization dialogs between trusted applications allows OAuth 1.0 to behave similar to a single-signon protocol, improving the user experience when traversing  CLM applications.  By way of contrast, a registered application not marked as “trusted” will always ask the logged-in user if she authorizes applications to access the protected resources of the target application.  Authorization is always requested, but the user-experience when traversing multiple applications in the same authentication realm can degrade.

In 3.0.1, the definition of a “trusted” consumer was further strengthened to require that the requesting application’s URI namespace be recognized by the target application.  If the requesting namespace is not recognized, that application is considered untrusted, regardless if it was registered as trusted, and so an approval dialog is always shown.

Intervention

There can be some cases where a registered, valid and trusted application’s request for authorization won’t be recognized as trusted, and thus more authorization dialogs are shown than what is expected or desired.  For example, if the requesting application is requesting authorization from a URI namespace that is different that what is registered as its public URI or its rootservices documentation.  The evidence for this case can be found in the target application’s server logs, with messages similar to this one:

 WARNING CRJAZ2115W The consumer application named "Application B"
 has been registered as "trusted", that is, for this consumer
 application it is not necessary to present to the user an
 authorization dialog requesting that user''s permission to allow the
 application to access this server.  However, the callback URL
 "https://hostname:9443/appA/callback" that was specified for request
 token authorization cannot be determined by this server to originate
 from any trusted consumer or application.  So for this
 authorization cycle, this consumer is not considered trusted and an
 authorization dialog will be issued. If you (the administrator) wish
 to assert that this callback is trusted, enter the callbackURL into
 the "Application B" server configuration page section for trusted
 URIs, per the directions for that field.
 

If you find such a message, and you determine that the requesting application’s callback is trustworthy, you can override this behavior by specifying the listed application callback as a value of the “Trusted client authorization URIs” field on the “Advanced Properties” page of the “Server Administration” Web UI for Application B as shown below:

---

A server restart is not required after modifying and saving the value.