What's New in Akana API Platform

FAPI 1.0 Advanced Profile Support

Akana OAuth provider now supports FAPI 1.0 Advanced Profile (FAPI), designed to meet the highest security and privacy requirements for financial-grade APIs.

Key Features:

• The Akana OAuth provider domain can be configured to comply with the FAPI profile by enabling the FAPI profile flag in the domain settings. Once enabled, the OAuth authorization and token endpoints will enforce stricter security requirements in line with the FAPI profile.
• The External OAuth provider domain such as PingFederate will also support FAPI profile compliance.
• The Akana OAuth policy will enforce additional validations on incoming access tokens in the API requests when the FAPI profile is enabled for corresponding Akana or External OAuth domains.

Review FAPI Support in the documentation to start using the FAPI feature support in Akana. Akana 2024.1.1 also includes bug fixes and security measures. Please check the release notes for other updates. 

TLSv1.3 Support

Akana has added  TLSv1.3 support in this release, enhancing the security, performance, and compatibility of our product. For enhanced compatibility both TLSv1.3 and TLSv1.2 protocols can be enabled for Akana inbound and outbound communication. Akana supports TLS_AES_256_GCM_SHA384, and TLS_AES_128_GCM_SHA256 and cipher suites for the TLSv1.3 protocol.

Please refer the “Enabling TLS v1.2 and v1.3” and “Limit outbound SSL/TLS/Cipher support” in the Akana Platform Hardening Guide for detailed steps to enable protocol.

Akana 2022.1.3.2 also includes bug fixes and security measures. Please check the release notes for other updates. 

Key Enhancements and Features in 2024.1.0

Akana 2024.1.0 includes numerous upgrades and enhancements, including in-place container upgrades.

In-Place Container Upgrades 

This release offers improved capabilities for in-place container upgrades. You can now easily apply cumulative upgrades to any Akana container.

To allow for a rollback of the upgrade, a snapshot of the container state is automatically created just before the upgrade is being applied. The container updates can be easily uninstalled using the rollback function, which restores the container to its state captured in the snapshot.

Apply and rollback functions can be executed through the container’s Admin Console or by using automation recipes. New recipes (named install-patch.json and rollback-patch.json) have been added.

In-place container upgrades (or rollback of these upgrades) are executed on a running container. The container will automatically be restarted once the upgrades have been successfully applied (or rolled back).

This feature is applicable to all Akana containers. Learn more in this video:

OpenAPI Specification 3.1 Support

Akana has added support for the OpenAPI Specification (OAS) 3.1. Key enhancements introduced along with this feature are:

• Creating and updating REST APIs using OAS 3.1 format.
• Downloading the OAS 3.1 API specification from an API.
• Validating the request and response for APIs using the HTTP Message Validation policy. 
• Viewing the OAS 3.1 documentation with partial support for OAS 3.1 constructs.
• JSON Schema 2020-12 Compatibility.
• JSON schema type 'null'
• Discriminator property for oneOf, anyOf keywords

For other enhancements and bug fixes, see the release notes. 

Starting version 2022.1.2.10, Akana adds support for using AWS Identity and Access Management (IAM) authentication tokens when accessing Amazon RDS (Relational Database Service) instances. When the IAM feature is enabled on the Amazon RDS instance, Akana communicates with the RDS instance using the IAM token instead of traditional database credentials. Akana has certified this feature with MySQL and Aurora MySQL-compatible databases.

Please check release notes for other updates 

Oracle 23c support has been added.

Starting with version 2022.1.2.9, the Akana platform now supports Oracle 23c.

Added support configure additional parameters for OpenID Connect Relying Party Domain.

The OpenID Connect Relying Party Domain now allows the option to configure additional parameters required by the OIDC provider.

This feature allows Oracle Access Manager to be configured as the OIDC domain for single sign-on.

Please check release notes for other updates.  

What’s New In Akana 2022.1: GraphQL Support Release

The latest Akana Platform upgrade includes improved cloud capabilities, security, and API automation. An important new feature with this upgrade is our support for GraphQL, an open-source query language for your APIs and a runtime for executing queries on your data. This new feature allows you to now manage RESTful, SOAP and GraphQL APIs from a single Akana environment. In short, all API endpoints can now live and be managed in the same API catalog.

With our latest Platform release you get first-class support for creating, documenting, publishing and testing GraphQL APIs.  

Akana API Management For GraphQL

GraphQL API Design

Our upgraded Developer Portal UI now allows you to include GraphQL schemas at the API design level. For example, you can import a GraphQL schema document and have Akana generate the corresponding API product. If necessary, you can modify the schema as you see fit, or isolate sections from the schema to create distinct proxies without exposing the entire graph; the API product will automatically reflect these changes.

Lifecycle Management, Policies & Monitoring

