Policy List

Security policy for apps on the platform. Used to identify (authenticate) an app that is attempting to access an API, to make sure the app is authorized. This policy type supports multiple mechanisms for the app to present its identity, including plain text App ID, signed header with x.509 certificate, or shared secret.

Most or all APIs on the platform have this policy assigned.

For more information, see Using the API Consumer Application Security Policy.

Provides basic auditing of messages. Message metrics are recorded in the Policy Manager Usage Logs Monitoring tab. The request and response messages are not logged. If auditing of individual messages is needed, use the Detailed Auditing policy.

The difference between the Basic Auditing and Detailed Auditing policies is that the Detailed Auditing policy captures the payload, and the Basic Auditing policy does not.

For more information, see: Using the Basic Auditing Policy.

Note: Only attach one auditing policy to an API; for example, Basic Auditing policy or Detailed Auditing policy, but not both.

Category: Auditing

Provides detailed auditing of messages. Message metrics are recorded in the Policy Manager Usage Logs Monitoring tab as well as the entirety of each message, including request and response.

The difference between the Basic Auditing and Detailed Auditing policies is that the Detailed Auditing policy captures the payload, and the Basic Auditing policy does not.

For more information, see: Using the Detailed Auditing Policy.

Note: Only attach one auditing policy to an API; for example, Basic Auditing policy or Detailed Auditing policy, but not both.

Category: Auditing

An Akana API Platform policy that enables API authorization using OAuth 2.0. It uses the OAuth configuration assigned to an API when enforcing OAuth tokens in a received request.

For more information, see: Using the OAuth Security Policy.

The OAuthSecurity policy also has three configuration options:

• TokenTransformation
• IncludeTokenAttributes
• ScopeRequirement

For details, see OAuth Security Policy Configuration Options.

CORS (cross-origin resource sharing) enables users to access resources from within the browser serving a web page, and defines a way in which the browser and the server can interact to determine whether or not to allow the cross-origin request.

For more information, see: Using the CORS policy.

The CORSAllowAll policy allows all cross-origin requests.

The Cross Site Scripting Detection Policy is an Operational policy that allows you to block potentially malicious HTML tags in the request message body using what is called an allowlist (previously called whitelist) of tags.

For more information, see Using the Cross-Site Scripting Detection Policy.

Used to inspect the HTTP messages for content that could be considered dangerous to an API or web service, and to reject the message returning a fault if any of the defined expressions match the content.

For more information, see Using the HTTP Malicious Pattern Detection Policy.

The Metrics Policy is an Operational policy that allows you to collect roll-up data for selected services/operations that the policy is attached to.

For more information, see Using the Metrics Policy.

A security policy that can be attached to RESTful and messaging services, to secure any message content. This policy supports JSON signatures and/or encryption in the messages.

The JOSE specification offers a way of signing payloads in such a way that it's relying on keys from whoever is doing the signing. With JOSE, a set of attributes are put together in a specific format, such that it's very clear what the consumer, or the provider, is trying to convey in that format. And then, verification follows a standard set of rules.

With JOSE Policy v2 you can do the following:

• Sign and/or encrypt content
• Validate signed and/or encrypted content
• Send either signed or raw data to the client or the downstream service
• Check for Open Banking specification requirements

This policy supports both of the following:

• Scenarios where the entire message, including header, payload, and signature, is signed and/or encrypted.
• A detached, unencoded payload scenario where the payload is sent as the body of the message and only the header and signature are signed and/or encrypted.

For more information, see Using the JOSE Security Policy v2 (Unencoded Payload Support).

Note: If you're attaching this policy to your API, with a serialization setting of JSON, make sure that the operations in the API support the application/jose+json content-type.

The Paging Policy is designed to allow a client to only get a subset of a list based response. For example, if an operation is returning a list of books, and the full list is 1000 books, the client may wish to only have 100 books be returned at a time.

For more information, see Using the Paging Policy.

Performs schema validation. A common integration problem in a service-oriented architecture occurs when consumers send messages to services that don’t conform to the services' message schemas. Typically this is caused by the versioning of a service’s schema, and a consumer sending a message that conforms to a prior schema version. It can also be a consumer’s malicious attempt to cause a denial of service by sending invalid messages to a service. An SOA Container can aid by validating the messages exchanged between the consumers and services against the service’s published schema.

For more information, see Using the Schema Validation Policy.

Schema validation policy for WS-Schema.

For more information, see Using the WS-Schema Validation Policy.

The default security policy for Akana API Platform services and controls who can perform administrative actions on the Community Manager developer portal.

Category: Security

For more information, see Using the API User Security Policy.

An Akana API Platform security policy that provides OAuth Pass-thru support when OAuth 1.0a is used to perform API authorization.

Category: Security

For more information, see Using the OAuth 1.0a Security Policy.

An Akana API Platform policy that enables API authorization using OAuth 2.0. It uses the OAuth configuration assigned to an API when enforcing OAuth tokens in a received request.

Category: Security

For more information, see Using the OAuth Security Policy.

Used to audit service operations and binding operations.

Category: Auditing

Used to audit service operations and binding operations.

Category: Auditing

Used to audit SOAP binding operations.

Category: Auditing

Used to audit Services, Bindings, Operations, and Access Points.

Category: Auditing

Supports Transaction Tracking functionality that correlates related web service events within a single activity or transaction. For example, if a service in a Container uses the Akana Delegate to call another service in a different container that is managed by the Akana Agent, it will automatically insert correlation information into the message that is collected and used by Policy Manager to collect tracking and log information.

Category: Auditing

Allows you to configure the bandwidth cap (i.e, quota) that a consumer can upload or download at any given time. The bandwidth cap can be specified as kilobytes or megabytes per second. If the quota is exceeded, the runtime will throttle the traffic to conform to the quota policy. The quota is also assigned to either the request (upload) or response (download). No alerts are generated for this policy since the bandwidth consumed is a function of the network speed and capabilities of the service provider, not the consumer.

Category: QoS (Quality of Service Policy)

Allows you to update a policy defined using BeanShell or Jython script languages. A series of predefined functions and variables are provided that allow you to build a custom policy expression that is evaluated at runtime. Several sample scripts are also provided that illustrate common quota management activities.

Category: QoS (Quality of Service Policy)

The Service Level Enforcement Policy is a Quality of Service (QoS) policy that allows you to enable and configure the error message returned to the consumer when their SLA is violated.

This policy works in conjunction with a Service-Level Policy and only applies to the following Service-Level rules: "Usage Count," "Total Request Message Size," and "Total Response Message Size."

You define a Service-Level Policy and specify each service level condition and alert code, then you define a Service Level Enforcement Policy and specify the error message you would like displayed when a specified service level condition is violated.

Category: QoS (Quality of Service Policy)

Allows you to monitor web service throughput performance by specifying a throughput limit (quota), queue size, and configuring fault and alert notifications.

If the quota is exceeded, a consumer fault message will be returned to the service consumer and an alert will be logged.

Category: QoS (Quality of Service Policy)

Allows you to configure the timeout for each request and specify a custom fault error message that is returned to the client.

Category: QoS (Quality of Service Policy)

Allows you to monitor the web service concurrency performance by specifying a concurrency limit (quota) that represents the maximum number of concurrency connections, and configuring fault and alert notifications.

If the specified concurrency limit is exceeded, Policy Manager will return a fault and send an alert.

Category: QoS (Quality of Service Policy)