Policy Asset

This page describes the policy asset repository structure, policy import rules, supported policies, and interpolation scenarios.

On this page:

Policy repository structure

When policies and their associated configuration are exported successfully, the tool generates a standardized directory structure. This structure clearly separates tenant (common) policies from child organization–specific policies, making it easier to manage, version, and apply policies across organizations.

The exported directory structure appears as follows:

Copy 
repository/
└── export/
    └── common/
        └── policies/
            ├── AtmosphereApplicationSecurityPolicy/
            │   └── policy_configuration.yaml
            └── child_org/Throughput_limit_policy_childorg/
                    └── policy_configuration.yaml
repository
Root directory that represents the exported package version.
export
Stores all artifacts generated during the policy export operation.
common
Stores policies defined at the tenant level. These policies can be shared and reused across multiple organizations.
policies
Stores all exported policy definitions, organized by policy scope and name.
tenant policy
Represents a tenant‑level policy that is defined at the top organizational level and can be applied across multiple child organizations. The policy is stored in a directory named after the policy, such as AtmosphereApplicationSecurityPolicy, and the policy_configuration.yaml file in that directory defines the configuration for the tenant‑level policy.
child organization policy
Represents a policy that is scoped to a specific child organization. The directory structure child_org/Throughput_limit_policy_childorg/policy_configuration.yaml represents a policy that is scoped to a specific child organization. The top‑level directory, such as child_org, identifies the child organization, and the subdirectory, such as Throughput_limit_policy_childorg, represents the policy applied to that organization. The policy_configuration.yaml file defines the policy configuration specific to the child organization.
Policy names must be unique across the tenant and all child organizations. If a policy with the same name already exists at the tenant-level or in a child organization, the export operation fails. Likewise, if a policy with the same name exists during import, the import operation fails.

Example: Policy configuration YAML file

Copy 
policyName: "AtmosphereApplicationSecurityPolicy"
organization: "Tenant - open2025-1"
policyType: "Operational Policy"
policySubType: "policy.apisec"
description: ""
policyConfiguration: "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<wsp:Policy Description=\"\
  This is the security policy for Atmosphere applications.\" Name=\"AtmosphereApplicationSecurityPolicy\"\
  \ xmlns:wsp=\"http://schemas.xmlsoap.org/ws/2004/09/policy\">\n\t<ApiSecurity xmlns=\"\
  http://federatedgoverance.org/policy/apisecurity\">\n\t\t<signatureRequired>true</signatureRequired>\n\
  \t\t<possibleSignatureAlgorithms>SHA1</possibleSignatureAlgorithms>\n\t\t<possibleSignatureAlgorithms>SHA1withRSA</possibleSignatureAlgorithms>\n\
  \t\t<possibleSignatureAlgorithms>SHA256withRSA</possibleSignatureAlgorithms>\n\t\
  \t<possibleSignatureAlgorithms>HMACSHA1</possibleSignatureAlgorithms>\n\t\t<possibleSignatureAlgorithms>HMACSHA256</possibleSignatureAlgorithms>\n\
  \t\t<possibleSignatureAlgorithms>HMACSHA512</possibleSignatureAlgorithms>\n\t\t\
  <clockSkewInSec>120</clockSkewInSec>\n\t</ApiSecurity>\n</wsp:Policy>"
state: "Active"

Import rules

This section explains how Akana processes policies during import and how it determines whether a policy is created, updated, or rejected in the target environment.

How policy import works?

When you import policies by using API Ops, Akana evaluates each policy against a set of rules defined in the import configuration file (import-config.yaml) and the selected import strategy.

These rules ensure that:

  • Policies are imported into the correct organization.
  • Existing policies are not unintentionally overwritten.
  • Policy type and subtype mismatches are detected.
  • Required dependencies, such as identities, are available in the target environment.

How Akana matches policies?

To determine whether a policy already exists in the target environment, Akana compares the following attributes:

  • Policy name
  • Policy type
  • Policy subtype
  • Organization

A policy is considered a match only when all attributes are identical.

If a policy with the same name exists but the type or subtype differs, Akana does not treat it as a match. This prevents incorrect policy associations during import.

Organization consistency

Policies are always imported into the same organization from which they were exported. During export, the policy’s organization is captured in the metadata, and during import, Akana uses this information to associate the policy with the correct organization. If a policy with the same name exists in another organization, Akana preserves the original organization context to avoid cross‑organization conflicts.

Import strategies

The import strategy defines how Akana handles policies when a match is found in the target environment. Configure the strategy in the import-config.yaml file.

Create: Always creates a new policy and fails if a matching policy already exists.

CreateOrFail: Creates the policy only if no matching policy exists; otherwise, the operation fails.

CreateOrUpdate: Creates the policy if it does not exist, or updates the existing policy if a match is found.

Dependency handling

Some policies depend on identities, such as OAuth or other security configurations.

During import:

  • Akana checks whether the required identity exists.
  • If the identity does not exist, Akana creates it automatically.

This ensures that imported policies function correctly after deployment.

Policy hierarchy

Before importing policies, Akana performs the following steps:

  1. Retrieves the policy hierarchy starting at the tenant level.
  2. Filters policies based on:
    • Name
    • Type
    • Subtype
  3. Applies the selected import strategy to each policy.

Error handling and logging

During the import process, Akana logs key information to help you troubleshoot issues, including exported policies, successfully imported policies, and any validation or import errors.

Supported Policies

The process supports all actively supported Akana policy types except the following:

For more information, see About Policies.

Supported policy types

Aggregate policy that reference other policies cannot be exported or imported.

Interpolation scenarios

Interpolation allows you to dynamically modify policy configuration files without manually editing the source policy artifacts. You can define interpolation rules in the import configuration file and those rules are applied to matching policy files at runtime.

Example 1: Update Open Banking version and documentation URL

The following example updates the Open Banking metadata in a policy configuration file.

Copy 
xmlInterpolations:
  - filterValue: ".*JOSE-OB-1-IN_AutoTent/policy_configuration.yaml"
    xPath: "//*[local-name()='OpenBankingVersion']"
    value: "4.0"
    
  - filterValue: ".*JOSE-OB-1-IN_AutoTent/policy_configuration.yaml"
    xPath: "//*[local-name()='OpenBankingDocUrl']"
    value: "https://openbankinguk.github.io/read-write-api-site3/v4.0/profiles/read-write-data-api-profile.html"

Example 2: Update private header values

The following example changes the value of specific headers by targeting the header attribute.

Copy 
xmlInterpolations:
  - filterValue: ".*JOSE-OB-1-IN_AutoTent/policy_configuration.yaml"
    xPath: "//*[local-name()='Header'][@Name='http://openbanking.org.uk/iat']/@Value"
    value: "new-iat-timestamp-40"

Example 3: Update the policy description

The following example updates the policy description field.

Copy 
jsonInterpolations:
  - filterValue: ".*BasicAuditing/policy_configuration.yaml"
    jsonPath: "$.description"
    value: "Auditing Message Policy"

Example 4: Set the policy state to Active

The following example sets the policy state to active.

Copy 
jsonInterpolations:
  - filterValue: ".*BasicAuditing/policy_configuration.yaml"
    jsonPath: "$.state"
    value: "Active"