Our new GraphQL features unlock a simplified and more comprehensive lifecycle management process. Your developers can now easily create API products that give access to GraphQL endpoints. View GraphQL documentation, apply security policies to query and/or mutation operations as applicable, make modifications to existing schema in a streamlined lifecycle approach and monitor your GraphQL APIs at runtime. GraphQL test and try-out is supported with inline documentation test client.

GraphQL Runtime & Test Client

Akana provides the virtual API endpoint which can be directly called from any client application. Additionally, you can test the GraphQL endpoint from our Developer Portal in the same fashion as RESTful APIs, with introspection capabilities integrated into the test client.   

API Security and Authorization

Security and authorization for GraphQL APIs are ultimately managed at the API gateway level. GraphQL APIs benefit from existing comprehensive security and authorization capabilities already present with the Akana API Gateway. For example, access to your GraphQL endpoint can be easily secured with OAuth2.0.

GraphQL API Publishing to Portal

Publishing to the portal has always been easy with Akana. Now with support for GraphQL, it’s even easier. Our API Developer Portal allows you to upload GraphQL schema documentation and have Akana generate the corresponding API product. Furthermore, you can manage which developers and API consumers can run queries against your data. This means only authorized parties can consume GraphQL APIs, further enhancing security for complex API operations.

Akana Unlocked

Our latest release is part of our Akana Unlocked initiative, which is helping customers get more out of their API management programs. Whether you’re a current or future customer, all Akana modules are now available free of additional charge.

What’s New in Akana 2020.2.0?

The Akana 2020.2.0 release expands cloud support, enhances security, and makes customization easier. To see the full details of the release, view the release notes. 

Additional Cloud Support

AWS CloudHSM Support [NEW]

Akana adds support for the AWS CloudHSM cloud-based hardware security module. Contact your account executive to get started.

Docker Images Support Enhanced

Enable better environment standardization, portability, compatibility, and ease of maintenance with the enhanced support for installation via specific Akana Docker images. 

Docker images are now available to download:

• Akana 2020.2.x Product Downloads
• Akana Envision Product Downloads
• Akana Lifecycle Manager Product Downloads

Enhanced Security

Akana OAuth/OIDC Provider Domain Adds Support For PKCE

This release adds support for the optional PKCE security extension for OAuth, with the Authorization Code grant type. PKCE (Proof Key for Code Exchange) enhances security by adding an additional key with the authorization code request and again with the token request.

Easier Customization

Guidance For Customizing Your API Marketplace (Community Manager Developer Portal)

You now have more options and guidance for customizing your API marketplace. Learn more >>

Download Customization Samples

A zip file of the customization samples is now available to download within the Community Manager developer portal. (Go to the Customization page, accessed via More > Admin > Customization > Download Customization Samples.)

Enhancements to the Developer Portal

Enhancements to the Community Manager developer portal include:

• Operation-specific policy support: Policies can now be assigned to a specific API operation, in addition to assigning at the API level.
• Process Editor now available from the API Details page: To open it, choose API > Details > Design section > specific operation, Actions drop-down; then select Edit Live Process or Edit Sandbox Process.

Additional Enhancements

Technology Upgrades

Adobe Flash has been replaced in Policy Manager's Real Time and Historical Charts.

Automation Recipe Enhancements

This release includes out-of-the-box automation recipes that have been enhanced to support various use cases for configuring security across Akana containers.

Release Notes

Kafka for Analytics

This release adds a deployment option for Apache Kafka. This new product allows audit and metrics data to be streamed to Kafka topics. Akana gateway performance and reliability can be improved with the Kafka option.

Envision Business Analytics: Performance and UI Enhancements

Akana has a renewed focus on the Envision product and relaunched it with numerous performance and usability enhancements to the UI and charting capabilities.

New API Consumer-Focused Theme "Bonita"

A new theme called Bonita, added alongside Akana’s existing themes, with a streamlined interface provides API information from the perspective of an API consumer, including the API overview, documentation, API analytics, and Test Client.

Analytics Enhancements

Tenant metrics: The developer portal now includes the ability to generate usage statistics and metric information across all businesses for the tenant on a monthly basis.

My Dashboard: The developer portal now includes a new user dashboard to simultaneously monitor up to 10 APIs.

Performance Improvements

Enhancements made across different components from the UI to the gateway include faster gateway startup times, faster message processing, and faster analytics.

The script startup.sh now takes a new environment variable AKANA_OPTS as an argument, which can be used to configure the container JVM. For example, it can be used to configure AppDynamics, other agents, Java Management Extensions (JMX), Garbage Collector (GC) options, or to add JVM system properties.

A JOSE Policy v2 configured for OB 3.1 now validates the tan header using the value configured in the policy, if one exists. If no value for the tan header is provided in the policy configuration, then the header is validated using the static domain value openbanking.org.uk.

