Why you should consider installing AWS’s Open API Framework

In the last decade, much has been said about the adoption of Open APIs strategies. Many companies have tried this strategy and have underestimated the efforts needed to make their APIs public, but before we talk about the challenges of adopting Open APIs, we need to talk about how it has become popular in the daily lives of people and companies.

In the early 2000s, with the expansion of the internet’s reach in the world population, APIs have been the main means of interoperability between systems, whether they are used via browsers or mobile devices. Many companies have become involved in a new market model that makes this information the main asset of this business format. It has become common for companies that start to sell information and discover a new way to monetize within their market niche. However, making an API public in a safe and controlled environment that delivers to its consumer users a technically clear catalog so that they are not consumed, is not a simple or quick process using the traditional forms of technologies that we currently have.

For an Open API to be secure, several aspects need to be considered in its publication and use. We have a wide range of attacks and vulnerabilities constantly appearing on the web. A company that cares about security must consider points such as access policies or credentials that work programmatically, strong encryption algorithms at rest and transport, and anomaly control, among many other points.

Another question, Can Open API can be provided in a free or paid model? In the case of the paid model, there are also relevant considerations regarding how consumption will be charged, how consumers will be identified, and what consumption limits will be imposed..

Considering that the Open API Framework is a solution developed by GFT in partnership with AWS, this automated mechanisms for open APIs has asymmetric encryption, oAuth, mTLS, and web portals that facilitate the journey of the API developer and provider.

This solution provides several benefits:

Manage APIs from multiple AWS accounts simultaneously
Manage APIs from any AWS region
Allows authentication using an automated pool of users or you can integrate it with your Azure AD
Has integrated access control
API consumption billing control
Reactive security mechanisms
Includes mechanisms that meet Open Banking and Open Insurance requirements.

The solution offers two portals for managing and subscribing to APIs. The management portal is responsible for the management and governance of the APIs, the location where the APIs will be made available is defined, who will have access to them, and the amount charged for access. The developer portal is responsible for allowing users to find the APIs available for subscription, or the place where they will get the apps (which are conglomerates of signed APIs), and obtain the necessary approvals and credentials to consuming them.

Management portal

Developer Portal

The Open API Framework is a 100% AWS solution with a low effort curve to adapt to other clouds and technologies. See the architectural model below:

Describing the architecture

In the first step of the solution, right after CloudFormation has been deployed, a serial number and a link are sent to the user.

The generated URL is a portal that was published on S3 and distributed via CloudFront. The serial number was generated during the deployment and stored in an Aurora MySQL database.

Through this URL, the user will be able to finish installing the solution – defining if he wants to add more AWS accounts to manage the APIs, if he would like to authenticate himself in the portals using Azure AD, etc.

After completing the setup session, the solution sends the URLs of the manager and developer portals in the email selected via SNS. Additionally, if the user has chosen authentication without using an Azure AD, an initial username and password are provided.

In the manager portal, which is provided through an S3 bucket and distributed over the internet through CloudFront, the user logs in using Amplify. This authenticates directly to Cognito or federated to Azure AD if the user has chosen this means of authentication.

The information that assembles the permission schema can come directly from the federated account’s Cognito or Azure AD groups.

During the authentication process some information is injected into the token to verify the user’s access permissions.

From that moment on, all API calls (Lambdas) occur through an API Gateway Authorizer that points to the Cognito pool and an API Key that qualifies the originating application.

Within the manager portal, the user can add a new AWS account, where lambda is executed and performs the “trust relationship” process between the accounts. This allows OAF to access API Gateway resources from another AWS account, and if applicable, from regions other than the one where the solution is deployed using the AWS SDK.

The registrations of the solution use the Aurora MySQL database to obtain the credential information in Secrets Manager. Information such as API billing definitions, auxiliary user information, and others are stored.

Through the developer portal, which is provided through an S3 bucket and distributed via CloudFront, users have access to the APIs offered and subscription access. This entire process takes place through the parameters defined in the management portal.

When an API subscription is approved, a set of keys is generated in KMS, an API Key and a temporary password.

To access the signed Rest API we have two methods: 1) Direct access via API Gateway, where the user initially goes through a challenge process through lambda. As soon as the handshake is executed, the user passes through API Key and access to the Signed API. 2) Access via reverse proxy, when invoking the endpoint, Route 53 directs the call to an EC2 machine that contains Nginx with the certificates that were sent in the manager portal. In this way, it validates the access via mtls and, in case of success, directs it to the appropriate API Gateway route and continues the process execution.

Calls to APIs provided by the manager are logged through Kinesis Firehose as Custom Log in API Gateway and bundled into an S3 bucket.

An AWS Glue crawler digests this information and creates the catalog. With this information the manager user can run queries and validate the billing of API calls.

Optionally, the user can use WAF as an additional layer of security for API Gateway calls.

Optionally, the user can use SageMaker to analyze the access data digested by AWS Glue and perform anomaly control or some other ML process. If it is a security process, it can create notifications for the Security Hub.

How do I test / install?

To test the Open API Framework is very simple, just access this page and download the solution. You will receive the download link and the complete solution manual.