This space contains files and text snippets that are used throughout the Scheer PAS documentation.
This content is not meant to be read independently from the rest of the documentation.
Oops, it seems that you need to place a table or a macro generating a table within the Table Filter macro.
The table is being loaded. Please wait for a bit ...
Chapter
Name
Excerpt
Usage
APIs
api_contracts_and_keys
Only public APIs can be accessed by any consumer. The only way for a client to consume a private API is by using an API contract. An API contract is a link between a client and an API through a plan offered by that API.
API contracts can only be created between clients and published APIs which are offered through at least one plan. An API contract cannot be created between a client and a public API.
When an API contract is created, the system generates a unique API Key. This key is unique per client and the same for all contracts of this client. All requests made to the API by a client through the gateway must include this API Key. The API Key is used to create the runtime policy chain from the policies configured on the API, plan and client.
You can forward the X-API-Key to the service using the API Key policy. However, you cannot define your own value for the X-API-Key, since the gateway uses the key to identify the clients.
Enables HTTP BASIC Authentication on an API. Use this policy to require clients to provide HTTP BASIC authentication credentials when making requests to the managed API.
Enforces transport security when using HTTP to mitigate a range of common web vulnerabilities. Contains also a sophisticated mechanism to precisely define the types and sources of content that may be loaded, with violation reporting and the ability to restrict the availability and scope of many security-sensitive features.
Enables the user to shield some API’s resources from being accessed, without blocking access to all the API’s resources. Requests made to API resources designated as ignored result in an HTTP 404 (not found ) error code. This policy allows fine-grained control over which of an API’s resources are accessible.
Only inbound API requests from clients, policies, or APIs that satisfy the policy are accepted. The user must specify the IP address ranges to be included to be able to access the API. Any addresses that are not explicitly included are not able to access the API.
This policy blocks access to an API’s resource based on the IP address of the client. The user must specify the IP address ranges to be excluded from being able to access the API. Any addresses that are not explicitly excluded are able to access the API. It is possible to use wildcard characters to specify the IP addresses to be blocked. It is also possible to define the return error code sent in the response to the client in case a request is denied.
An IP Blocklist policy overrides an IP Allowlist policy.
This Keycloak-specific OAuth2 policy regulates access to APIs. It enables a wide range of sophisticated auth facilities in combination with, for instance, Keycloak’s federation, brokering and user management capabilities. Keycloak’s token format and auth mechanism facilitate excellent performance characteristics, with users able to easily tune the setup to meet their security requirements.
In general, this is one of the best approaches for achieving security without greatly impacting performance. Refer to API Security: Authentication and Authorization for more detailed information.
Manages a list of API routes that can be accessed at specific time and date. This policy allows to control when client and users are allowed to access your API.
Governs the number of times requests are made to an API within a specified time period. The requests can be filtered by user, client or API and can set the level of granularity for the time period to second, minute, hour, day, month, or year. The intended use of this policy type is for fine grained processing.
Tracks the number of bytes transferred. Enables the user to set a transfer quota (data) in B, KB, MB or GB for upload, download or both per client, user or API in a definable period of time. The response header can also be freely defined.
Turns a standard REST endpoint into a JSONP compatible endpoint. The caller must provide a JSONP callback function name via the URL.
If the API client does not send the JSONP callback function name in the URL, this policy will do nothing. This allows managed endpoints to support both standard REST and JSONP at the same time.
Headers can be set and removed on request, response or both. The values can be literal strings, environment or system properties. Headers can be removed by simple string equality or regular expression.
With this policy it is possible to cache requests based on their URL path, HTTP method and HTTP status code. This allows reducing overall traffic to the backend API.
Allows you to determine timeouts for your API. You can differentiate between a timeout for the initial connection and a timeout for the entire request.