The Developer Portal adds support for OpenAPI 3.0. OpenAPI 3.0, based on the original Swagger 2.0 specification, provides a standard, language-independent interface to RESTful APIs. Support includes an OAS Schema Form Editor, which is a graphical and text editor for authoring and editing Open API Specification v3 documents.

The editor supports syntax and semantic validation on save or switch between text and graphical view, as well as code completion and syntax highlighting. The API Designer also supports dynamic switching between OAS 3.0 and Swagger 2.0.

The new Model Library is a centralized library of model objects in the context of a business on the platform. Highlights include:

• The ability to reference Model Library objects from any APIs in the business, so that APIs and API consumers can work with consistent data definitions across all APIs
• Support for JSON Schema Draft 4
• Support for importing existing models
• Support for inline authoring of the model definition via the Schema Designer, which offers two modes: a simple JSON text editor and a form editor
• The Business Admin's full permission for the Model Library with two new roles: a Model Designer and a Model Administrator
• Support for multiple, valid versions of a model object
• Addition of a new, customizable, governance workflow
• The ability to group models into categories

The platform supports multiple authentication policies on a single API using the Aggregate Policy. The Aggregate Policy includes a new “Choose Policy Enforcement Requirement” page.  Users can select either the logical OR (if the message meets the requirements of any one of the policies included in the Aggregate Policy, the request is successful) or AND (the request must meet the requirements of all policies included in the Aggregate Policy, or it will fail).

An OAuth policy can authenticate and authorize requests against multiple, different providers. The API OAuth Details page in Community Manager now allows the assignment of an OAuth provider to multiple endpoints, assuming that the Admin has configured multiple OAuth providers. The provider used for messages to an API depends on the scopes set up for each OAuth Provider. This support includes the addition of a new media type, application/vnd.akana.v2019+json, with the following API enhancements:

• PUT /apis/versions/{ApiVersionID}/oauthdetails is overloaded by content-type
• GET /apis/versions/{ApiVersionID} and GET /apis/services can produce the new content type, meaning that multiple OAuth providers are returned instead of the first found.

This release expands support for the UK OpenBanking v3.1 standard via the JOSE Policy v2, which now verifies the certificate subject DN in the “http://openbanking.org.uk/iss” header.

In the Test Client, additional claim headers can now be added to a JOSE Policy v2, using the new "Claim Headers" section in the Test Client JOSE Policy popup dialog.

For Runtime Configurations, the classifier apiVisibility used to determine the visibility of an API can now be set within the topology definition.

By default, an app version can request a contract with any available API in any available environment. Now, using custom workflow, the Site Admin can limit apps so that when an app has one contract in a specific environment (Sandbox or Live), it cannot have a contract, either with the same API or with another API, in the other environment. With this custom functionality in place, one app version cannot have contracts in both environments.

This option is not part of the default contract workflow, but is available with custom workflow using the custom function verifyAppAccessLimitedToOnlySandboxOrLiveAPIs.

Admin Console: Two new properties, com.soa.database.config:trustStorePassword, and com.soa.database.config:trustStore, have been added to enable encrypted MS-SQL connections.

New automation recipes are now available for users with older Community Manager or Policy Manager instances who need to upgrade to a later version, possibly spanning major or multiple versions. Recipes are available to upgrade from 7.1 through subsequent releases. To learn more, contact your account representative.

A new property, _HTTP result code_, has been added to the following Quality of Services policies: Concurrency Quota Policy, Service Level Enforcement Policy, Throughput Quota Policy, and Timeout Policy.

This property ensures the return of a specific HTTP fault status code for RESTful services.

Site admins can now exclude certain keywords from allowable input data, in order to ensure against cross-site scripting attacks. The selected keyword will be disallowed when validating data for the name, description, and tag fields.

Currently, keywords available for exclusion are: onerror, unload, onmouseover, eval, and mouseout. The keywords are set at the tenant level, and will be expanded over time.

Lifecycle Repository's Runtime Configuration now supports the ability to configure the visibility of APIs that are created. Valid values are Public, Private, and Registered Users. The default is Public, if not specified.

Analysis of the code base and subsequent improvements to remove XSS (Cross-site Scripting) vulnerabilities is ongoing.This release includes extra XSS validations to App, API, Organization, Group, Review, Ticket, Discussion, and Alert pages.

The Akana OAuth/OIDC domain now supports passing a request parameter, a single, self-contained parameter passed as a signed JWT. For Open Banking support, the request JWT consists of two claims, state and openbanking_intent_id.

The request parameter is only applicable to the OAuth 2.0 Authorization Code and Implicit grant types for OAuth providers with UK OB support.

The two claims state and openbanking_intent_id will be included in the JWT Access Token issued by Akana OAuth/OIDC provider.

The platform's embedded JDK 8 has been updated to the latest publicly available release (1.8 u201), dated January 15, 2019, under the Oracle Binary Code License (BCL).

The Test Client has added support for OAuth providers that do not support the registration of a redirect_uri containing query parameters, such as Microsoft Azure.

For JOSE Policy v2 and HTTP Message Validation policies, a new option on the Policy Options page "UK Open Banking" supports the enforcement of OB-formatted error messages returned to the API client application. For OB 3.1 compliance, check the option, then choose “OB version 3.1.”

If the option is unchecked, or checked and “OB version 3.0 and earlier” is selected, error messages are returned in whatever format the policy used before OB 3.1 was introduced.

A new setting in the Business Security settings supports the ability to set the Domain attribute on the Set-Cookie header with the complete hostname of the tenant's incoming URL or the X-Forwarded-Host header.

The JOSE Policy v2 now supports the OB specification 3.1, as well as 3.0 or earlier. The OB rules are enforced based on the version selected in the policy configuration, available on the Policy Options page. If "UK Open Banking" is selected, the version to choose is either 3.1, or 3.0 and earlier.

OB 3.0 and earlier will follow the same rules in terms of crit headers and error messages returned to the API client application.

OB 3.1 enforces:

• the http://openbanking.org.uk/tan header
• the typ claim value to be "JOSE" if it exists
• OB-formatted error messages

Alerts and error log entries are no longer generated by default for authentication challenges, since these are a common part of every Authorization policy. This behavior is supported by two new properties in the Admin Console under the Configuration tab > com.soa.client.subsystems:

The JOSE policy validates that, if a typ claim exists in the JOSE header, that its value is "JOSE," as per the Open Banking 3.x specification. The typ header is optional, so the existence of the claim itself is not enforced.

For Open Banking, if a tan header exists in the JWS header, JOSE validates the header value and that it is present in the crit headers list; JOSE does not enforce that a tan header be defined, however. For OB 3.x compliance, add the tan claim to the policy's configuration page's IN Message Options under "Private Header."

A JOSE policy using the JWKS URL option can now retrieve the certificate to verify the iss header from the JWKS rather than requiring the x5c claim to be in the JWS header. When retrieving the certificate, this order is followed:

1. x5c in the JWS header
2. x5c parameter from the JWKS URL
3. The Consumer's (App) certificate

When using the Test Client to retrieve an OAuth token, the authentication methods now include either a Private Key JWT or Client Secret JWT.

Per the Swagger specification, operations should always contain a response description. In a scenario where an API operation was defined as In Only, errors were generated because the responses property was missing. Now, if the response is not defined, the platform adds a default response.

A new parameter modifier context_path_safe can be used with context parameters such as catalog_asset.group.name to transform the resolved parameter value as follows:

• Removes characters that aren't letters or numbers
• Strips accents from accented characters (e.g., 'é' would become 'e')
• Lowercases remaining characters

For example, using the parameter expression

{catalog_asset.group.name.context_path_safe}

would transform the group name "Nuestra Compañía #1" to "nuestracompania1".

A JWT bearer token can now be signed with either an app's shared secret or a Private Key. A Business Admin can configure the JWT Bearer access token in the developer portal's Admin section under Domains > Add Domains > External OAuth Provider's "Access Token Validation" screen.

Then, in APP OAuth Profile, either a JWT client secret or Private Key can be selected.

• If a client secret is selected, the JWT is verified against the APP secret.
• If a JWT Private Key is selected, the JWT is verified against the Public Key that exists in the JWKS URL from the APP's OAuth profile.

Memory consumption of script policies has been reduced for improved performance. This resulted in the removal of some unused properties in the Admin Console under the configuration com.soa.script.repository and the addition of a new property:

The Jetty NCSA access log now includes the request processing time by default. This setting is configured in the Admin Console under the Configuration tab. Select the com.soa.platform.jettycategory, then the ncsa.access.log.logLatency property. The default value of true includes the request processing time; false omits it from the log.

A new property VersionName has been added to the APIVersionInfo object model so that an API version can be assigned at API creation. If this property is not set, the API is created with the default "v1" version.

The ability to terminate SSL connections for multiple different virtual hosts, enables reduced cost and better operational efficiency for multi-tenant deployments.

The ability to create and search through a library of fully defined services that can be used in orchestrated API calls.

Support for new and enhanced versions of various standards, most notably support for a new version of the JOSE (JSON Object Signing and Encryption) specification as required for UK Open Banking and PSD2.

Management and control over the migration of APIs, apps, policies, processes, and all other associated assets between environments (e.g. development, QA, staging, production)

• Support for MongoDB 3.4 and 3.6 (extending from 3.2 that is currently supported)
• Support for Ping Federate 9
• Support for updated Elasticsearch 6.3.1

Enhancements and ongoing remediation of internal and customer identified vulnerabilities.

Optimization of connection, thread, and memory management. Improved OAuth server performance, optimized monitoring.