Client ID-Based Policies
API Manager provides several client ID-based policies:
If you want to track application access to your API, apply one of these policies to handle client ID authentication. Ensure that your application provides its client ID and client secret in every request made to your API.
When registering an application in an API portal, users obtain credentials, the client ID and client secret, that you configured when applying the policy.
The Client ID Enforcement policy simply enforces requirement for credentials. Rate Limiting - SLA-Based and Throttling - SLA-Based policies use the client ID as a reference to impose limits on the number of requests that each application can make within a period of time.
The information in these sections applies to all client ID-based policies.
When an application calls an API that enforces a client ID-based policy, API Manager expects client_id and client_secret from the application in the form of query parameters. By default, the query parameters are in the format of client id and client secret expressions. Alternatively, you can remove the client_secret expression and provide only the client_id in the dialog that appears when you apply a client id-regulating policy. In that case, the only a client ID is required.
In Mule Runtime 3.8.0 and later, you can also select HTTP Basic Authorization Header to use Basic Authentication as the origin of the credentials.
Users need to send a token in addition to an ID with every request to an API that enforces client id-Based policies. To obtain the ID and token, users request API access using the Request API Access control on the portal for the API.
After users click the Request API Access button, they are prompted to select an existing application or create a new one. The request for API access can be automatically approved or, in the case of an client ID-, SLA-based policy, require approval by an admin of the API.
Approve API access requests from the API version details page, and select the Applications tab in the bottom section of the screen.
Use Mule expressions to pass query parameters, client_id and client_secret, from an application to an API that enforces a client ID-based policy:
1 2 3 #[message.inboundProperties['http.query.params']['client_id']] #[message.inboundProperties['http.query.params']['client_secret']]
You can change this expression to expect these values in any other element in the Mule Message.
When an HTTP request is transformed into a Mule Message, the following transformations occur:
Query parameters become part of
Headers become part of
Form parameters become a map in
If your API exposes a RAML definition that users may need to reference (perhaps via the API Console, which is generated from a RAML file), then the RAML definition should reliably detail every element that is expected in calls to your API.
As established, applying one of these client ID-based policies implies that all requests coming to your API need to include both a client ID and client Secret (by default expected as query parameters). To prevent user requests from being rejected, create a trait at the start of your RAML definition and then reference this trait in every operation of your API. The trait might look like this:
1 2 3 4 5 6 7 traits: - rate-limited: queryParameters: client_id: type: string client_secret: type: string
And then you can apply this trait in each individual operation like this:
1 2 3 4 /products: get: is: [rate-limited] description: Gets a list of all the inventory products.