See what's new in the latest release of the Akana API Platform.

Full Release Details

New Startup Environment Variable Supports Java Options

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.

JOSE Policy v2 for Open Banking 3.1 Tan Header Now Validates Using Policy Configuration

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.

Support for OpenAPI 3.0 Specification

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.

Model Library

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

Support for Multiple Authentication Policies

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

Support for Multiple OAuth Domains for a Single API

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.

Enhanced Support for Open Banking Version 3.1

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.

Support for Adding Additional JOSE Policy v2 Claim Headers

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.

Lifecycle Coordinator Runtime Configuration: Topologies Can Now Define API Visibility

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

New Custom Workflow Function to Limit Apps to a Single Environment for API Access

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.

New MS SQL Server Encryption Password Properties

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 Support Skipping Major Versions During Multi-Version Upgrades

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.

Policy Manager: New HTTP Status Code Property for Faults Returned on QoS Policies

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.

Admin Portal: Support Added to Disallow Certain Keywords From User Input

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 Runtime Configuration Can Now Configure API Visibility

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.

Stored Cross-site Scripting (XSS) Vulnerabilities Addressed

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.

OAuth Enhancements to Support Additional Parameters Required by UK Open Banking Specification

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.

Oracle JDK 8 Updated to Latest Patch Released January 2019

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

Support Added for a redirect_uri Containing Query Parameters for Some OAuth Providers

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.

Open Banking 3.1 Support for Error Messages for JOSE Policy v2 and HTTP Message Validation Policies

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.

JOSE Policy v2: Support Added for Open Banking Spec 3.x

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:

Authentication Challenge Events Are No Longer Logged as Alerts or in the Error Logs

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:

 

PropertyValue
alert.config.blockedErrorCodesForAlertcom.soa.jbi.JBIErrorCode.BC_BINDING_ERROR_ENCOUNTERED, com.soa.transport.TransportErrorCode.AUTH_CHALLENGE_REQUIRED
alert.config.blockedErrorCodesForLoggingcom.soa.transport.TransportErrorCode.AUTH_CHALLENGE_REQUIRED

JOSE Policy v2 Now Supports the TYP JOSE Header

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.

JOSE Policy v2 Now Validates Open Banking JWS TAN Header

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

JOSE Policy v2 With JWKS URL Option Now Can Verify the ISS Header Using the JWKS

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

OAuth Provider: Test Client Now Supports Validation With a Private Key JWT or Client Secret JWT

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

If Response is Not Defined in the Swagger API Description, the Platform Now Adds a Default Response

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.

Lifecycle Coordinator: New Parameter Modifier to Sanitize Parameter Values For Use in the Context Path of an API

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

External OAuth Provider Domain: Support Added for Signing a JWT Bearer Token With a Private Key

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.

Policy Manager: Script Policy Memory Management Improved

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:

New PropertyDescription
compiled.script.pool.maxScriptsPerLanguageMaximum number of compiled scripts that can be held in memory for a script language
Removed PropertyDescription
compiled.script.pool.maxTotalPerLanguageMaximum number of compiled script engines that can be held in memory for a script language
compiled.script.pool.minIdlePerLanguageMinimum number of compiled script engines, unused but available for future compiled script evaluation
compiled.script.pool.maxIdlePerLanguageMaximum number of compiled script engines, unused but available for future compiled script evaluation

Jetty Transport Configuration in Admin Console Now Includes Request Duration

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.

New Property VersionName Allows an Initial Version at API Creation

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.

SNI in Developer Portal

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

Physical Services in Developer Portal

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

Open Banking Enhancements, Including JOSE Upgrade

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.

Lifecycle Coordinator

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

Software Support

  • 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

Continuing Focus on Security

Enhancements and ongoing remediation of internal and customer identified vulnerabilities.

Scalability and Performance Enhancements

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