Submit support requests and browse self-service resources.
LATEST FEATURES IN AKANA API PLATFORM
GET LATEST RELEASE TRY FOR FREE
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.
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.
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.
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.
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.
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.
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.
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.
Akana adds support for the AWS CloudHSM cloud-based hardware security module. Contact your account executive to get started.
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:
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.
You now have more options and guidance for customizing your API marketplace. Learn more >>
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 Community Manager developer portal include:
Adobe Flash has been replaced in Policy Manager's Real Time and Historical Charts.
This release includes out-of-the-box automation recipes that have been enhanced to support various use cases for configuring security across Akana containers.
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.
Akana has a renewed focus on the Envision product and relaunched it with numerous performance and usability enhancements to the UI and charting capabilities.
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.
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.
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 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:
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:
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:
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:
For example, using the parameter expression
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.
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)
Enhancements and ongoing remediation of internal and customer identified vulnerabilities.
Optimization of connection, thread, and memory management. Improved OAuth server performance, optimized monitoring.