Policy List

API Platform Version: 8.1 and later

Includes information about the following types of policies:

  1. Basic Policies Available in Add/Edit API
  2. Additional Operational Policies Available in Policy Manager
  3. Additional Service-Level Policies Available in Policy Manager
Default Policies Available in the Akana API Platform

The policies below are available by default in the Akana API Platform. Policies are visible in the Implementation page, where you can click through to assign one or more policies to an implementation.

Policy Name Type/Link
AtmosphereApplicationSecurityPolicy (In Policy Manager, API Consumer Application Security Policy)

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.

BasicAuditing

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 DetailedAuditing policy.

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

Category: Auditing

DetailedAuditing

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.

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

Category: Auditing

OAuthSecurity

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.

Back to top

Additional Operational Policies Available in Policy Manager
Policy Name Description
CORSAllowAll

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.

Cross-Site Scripting Detection policy

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 a white list of tags.

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

HTTP Malicious Patterns 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 Patterns Detection Policy.

Metrics 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.

JOSE Security 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. It conforms to the JSON Web Signature (JWS) standard (https://tools.ietf.org/html/rfc7515) and the JSON Web Encryption (JWE) standard (https://tools.ietf.org/html/rfc7516).
Paging policy

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.

Schema Validation 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.

WS-Schema Validation policy

Schema validation policy for WS-Schema.

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

API User Security Policy

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

Category: Security

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

OAuth 1.0a Trusted Token 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.

OAuthSecurity

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.

WS-Auditing Message Policy

Used to audit service operations and binding operations.

Category: Auditing

WS-Auditing SOAP Message Policy

Used to audit service operations and binding operations.

Category: Auditing

WS-Auditing SOAP Service Policy

Used to audit SOAP binding operations.

Category: Auditing

WS-Auditing Service Policy

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

Category: Auditing

WS-Auditing Transaction Tracking Policy

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

Back to top

Additional Service-Level Policies Available in Policy Manager

Defines conditions for measuring and reporting performance of a specific contract. Each policy is composed of a "Rule" and "Access Interval." Rules represent the conditions you define to measure and report performance of a service contract. When a defined system condition matches a defined rule, an alert is raised.

Policy Name Description
Bandwidth Quota Policy

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)

Script 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)

Service Level Enforcement

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)

Throughput Quota 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)

Timeout 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)

Concurrency Quota 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)

Back to top