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

• Blocked IP Address List
• Allowed IP Address List
• Time Restriction
• API Based Quota
• API Based Throttling

Data Manipulation Policies

• JSON Message Transformation
• XML Message Transformation
• Redaction

Threat Protection Policies

• Regular Expression Message Filters
• JSON Schema Validation
• XML Schema Validation
• Maximum Message Size 
• Minimum Message Size

Other Policies

• Script
• API Call
• Business Rule

Policy Enforcement Points

Policies can be applied on 3 different points.

1. On API Proxy Groups: When a policy is enforced on an API Proxy Group, this policy applies to all API Proxies in that group.
2. On API Proxies: When a policy is applied on an API Proxy, this policy is applied for all methods/endpoints of that API Proxy.
3. 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 View Page General Structure

A specifically designed "Policy View Page" is available for policies. This page allows users to review the details of a policy and view the current configuration without making any edits.

The general structure of the page consists of the following sections:

Policy General Information:

• Name: The unique name of the policy.
• Status: Indicates whether the policy is Active or Passive.
• Description: Provides brief information about the policy.
• Global: Specifies whether the policy is global.

Policy Settings:

This section includes technical settings related to the functionality of the policy, such as:

• Authentication methods.
• Parameters, algorithms, and necessary technical configurations used.

Conditions:

Rules that define under which circumstances the policy will operate.

Error Message Customization:

Allows the management of error messages returned in case of issues related to the policy:

• HTTP Codes: The HTTP status codes returned.
• Error Codes: The specific error codes.
• Original and Customized Error Messages: Displays and allows editing of the original and customized error messages.

Actions:

Provides users with options such as editing, changing the status, or exporting the current policy:

• Edit: Used when changes need to be made to the policy.
• Deactivate: Temporarily disables the policy and halts the execution of any associated rules.
• Export: Used to back up the policy or transfer it to another project.
• Back: Navigates the user back to the listing screen or the previous page for easier navigation.

With this information, users can easily understand how a policy works and manage error situations effectively.

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.

Defining a Condition 

By adding conditions to the policy, it is ensured that it works only when the defined conditions are met. The selected conditions that can be applied to the policy are shown in the image below.

The image below shows an example condition where the selected policy will run only if the value of the status parameter is pending.

When the "in list" or "not in list" option is selected as the condition value comparison operator, the # character should be used to separate the list values. For example, user1#user2#user3.

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.