In the following examples, we use the Swagger Pet Store API to demonstrate some basic applications of some API policies.
In this document, we use the term APIs to denote the Triggered or Ultra Tasks against which the API policies are applied, as well as the APIs created through the API Manager console.
You can also view this video about the API Policy Manager.
Allowing Unauthenticated Access
To allow anyone to access the read-only parts of the pets API, you can apply the Anonymous Authenticator policy on the PetStore project. This policy authenticates any request that is not authenticated through a SnapLogic username and password. The default configuration for the policy authenticates the user making the request and assigns the “anonymous” role name. For this, no changes need to be made and the policy can be saved.
At this point, the policy is active and a request to the pet Task’s ground URL will flow through the policy. Making a request at this point should return the following message:
<IP_ADDRESS> is not authorized to access this API
This message means that the request was authenticated and the client is identified by the mentioned IP-address. However, while the request was authenticated, it was not authorized. Therefore, the request was rejected with a
403 Forbidden error. In order to authorize requests from anonymous clients, the Authorize By Role policy needs to be installed.
To authorize requests from anonymous clients, add a row to the Roles table where the value of the Role column is set to anonymous. To further restrict access to the APIs that are read-only, the Condition column can be used to check that the request methods are not a PUT or POST with the following expression:
!(request.method matches "PUT"|"POST")
No preview for expressions exist currently. However, the properties of the Policies are validated before they are saved. If the validation fails, a popup appears with the choice to disable and save the policy or return you to the editor to fix the issues.
Ensuring expressions are syntactically valid is part of the validation process.
Limiting the Unauthenticated Request Rate
Allowing unrestricted access to an API can compromise performance since a client can overload a Snaplex by making too many requests. To restrict the request rate of a particular client, you can apply the Client Throttling policy to limit the number of requests that a client can make over a period of time. The Throttling policy works by categorizing requests into different Service Tiers based on a condition. The limit is then applied separately for each user based on their ID. In the case of anonymous users, the user ID is the client's IP address.
To limit the number of anonymous requests to 250 per hour, add a Service Tier row to the Client Throttling configuration with the following settings:
Validating the Request
You can take the additional step to prevent invalid requests from invoking a Pipeline by adding an Authorized Request Validator Policy. This policy can perform arbitrary checks on the incoming request using expressions. If an expression evaluates to true, the request is rejected with a custom HTTP status code and response body. In the case of the Pet Store API’s pet endpoint, a limited number of path parameters are supported; therefore, we can add this policy to the Project with the following check to make sure the paths are valid:
asset.name == 'pet' &&
'Expecting a numeric pet ID'
Restricting the Size of PUT/POST Request Content
The Pet Store API supports uploading images of the pet using a POST request, which opens up another avenue for misuse from overly large images. To immediately reject requests with excessively large content, the Request Size Limit policy can be installed. In this case, the default limit of 10MB is probably enough for most images.