IBM Tivoli Federated Identity Manager, Version 6.2.2

Security Token Service interface for two-legged OAuth flow

The Security Token Service interface processes requests differently for a two-legged OAuth flow.

This section provides the following information about the two-legged OAuth scenario:

The behavior of Tivoli® Federated Identity Manager Security Token Service.
The significance of the WebSphere® Trust Association Interceptor enforcement point.

When an OAuth client accesses a protected resource that uses two-legged OAuth, no OAuth token or authorizing resource owner is associated with the request. The OAuth client signs the request with its client credentials, proving that the request came from that client. This method is similar to a traditional basic authentication, except that the request is digitally signed rather than containing the client credentials in clear text.

The two-legged OAuth flow follows this process:

An OAuth enforcement point receives a two-legged OAuth request.
The enforcement point contacts the Security Token Service for validation.
The Security Token Service then processes the two-legged OAuth request sent from the enforcement point, and validates the request signature.
The Security Token Service returns a username response attribute as part of the validation response. This attribute is set to the value of the client identifier, which is also known as the client key.
Note: This method is different from a traditional three-legged OAuth flow, where the username attribute is set to the user name of the resource owner. The user is the same entity who authorized the access of the OAuth client to the protected resource.

The OAuth enforcement point can use the returned username response attribute for audit, authentication, or downstream protected resource application.

Tivoli Federated Identity Manager provides sample OAuth mapping rules that detect a two-legged OAuth scenario. When detected, the mapping rule changes the value of the returned username attribute from the client identifier to the predefined value me_guest.

You can modify the mapping rule to either leave the username attribute as the client identifier or map it to something else. This change becomes important only when your enforcement point or downstream protected resource application rely on the value of the returned username attribute for special processing.

The Trust Association Interceptor enforcement point requires and relies on the value of the returned username attribute. The enforcement point performs a WebSphere authentication as the username that is returned from the Security Token Service. The WebSphere Application Server user registry must contain a user that matches the username attribute returned by the custom mapping rule in the Security Token Service.

If you are using the example mapping rule as is, you must create a user in the WebSphere user registry called me_guest. This step is only needed for two-legged OAuth with the Trust Association Interceptor enforcement point.

Feedback