Policies
This section describes the general features of the policies. For detailed information on any policy and how to configure it, please refer to the relevant policy's own page.
Entities used to define a set of rules, restrictions and transformations for the purposes of security, performance improvement and ease of use for messages coming to or returning from the API are generally referred to as policies.
The policy allows API behavior to be 'programmed' without the need for code development. It is designed to easily and reliably meet common management requirements for APIs.
It offers features such as security, rate limiting, conversion and brokerage capabilities and relieves you of the burden of writing code and maintaining these functions. Each policy works like a separate module that implements a specific function and whose behavior can be customized by configuration.
Policy Types
The policies offered on the Apinizer Platform can be roughly grouped functionally as follows:
Security Policies
- Plain-Text Authentication
- Basic (Base64) Authentication
- Digest Authentication
- JWT Authentication
- OAuth2 Authentication
- JOSE Validation
- JOSE Implementation
- mTLS Authentication
- Backend API Authentication
- SAML Authentication
- Encryption
- Digital Signature
- Decryption
- Digital Signature Verification
- WS-Security (To Target)
- WS-Security (From Target)
- WS-Security STS Token
- Authorization
Access Control Policies
Data Manipulation Policies
Threat Protection Policies
- Regular Expression Message Filters
- JSON Schema Validation
- XML Schema Validation
- Maximum Message Size
- Minimum Message Size
Other Policies
Policy Enforcement Points
Policies can be applied on 3 different points.
- On API Proxy Groups: When a policy is enforced on an API Proxy Group, this policy applies to all API Proxies in that group.
- On API Proxies: When a policy is applied on an API Proxy, this policy is applied for all methods/endpoints of that API Proxy.
- On methods/endpoints of API Proxies: The policy applied on a method/endpoint is only executed for that method/endpoint, it does not affect other method/endpoints.
For detailed information on the enforcement of policies on different points and the order of execution of these policies, see the Development Tab section.
Policy Usage Types
Policies can be Local or Global.
Local Policy
A local policy can only be created on the Development Tab of the API Proxy to which it is intended to be added and can only be used by this API Proxy. If the API Proxy is deleted, local policy is also deleted with it.
Global Policy
Global policies can be created independently of API Proxies from Global Policies interfaces or from within the Development Tab of an API Proxy. A global policy can be used by zero or more API Proxies. When an API Proxy is deleted, the global policies used by that API Proxy are not affected. However, any update to the global policy affects all API Proxies that use that policy.
Policy Structure
Policies are structurally the same except for the configuration information that differs in terms of the specific function they are defined for, and they contain some common data fields.
Common Data Fields
These data fields, which are common to all policies, are given in the table below.
| Field | Description |
|---|---|
| Name | It does not appear in the interface as it is not needed for local policies. However, it is a required field for global policies and is used in policy selections so that the users can find the policies they are looking for. It must be unique within a project. |
| Description | It is an optional, short explanation information about the policy. It is useful to enter it for global policies. |
Conditions | Sometimes it is desirable to decide whether to operate an added policy, for example, by looking at the existence of a parameter or the value of a header. Apinizer provides Conditions section for all policies so that users can define such requirements. Conditions can use logical operators such as AND, OR, NOT. The conditions are tested before the policy is executed, and if the conditions are not met, the policy will not be executed. |
Error Message Customization | When executing any policy, an error message may be returned to the client for various reasons. Apinizer has predefined error codes and messages for each policy depending on the cause of the error. Users can customize these error codes or messages for any policy. |
| Active | Indicates the status of the policy. By default, policies are created with the value Active. However, for any reason, they can be temporarily disabled by making the value of this field Passive. |
Defining a Condition
By adding conditions to the policy, it is ensured that it works only when the defined conditions are met. The image below shows an example condition where the selected policy will run only if the value of the status parameter is pending.
Error Message Customization
The HTTP Status Code, Error Code, and Error Message fields in the error messages are customizable. Error codes and messages can be customized for a policy in the policy definition interface, as well as error customization can be made across the platform.
The Customize Error Message fields are shown in the table below.
| Field | Description |
|---|---|
HTTP Status Code | It is the default HTTP status code. Its default value is set via the System Settings → Error Messages screen. |
Error Code | It is the default error code. Its default value is set via the System Settings → Error Messages screen. |
Original Message | It is the default error message. Its default value is set via the System Settings → Error Messages screen. |
Customized HTTP Status Code | It is the custom HTTP status code that will be returned for the error. |
Customized Error Code | It is the custom error code that will be returned for the error. |
Customized Error Message | It is the custom error message that will be returned for the error |