Contact Free trial Login

Client ID enforcement

Policy Name

Client ID enforcement

Summary

Allows access only to authorized client applications

Category

Security

Since Mule Version

3.8.0

Returned Status Codes

401 - Unauthorized or invalid client application credentials

500 - Bad response from authorization server, or WSDL SOAP Fault error

The Client ID Enforcement Policy restricts access to a protected resource, by only allowing HTTP requests if credentials of client applications already registered to (contracted with) the API being targeted are provided in each request.

The policy validates the Client ID and, optionally, the Client Secret, of a client application created within an Anypoint Platform Organization.

This policy will not validate successfully any client application credentials generated outside of the Anypoint Platform context.
The set of Client ID and Client Secret are also known as credentials.

Analytics and access tracking

If you need to track client application access to your API, apply a policy that directly or indirectly makes sure that client ID is provided in the HTTP request (ie Client ID enforcement type policy).

Indirect client ID enforcement

There are other provided policies that enforce client application credentials. For example:

In Mule 3.8.5 or later, the following OAuth 2.0 Token Enforcement policies include a client ID enforcement validation:

Offline mode

Credentials data from client application credentials registered to protected APIs, are provided by Anypoint Platform. Once a policy requiring such information is applied (eg Client ID enforcement policy), the Runtime caches persistently the information locally updating it periodically.

Besides its performance benefits, this action enables the policy to work offline in the event of a sudden loss of connectivity to the platform. The enforcement is applied regardless of the state of the management plane, with existing data. Once connectivity is re-established, the cache will be periodically updated again.

REST Console

To prevent user requests from being rejected when using the REST Console, create a trait in the RAML root and then reference it in every operation of your API affected by policy. You may find the RAML snippet link containing the RAML code you need to add to the RAML in the corresponding policy from the list of applied policies in the Policies tab of your API specification in API Manager.

raml snippet

Credentials source

The policy can be configured to extract the client ID and client secret from the HTTP request in different ways using DataWeave 2.0 expressions.

The following examples assume that the values for application credentials are '1234' for client ID and 'abcd' for client secret.

If when configuring the policy, client secret DataWeave 2.0 expression is specifically not specified (ie empty field), then only the client ID specified on the HTTP requests against the protected resource will be validated.

Credentials as HTTP headers

Example request using curl:

curl "http://localhost/myResource" -H "client_id:1234" -H "client_secret:abcd"

Example DataWeave 2.0 expression to be used when configuring the policy:

#[attributes.headers.['client_id']]
#[attributes.headers.['client_secret']]

Credentials as HTTP query parameters

Example request using curl:

curl "http://localhost/myResource?client_id=1234&client_secret=abcd"

Example DataWeave 2.0 expression to be used when configuring the policy:

#[attributes.queryParams.'client_id']
#[attributes.queryParams.'client_secret']

Credentials included in HTTP request payload

Example request using curl:

curl "http://localhost/myResource" -d '{"client_id":"1234", "client_secret":"abcd"}' -X POST

Example DataWeave 2.0 expression to be used when configuring the policy:

#[payload.client_id]
#[payload.client_secret]

Credentials as Basic Authorization header

Example request using curl:

curl "http://localhost/myResource" -u 1234:abcd

Example DataWeave 2.0 expression to be used when configuring the policy:

No DataWeave 2.0 expression needed to be specified when the policy is configured to use the Basic Authentication as the origin of the credentials.

WWW Authenticate HTTP header

When a HTTP request is performed against a protected resource, where the Client ID enforcement policy is applied, and client application credentials are invalid or unauthorized, the HTTP response includes a WWW Authenticate header with the following values:

Custom mode

Header 'WWW-Authenticate'='Client-ID-Enforcement'

Basic Auth mode

Header 'WWW-Authenticate'='Basic realm="mule-realm"

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub