Category Archives: Products

Service Discovery with WSO2 API Microgateway

The world is constantly moving towards microservices architectures. A service that is exposed as an API is actually an aggregation of a set of microservices. This approach helps developers to work in parallel since microservices are loosely coupled. As the exposed service is distributed in different server locations, it improves the system’s availability.

However, if consumers are to use microservices as they are, they will have to remember the corresponding IPs of those microservices they need to call; this is inconvenient. From a consumer’s point of view, it would be better to utilize the service as a single component. This is where API management comes into play.

From a developer perspective, going ahead with basic functionality — rather than considering other requirements such as authentication, throttling, etc — is preferred. Developers prefer not to expose their endpoints directly. An API manager is responsible for exposing those endpoints to consumers with these additional requirements.

Let’s consider an example of an online retail store service. It consists of microservices for adding goods to the store, user management, payment management, etc. The owner of this online retail store requires a  fitting way to approach consumers and develop the business efficiently and effectively.

The Traditional API Management Approach

To accommodate both parties’ requirements, we bring the concept of API management, where developers can implement a large service as a set of microservices while consumers see the same service as a single component. In that case, the entire service is exposed to the consumer through the API manager. Then, the API Manager routes traffic to the corresponding microservices.

Figure 1: Routing Traffic under the traditional API management approach for microservices (static IPs)

The API manager should know about all microservices endpoints. Let’s consider a scenario where a user searches for an item. The user sends a request to a URL, which is resolved to the IP of the API manager.

curl -H “Authorization: Bearer ” https://10.10.10.50:9090/myStore/searchItem

Since the API manager knows about the search-microservice and its endpoint (10.10.10.10:8181), the request is redirected to that corresponding IP. Finally, the response received from the microservice is routed back to the user.

When and Where This Traditional Approach Fails, Within the Context of Service Discovery

Today, most companies in the software industry are moving towards cloud platforms such as AWS, google cloud, and Azure. When your services are running in the cloud, you can scale up or down at any moment by utilizing vertical or horizontal scaling processes. You are only charged for the usage of the purchased resources. So, it is important to purchase and utilize in a cost-effective manner. This means you are dealing with a highly dynamic environment, where services can have different server addresses from time to time.

For example, think of a situation where you are running a few services inside a single cluster. However, as traffic increases, you realize that you need to move them to a cluster where more resources are allocated (in terms of CPUs, memory). If you are using a traditional API management approach, you will have to update the API manager separately to route traffic. When there is a large number of services handled by different development teams, it becomes harder to update endpoints manually. Therefore, we need an API management solution where the service discovery is managed by the API manager itself.

So far, our concern has been on a production environment. Now, let’s take a look at a developer environment. With the microservices architecture, developers prefer to identify the service at a more granular level. Thus, the service is composed of a set of microservices. And those microservices can be shared between services. In this kind of environment, you have to accept the fact that the server endpoints are subject to frequent change. To accommodate this, you have to consider whether your API management solution can provide service discovery.

WSO2 API Microgateway with Service Discovery

Now we know that change is inevitable for moving your production environment to the cloud. And we could see how crucial is to have the service discovery as a feature. That is why it is better to go for WSO2 API Microgateway along with etcd. Etcd is a consistent and highly available key-value store. To have service discovery enabled, an API developer provides a relevant key as the endpoint in the openAPI, and then, a microservice developer updates the etcd server with the given key and endpoint address. WSO2 API Microgateway can connect to the provided etcd server, figure out the actual endpoint address, and route the traffic accordingly.

Let’s go back to the previously mentioned scenario. All the microservices are deployed using separate server instances within the cloud. Imagine a case where, for some reason, the server in which the search-microservice runs needs to be moved to a different server instance. With a traditional API Manager, you will have to update the API Manager with the newly assigned IP address. But, if you are using WSO2 API Microgateway, this burden is removed. You can keep running the microgateway as if nothing has changed.

Figure 2: Routing traffic using WSO2 API Microgateway’s Service Discovery

Now, let’s have a look at how this issue is solved in WSO2 API Microgateway. To build the API Microgateway, all we need is the openAPI definition of our online retail store. First, we initialize the microgateway project and add our openAPI definition to the project (For further details, please refer here). Then, we need to edit the openAPI definition. For the “/searchItem” “GET” resource in the Paths object, we need to provide the “x-wso2-production-endpoints” in the following format.

Figure 3: Provide a resource level endpoint using a key

Here, we provide the endpoint URL in the format of “etcd ( <> , <>)”. And the IP address corresponding to the searchItem resource is added to the etcd server as a key-value pair (key = searchItem_etcd_key, value = 10.10.10.10) (Please refer here to gain more insight on how to add/update entries in the etcd server).

Then, we can build the deployable artifact by building the project. After all, we can deploy the microgateway with the command line arguments “-e etcdUrl=http://etcdServerIP: port“.

bash gateway -e etcdUrl 10.10.10.60:2379 -e etcdusername=root -e etcdpassword=pass 

The microgateway resolves the actual endpoint IP address for the given resource using the provided etcd key. Whenever it is required to change the server IP address of the searchItem microservice, all you have to do is update the value of the relevant etcd key (in our case, it is search_etcd_key) in the etcd server. The microgateway will automatically pick the value of the changed etcd key so that the client request will be routed to the corresponding server address without any user intervention. This is basically how service discovery is supported in WSO2 API Microgateway.

In WSO2 API Microgateway, the user also can distribute the load among several backend endpoints. In other words, Microgateway acts as a load balancer for the given service. Or else, backend endpoints can be configured with a regular endpoint and a failover endpoint. You can use these service discovery features along with those backend configurations.

To gain more insight on how to use the service discovery feature, please refer here.

WSO2 Open Banking: Reaching Many Milestones in August 2019

WSO2 Open Banking completed its second anniversary on the 3rd of August. Since its inception, WSO2 Open Banking has set out to do three things: 1) Provide technical efficiency for banks who need to comply with PSD2 and Open Banking, 2) Stay relevant in the wake of the constant changes in the open banking world, and 3) Contribute to the global open banking movement. The latest release of WSO2 Open Banking ticks all three check boxes. This blog discusses each of the above mentioned points and how WSO2 Open Banking helps in more detail.

Support for Global Open Banking Standards

Open Banking API standards have revolutionized how effective API programs can be built for open banking. Open Banking UK API Standard and the NEXTGEN PSD2 API Standard (created by the Berlin Group) are two of the most commonly used standards. The Open Banking UK API standard is globally recognized, with countries like Australia and even some parts of Asia using it as the starting point to build their own specifications.

These API standards release a new version about every 6-8 months. A key priority of WSO2 Open Banking’s roadmap is to stay in line with these API Standards. Why? To help banks using WSO2 Open Banking to easily migrate to the updated versions, without having to spend cycles on implementing version updates themselves. But the benefit is not just for existing customers. Any bank who is looking at using WSO2 has the assurance that the solution’s technical capabilities are in sync with the regulatory demands.

Here are some of the improvements that have come about with this release:

  • Support for the UK v3.1.1 read-write API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.
  • Support for Dynamic Client Registration (DCR) v3.2 – To mandate the mechanism where a Third Party Provider (TPP) client should be able to register with the Account Servicing Payment Service Provider (ASPSP) using DCR.
  • Authorization endpoint support for Berlin API v1.3 NEXTGEN PSD2 API.
  • Transaction Risk Analysis (TRA) to help identify the right conditions to implement strong customer authentication (SCA.)

Meeting the September Deadline for Regulatory Technical Standards (RTS)

By September 14 of this year, all banks in Europe and the UK are expected to have several security measures in place to ensure that customers get to enjoy the benefits of open banking with no security compromises. Having basic identity and access management capabilities do not make the cut for PSD2 compliance and Open Banking. This is one of the key reasons why WSO2 Open Banking has always focused heavily on augmented security capabilities such as strong customer authentication and comprehensive consent management.

As such, this release supports:

  • Electronic Identification, Authentication, and Trust Services (eIDAS) to ensure secure electronic transactions.
  • SCA for electronic payment transactions.
  • Rule-based fraud detection and dashboards for monitoring fraudulent transactions.

Giving Developers the Experiences They Deserve

Much of the interaction between WSO2 Open Banking and a bank’s technical infrastructure is facilitated by the bank’s development team. The following feature implementations will allow a bank’s development team with greater flexibility and creativity when working with WSO2 Open Banking. Some of the developments include:

  • Externally deployable authentication endpoint to allow banks to deploy the authentication endpoint in a separate environment.
  • Extendable consent retrieval and consent persist steps to help banks to conduct their own customizations to the flow seamlessly and elimination duplicated efforts.
  • Transaction Risk Analysis (TRA) implementation has been moved to Open Banking Business Intelligence to help developers easily track and monitor TRA patterns.

More information on the technical capabilities can be found in this blog. If you are interested in getting an even deeper understanding of these features, do register for our webinar.

If you are interested in getting WSO2 involved with your open banking or PSD2 compliance projects, do reach out via our web page. We would love to be a part of your journey.

WSO2 Open Banking 1.4: Support for Global Open Banking Standards

WSO2 Open Banking supports global banks with their PSD2 compliance and open banking journeys. The latest release of WSO2 Open Banking 1.4 meets the technical and regulatory requirements for two global Open Banking API Standards – Open Banking UK API v3.1.1 and NEXTGEN Second Payment Services Directive (PSD2) API v1.3 standards.

This release also focuses on helping European and UK banks meet the requirements of the Regulatory Technical Standards (RTS). The RTS requires banks to have several technical features and standards applied to their Open Banking APIs including Transaction Risk Analysis, eIDAS support, and data reporting among others.

What Can Open Banking Developers and Architects Expect From WSO2 Open Banking 1.4?

Support for Open Banking UK API v3.1.1

Accounts, Payments, and Confirmation of Funds

  • Provide support for the UK v3.1.1 read-write API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.

Dynamic Client Registration DCR v3.2

  • This API mandates the mechanism where a Third Party Provider (TPP) client should be able to register with the Account Servicing Payment Service Provider (ASPSP) using DCR.

Support for Berlin API v1.3

Accounts, Payments, Confirmation of Funds

  • Provide support for the Berlin API v1.3 NEXTGEN PSD2 API standard which mandates how Accounts, Payments, and Confirmation of Funds requests are handled.

Authorization endpoint support

  • Authorization endpoints satisfying the NEXTGEN PSD2 API requirements. This API supports explicit authorization sub-resources and payment cancellation authorization.

Other Features

Transaction Risk Analysis (TRA)

  • TRA for both UK and Berlin specifications. This helps Improve the user experience of exempting strong customer authentication.

eIDAS Support – RTS

Provides support for:

  • eiDAS Qualified website authentication certificate (QWAC) validation in the transport layer.
  • eiDAS Qualified Electronic Seal (QSeal) certificate validation for message signature.

Management Information Reporting for Open Banking UK API standard

  • Data reporting functionality based on UK specification. This data is used to generate reports required by the standard. These reports cover various specification mandated authentication and API statistics.

Ability to restrict PS256 as the signing algorithm for incoming requests which contain signed Json Web Tokens (JWTs) as required by the UK specification.

Fraud Detection Requirements based on RTS. This includes Rule-Based Fraud Detection and dashboards to monitor fraudulent transactions.

An Enhanced User Experience for Open Banking Developers

WSO2 Open Banking 1.4 improves developer interaction with the various technical and regulatory components of the solution through the following:

Swagger based request payload validations – Account and Payment

  • The payload validation is moved to swagger based validations instead of manual validations. This helps increase the effectiveness and completeness of the validations.

Re-architecture of authentication endpoint

Re-architecture of the authentication endpoint to cater to the following requirements:

  • Externally deployable authentication endpoint. This is required when banks want to deploy the authentication endpoint in a separate environment.
  • Extendable consent retrieval and consent persist steps.
    Enables banks to conduct their own customizations to the flow seamlessly without having the need to re-write parts of the authentication flow.

Transaction Risk Analysis (TRA) implementation moved to Open Banking Business Intelligence

  • The TRA implementation which used to function as java based classes, is moved to siddhi (OBBI) as siddhi apps. This increases the efficiency of the TRA component.

OBBI is built with API Analytics incorporated so that OBBI users don’t have to deploy a separate APIM analytics node

Ability to extend key manager extension to add authentication steps based on Strong Customer Authentication (SCA) requirements

  • Different customers use different authentication steps in the authentication process. This feature reduces the effort taken to add an authentication step.

Introducing new REST APIs for operations in WSO2 Open Banking

  • API endpoint to retrieve Third Party Provider (TPP) information.
  • API to retrieve data to be displayed on a consent page.
  • API to persist consent data from a consent page.

In addition to these developments, the solution is now compliant with the OBIE Security Conformance Suite v3.1.0 and Functional Conformance Suite v1.1.17 versions.

Why Choose WSO2 Open Banking?

WSO2 Open Banking is purpose-built to align technology infrastructure and regulatory needs with domain expertise to fully satisfy technology requirements for open banking. The solution roadmap focuses on updates that keeps the solution on par with global Open Banking API standards. This helps banks using WSO2 Open Banking to easily migrate to these newer versions, without having to spend cycles on implementing version updates themselves.

Our webinar about the latest release will take you through an in-depth discussion on how WSO2 Open Banking 1.4 can expedite your compliance journeys and prepare you for the RTS deadline.

Another key advantage WSO2 Open Banking is its flexible architecture that meets technology use cases extending beyond open banking. Built on top of a unified integration platform, it helps banks extend open banking initiatives to any API-first digital initiative.

For more information on how WSO2 Open Banking can help your open banking journey, please visit our landing page.

Looking for more helpful resources? Here they are:

Documentation for WSO2 Open Banking

A Deep Dive of Transaction Risk Analysis for Open Banking and PSD2

Successful Third Party On-boarding for Open Banking UK

Fraud Detection: Making Open Banking a Safer Place

Strong Customer Authentication and Dynamic Linking for PSD2

HTTP/2 Support in WSO2 API Microgateway 3.0.1

WSO2 API Microgateway 3.0.1 supports HTTP/2 allowing you to expose your HTTP/2 services to clients directly via the microgateway, where the client can communicate using either HTTP/1.1 or HTTP/2. It also allows you to expose your HTTP/1.1 service as an HTTP/2 service via the microgateway, allowing clients to communicate via HTTP/2 – making the communication between the client and the microgateway HTTP/2 by keeping the communication between the microgateway and the backend service in HTTP/1.1. All these transformations are supported by WSO2 API Microgateway. This blog discusses use cases and how HTTP/2 can be enabled in the microgateway.

What is HTTP/2?

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web, which is officially standardized as a result of SPDY protocol developed by Google. Refer to (1) and (2) for more details.

Source: https://coolicehost.com/http2-protocol.html

HTTP/1.1 vs. HTTP/2

HTTP/2 is released to address the problems in HTTP/1.1 as explained below:

  • HTTP/2 is binary instead of textual. Binary protocols are more efficient to parse, more compact “on the wire”, and most importantly, they are much less error-prone, compared to textual protocols like HTTP/1.x.
  • HTTP/2 is fully multiplexed instead of ordered and blocking. Multiplexing allows multiple files and requests to be in flight at the same time, as opposed to HTTP/1.1 which only accepted one single request/connection at a time.
  • HTTP/2 uses one TCP connection for parallelism. With HTTP/1.1, browsers open between four and eight connections per origin, and with a single page having multiple origins, it might lead to more than thirty connections opened at a time which in turn causes a huge overhead. HTTP/2 opens one connection between the client and the server to reduce this overhead.
  • HTTP/2 uses header compression to reduce overhead. With HTTP/1.1, it retrieves different resources from the same or multiple web browsers and each request has a collection of headers, and it takes at least 7-8 round trips to get the headers out “on the wire.” In comparison, even mild compression on headers allows those requests to get onto the wire within one round trip.
  • HTTP/2 allows servers to “push” responses proactively into client caches without allowing the client browser to request files when needed.

Main Use Cases of HTTP/2 with WSO2 API Microgateway

The following use cases explains how the WSO2 API Microgateway works when HTTP/2 is enabled. Since HTTP/2 is enabled in WSO2 API Microgateway, when a request is received by the microgateway, it sends the following set of headers along with the request to the backend to determine whether the backend supports HTTP/2 or not.

If the backend supports HTTP/2, it responds to the microgateway with the following set of headers including “HTTP/1.1 101 Switching Protocols” header. Then the microgateway and the backend start communicating via the HTTP/2 protocol.

If the microgateway does not receive the “HTTP/1.1 101 Switching Protocols” header, then it concludes that the backend does not support HTTP/2 and starts communicating with the backend using HTTP/1.1.

Both Client and Backend Supports HTTP/2

In this use case, the HTTP/2 backend service is exposed via WSO2 API Microgateway as a HTTP/2 service and the users/clients communicate with the backend service via HTTP/2 protocol through the microgateway. When a client sends an HTTP/2 request, WSO2 API Microgateway forwards that request to the HTTP/2 backend, including the following HTTP/2 headers to determine the protocol of the connection between WSO2 API Microgateway and the backend.

The backend accepts the request and sends an HTTP/2 response back to WSO2 API Microgateway with the connection upgrade header as well as the “HTTP/1.1 101 Switching Protocols” header. Receiving this header indicates that the backend supports HTTP/2.

As a result, an HTTP/2 connection between WSO2 API Microgateway and the backend is established. Finally the backend sends an HTTP/2 response with the payload to the microgateway, which then forwards that HTTP/2 response back to the client.

The Client Does Not Support HTTP/2 but the Backend Supports HTTP/2

In this use case, the HTTP/2 backend service is exposed via WSO2 API Microgateway as a HTTP/2 service and the users/clients communicate with the backend service via the HTTP/1.1 protocol through the microgateway. When a client sends an HTTP/1.1 request to the WSO2 API Microgateway, this in turn sends the request back to the backend service after including the HTTP/2 headers to determine the protocol of the connection between WSO2 API Microgateway and the backend.

After receiving the request, the backend sends the response back to the microgateway with the following headers indicating that the backend supports HTTP/2.

The backend then sends the response with the payload to the microgateway, which sends the response payload back to the client.

The Client Supports HTTP/2 but the Backend Does Not Support HTTP/2

In this use case, the HTTP/1.1 backend service is exposed via WSO2 API Microgateway and the users/clients communicate with the backend service via HTTP/1.1 or HTTP/2 protocols through the microgateway. When a client sends a request to the microgateway, it sends the request back to the backend including the following headers to determine whether the backend supports HTTP/2.

Since the backend does not support HTTP/2, it does not reply back with the expected “HTTP/1.1 101 Switching Protocols” header; and that notifies the Microgateway that the backend does not support HTTP/2. Then the backend starts communicating with the backend via the HTTP/1.1 protocol and after receiving the response payload from the backend, the microgateway forwards the response payload back to the client.

Since the microgateway uses a keep-alive connection when communicating with the backend server, it sends the following request headers to the backend to determine whether the backend supports HTTP/2 in the initial request in the same connection only. If you send the same request repeatedly, you will not see the particular headers as the microgateway already knows of the backend supported protocol.

Prerequisites

Download and setup WSO2 API Microgateway 3.0.1 as explained in (3).

How to Enable HTTP/2 in WSO2 API Microgateway 3.0.1

Enable HTTP/2 in a Docker Setup

  • Create a microgateway project.
  • Navigate to a preferred workspace folder using the command line. This location is used to run the microgateway commands and to generate microgateway artifacts.
  • Create a project using the command given below:
  • micro-gw init 
    micro-gw init petstore
  • Add the API (open API definition) to the project. Navigate to the /petstore/api_definitions directory and add the API definition(s) to this directory. A sample open API definition can be found here.
  • Build the microgateway distribution for the project using the following command:
  • micro-gw build 
    micro-gw build petstore
  • After the above command is executed, an executable file ( /petstore/target/petstore.balx ) is created to expose the API via WSO2 API Microgateway.
  • Navigate to the <MGW-TOOLKIT-HOME>/resources /conf folder and open the micro-gw.conf file.
  • Locate the (http2) tag in the file and change the enabled value to true.
  • [http2]
    enable=true
  • Run the Microgateway Docker runtime mounting executable file (petstore.balx) and the config file (micro-gw.conf).
  • Now the petstore API is exposed using WSO2 API Microgateway.
  • Invoke the petstore API using a valid JWT token.

Enable HTTP/2 in a VM Setup

  • Create a microgateway project.
  • Navigate to a preferred workspace folder using the command line. This location is used to run the microgateway commands and to generate microgateway artifacts.
  • Create a project using the command given below:
  • micro-gw init 
    micro-gw init petstore
  • Add the API (open API definition) to the project. Navigate to the /petstore/api_definitions directory and add the API definition(s) to this directory. A sample open API definition can be found here.
  • Build the microgateway distribution for the project using the following command:
  • micro-gw build 
    micro-gw build petstore
  • After the above command is executed, an executable file (/petstore/target/petstore.balx) is created to expose the API via WSO2 API Microgateway.
  • Navigate to the <MGW-RUNTME-HOME>/resources /conf folder and open the micro-gw.conf file.
  • Locate the (http2) tag in the file and change the enabled value to true.
  • (http2)
    enable=true
  • Run the Microgateway Runtime mounting executable file (petstore.balx) by navigating to the /bin directory.
  • bash gateway //petstore/target/petstore.balx

Summary

To summarize, WSO2 API Microgateway 3.0.1 allows users to use either HTTP/2 or HTTP/1.0 by supporting multiple transformations. It can expose an HTTP/2 backend service directly to end-users and let them call the service via either HTTP/1.0 or HTTP/2. An HTTP/1.0 backend service can also be exposed as an HTTP/2 backend service letting end-users to invoke via HTTP/2 requests.

Learn more about WSO2 API Microgateway here.

Reference

(1) https://http2.github.io/faq/

(2) https://developers.google.com/web/fundamentals/performance/http2/

(3) https://docs.wso2.com/display/MG301/Quick+Start+Guide

Australia Passes Consumer Data Right Legislation. It’s Go Time for Open Banking!

Photo credits: Catarina Sousa via Pexels

After much anticipation, the Consumer Data Right Legislation is finally passed! Just after a month since the original open banking deadline for the Big 4, the real race begins. It’s time for banks to lay out their open banking playbooks and start implementing open APIs.

A Quick Overview of the Timelines

Even before you consider the technical aspects of open banking, you should understand the regulation. Our article answers some common questions around open banking in Australia. A summary of the approaching deadlines is included below:

  • February 2020: Credit and debit card, mortgage, deposit, and transaction data by the Big 4 banks
  • July 2020: Account data for all banks aside of the Big 4
  • February 2021 for mortgage data: Account data for all banks aside of the Big 4
  • July 2021 for all other products

How to Get Started

With less than a year to go, banks have a lot of prep work to do. Here are a few simple steps to kick start your technology implementation for open banking:

Create open banking evangelists: Even if it is just 3 people, it is important that there is a part of your organization that lives and breathes open banking. That way, they align every aspect of the business – customer value, profitability, and even vision towards a pro open banking model.

Budget for efficiency: Open banking doesn’t have to cut through a hole in your annual budget. An efficient open banking implementation is one that will not cost you a ton of money. And in order to budget for efficiency, always think about what you can re-use and re-purpose. As banks, most of the technology required for open banking should already be within reach. What matters is how you adapt it to fit open banking specific needs. Our article has more details.

Evaluate existing technology: Open banking does not require you to reinvent the wheel. You would already have banking APIs and data security mechanisms in place, and most of it can be modernized to fit open banking requirements. Our white paper covers this in detail. You just need to identify the gaps. And pay close attention to security. Features like customer authentication and consent management are crucial to the success of open banking.

Fill out the missing pieces: This is where you get creative. Once you know what is missing, always look at working with technology that is easy to integrate with current systems (so it doesn’t take much time), meets open banking specific customizations (so your teams don’t have to spend cycles implementing them), and finally invest in technology that gives you the flexibility to scale as you go. That way, you lower the risk in the technology investments that you make.

Test like your life depends on it: Once your open API environment is set up, make sure to test all of the functionalities are meeting requirements. When testing, think like a data recipient and envision the experience you want them to have. Remember, the better your API portal, the more data recipients you attract and the better you serve your customers.

We are excited to participate in the open banking journey in Australia and we are keen to share our experiences with banks like Société Générale with you. If you are just starting your open banking implementation or have made progress but need more technical or regulatory guidance, do get in touch with us.

Everything you need to know about WSO2 Open Banking is here.

WSO2 API Microgateway: Mutual SSL and Open API Security

Introduction

Security is not an afterthought, it is an integral part of any project. Moreover, an API is an interface where internal and external users can expose business information. The information might be medical, financial, business, or sensitive personal data. Allowing users to access APIs helps expand the business and compete with global vendors. But the internet is not a nice place and you might not have the luxury of exposing expensive details in public without any security mechanism or control. Hackers are on the lookout for emerging vulnerable pipes.

A gateway acts as the major point of enforcement for the API traffic and it will allow users to authenticate the traffic as well. WSO2 API Microgateway is a lightweight proxy to the APIs and a significant component for managing microservices architecture from the API perspective. A microservice is a target individual task and a set of microservices is composed to handle multiple tasks in a collaborative manner through network calls among each component. While each component is handling its individual tasks, the microgateway is used to govern individual API calls. If each individual microservice implements its own security mechanisms, it will duplicate and increase the maintainability issues. But WSO2 API Microgateway enforces standard security mechanisms across all microservices.

Security is an evolving concept which has been there for decades and there are two main factors:

  1. Authentication – validation of credentials and verification of identity
  2. Authorization – verification of a user’s rights to grant him/her access to resources

Let’s see how WSO2 API Microgateway supports the main security factors.

Mutual SSL (Certificate-based Authentication)

From an authentication perspective, a common practice in relatively large organizations is to secure their internal APIs using SSL key pairs issued by their own private CAs. This is where the mutual SSL comes into action. In fact, mutual SSL authenticates two parties through verifying the provided digital certificate so that both parties are assured of the other’s identity. WSO2 API Microgateway supports mutual SSL as an authentication mechanism.

Example scenario

Let’s see how we can achieve this requirement.

  1. Create the CoffeeBar using the command given below.
  2. Micro-gw init CoffeeBar

  3. Add the API to the CoffeeBar project by adding a Swagger file (.yaml or .json) to the
    CoffeeBar/api_definitions folder. A sample open API definition can be found here.
  4. Build the microgateway distribution for the project.
  5. Micro-gw build CoffeeBar

    Note: Once the particular build command is executed, an executable file (/CoffeBar/target/coffeebar.balx) is created to expose the API via WSO2 API Microgateway.

  6. Then we should enable the SSL authentication through the microgateway configuration file, micro-gw.conf.
  7. Note: If you have been working on kubernetes/docker environment, you should enable the SSL authentication in /resources/conf/micro-gw.conf. or else if you have been working locally, you should enable the property in /conf/micro-gw.conf file.

    A sample configuration in micro-gw.conf is shown below:

  8. Default sslVerifyClient is set to “optional. That said, if the mutual SSL authentication has succeeded, OAuth authentication is skipped. If you set it as “require”, the mutual SSL becomes exclusive. If it fails, you will get an unauthorized(401) error.
  9. Then, configure the trust store and change “trustStore.path” property and “trustStore.password” property under “[listenerConfig]” instance ID. The truststore should have the certificate which is used to create SSL connections.
  10. Now, let’s run the microgateway docker runtime mounting executable file(coffeebar.balx).

Format:

docker run -d -v :/home/exec/ -p 9095:9095 -p 9090:9090 -e project="project-name" 
 - The path of the target directory created inside the project directory

Sample:

docker run -d -v /wso2am-micro-gw-toolkit/bin/coffeebar/target:/home/exec/ -p 9095:9095 -p 9090:9090 -e project="coffebar"  wso2/wso2micro-gw:3.0.1

In order to successfully complete the SSL handshake, the public certificate of the WSO2 API Microgateway has to be imported to the trust store of the client and the public certificate of the client has to be imported to the ballerinaTruststore.p12.ballerina trust store which resides in the Micro-gw-runtime-home/runtime/bre/security folder.

In the example discussed in this blog, a self-signed certificate is added into the already available ballerina trust-store and the same certificate is imported into the client application. Let’s see how to import server certs to Navigate to the browser’s certificate management section. On Firefox, navigate to Preferences > Privacy & Security > Certificates.

Figure 2

Add the certificate to the client.

Figure 3

Invoke the REST API using a REST API client from the browser.

Figure 4

The browser will present a user identification request, to select a certificate in order to use for the SSL connection. Select the certificate you added and click OK.

Figure 5

If you don’t import certificates properly, you will see the following error message:

curl: (35) error:1401E412:SSL routines:CONNECT_CR_FINISHED:sslv3 alert bad certificate

Open API Security

When organizations expose business services via an API-driven model, these services are exposed to both internal and external parties. Since an organization cannot expose all the services of an API to the public, they need to restrict access to the most valuable services only to authorized parties.

If revenue is generated by exposing APIs, it’s important to make sure that only authorized parties have access to the respective resources. In this scenario, securing APIs is an important task because unauthorized access to resources will affect revenue and eventually have a negative impact on the organization. Even though it may seem difficult to do, it’s mandatory to have a security solution that can facilitate fine-grained access control to every resource of an API.

WSO2 API Microgateway supports security schemas keyword in OPEN API definition to restrict the authorization per resource and at the API level.

Example scenario

Here is an example that explains the use of scopes via a real-world example. Let’s take API called CoffeebarAPI to handle some operations in a coffee stole. This API can be used to add, update orders, and view the menu. Each resource is authorized through the scope and the token which has the particular scope only can invoke the particular API resource.To consume the API, you will need to obtain an access token with relevant scope otherwise you will encounter the unauthorized(401) issue.

The gateway supports the “securitySchemes” keyword in open API specifications. There are four types of security schemas in the open API specification – API key, HTTP, OAuth2, and OpenID Connect.

Most of the users tightly bond with OAuth2 authentication. But you may have several APIs that are exposed by WSO2 API Microgateway. All of them are secured with OAuth2 by default. But there may be a requirement for one API and it must be secured with basic auth. This means you simply use the username and password for authentication.

WSO2 API Microgateway currently supports OAuth2 and basic authentication under HTTP for APIs which can be defined via open API extensions. If none of the security schemes is defined, the gateway by default applies OAuth2 security.

You can refer to a sample configuration for OAuth2 and basic support below. This is how we define the security schema in the Swagger definition.

Figure 6

OAuth Authentication

Let’s now see how we can try out the OAuth authentication type. You can refer to a sample configuration which depicts how you can refer the OAuth security schema in the resource level.

Figure 7

You can find a sample Swagger file here. Let’s see how to apply the security schemas to our use case. The table below lists the mapping between scopes and resource.

Scope Resource
read:menu GET /menu
write:order, read:order POST /order
write:order, read:order GET /order/{orderId}
admin POST /menu

The user needs to obtain an access token to consume the respective resource. A scope allows you to specify what type of access is specifically required per resource. The scope of an access token defines what the access token can do and what resources it can access. In other words, the scope will add some limitations for the OAuth tokens.

Then you can move to consuming APIs according to the necessity of the user. Let’s try to consume a GET /menu resource by a JWT token which is not contained required scopes.

In the microgateway ecosystem, users can use third-party key managers to obtain an access token. In this sample use case, I used Auth0 as an identity provider and generate 4 types of jwt tokens to depict the scenario.

Token type Token name
Token without scopes TOKEN_A
Token with write:order, read:order scopes TOKEN_B
Token with read: menu scopes TOKEN_C
Token with admin scope TOKEN_D

TOKEN_A

Try to invoke the POST /order resource from the TOKEN_A. The user can’t access the resource without having the write: order and read: order and he/she will get the following error message.

{"fault":{"code":900910, "message":"The access token does not allow you to access the requested resource", "description":"The access token does not allow you to access the requested resource"}}

TOKEN_B

Try to invoke all the resource but user can only invoke POST /order and GET /order/{orderId}

TOKEN_C

User can only consume the resource GET /menu resource.

TOKEN_D

User can only consume POST /menu resource.

Basic Authentication

Developers can define the basic OAuth under “securitySchemes” as in figure 6 so that he/she can refer to the particular security schema under the resource as shown below.

Figure 10

Now you can access the GET /order/{orderID} resource through basic auth. But where can you define the username and password? You can use micro-gw.conf file to define a username and password.

Note: If your project is deployed in a Kubernetes or docker environment, you should do all the configs in /resources/conf/micro-gw.conf file or else if you have been working locally, you should enable the property in the /conf/micro-gw.conf file.

You can refer to a sample config here:

Username: generalUser1

Password : password

Figure 11

Passwords are sensitive and it should be encoded in sha1 as shown above. Now all the configurations are completed. You can build the project and try out the basic authentication by using the following curl command:

Curl -X GET "http://localhost:9090/coffeebar/v1/order/1" -H "Authorization: Basic "

Summary

API security has come a long way from where it started and it has a long way to go. This blog focused on how the microgateway has been layering security over individual services. We discussed mutual SSL/certificate-based authentication and Open API security schemas. This blog also depicted how scopes can be used when consuming the resources of an API.

Click here to learn more about WSO2 API Microgateway.

The Basics of Open Banking

Open banking has grown overnight. It started with the PSD2 regulation for Europe in 2018. Open banking is now adopted in Australia, several parts of Asia, Latin America, and many other regions.

Here are a few facts to understand what open banking is and why you should consider building a strategy around it.

What is Open Banking and Why Was It Created?

Open banking requires all financial institutions (deposit taking institutions) to open up customer and/or payment data to third party providers. Open banking breaks up the monopolies of financial services and allows more players to enter the market. This increases competition and results in better products and services for customers.

As time went on, non regulated regions started to accept that open banking was the best way to become more digitally agile. Therefore, they started taking measures to open up their APIs. Regions like Mexico are looking at open banking for larger financial inclusion agendas.

How Does Open Banking Work?

The “opening up” of this data is done via Application Programming Interfaces (APIs). APIs, which are essentially an integral part of any technology infrastructure, provide a secure and effective way to expose this data. In the past, banks have used screen scraping to expose data. This comes with a compromise on security with a high chance for fraudulent transactions.

How is Data Protected in Open Banking?

Security is of utmost importance in open banking. While security at an API management level is essential, banks must take extra steps to ensure that data does not fall into the wrong hands. Mechanisms like Strong Customer Authentication (SCA) and Consent Management are vital. SCA ensures that a two step authentication mechanism is followed, but without hindrance to user experience.

Consent management puts the user in control of who they share their data with. When you implement identity and access management for open banking, these two elements should be a top priority. It also helps to have fraud detection mechanisms in place, as a way of identifying fraudulent transactions.

Are There Technology Standards to Meet?

Since the APIs used for open banking need to follow certain protocols and adhere to specific requirements, there are a few open banking API standards available. Open Banking UK API Standard, the NEXTGEN PSD2 API Standard (created by the Berlin Group), and the STET API specification are three of the most commonly used standards.

How Do You Integrate an Open Banking Architecture with a Legacy System?

One of the biggest challenges banks face is bringing together what seems to be two different worlds — open API architectures and legacy systems. In reality, it doesn’t have to be so difficult. The first thing to do is to add an integration layer which will mediate between the legacy system and Open APIs. This allows you to expose the required services to the open banking solution, which will in turn expose them as APIs with the required security measures in place. More details are available in this white paper.

Why an Open Banking Vision is Important

The availability of data and various methods to compare and contrast services create high expectations for consumers.This means banks need to go the distance — being a supporter of a person’s financial ecosystem is not enough. They need to think about improving consumer lifestyles too.

Open banking is the best way to start this journey. The openness it creates gives way to a tremendous amount of data. This data helps you understand how your consumers, eat, shop, travel, and more. With more players in the financial services ecosystem, banks should aim for collaboration over competition.

These collaborations can go a long way in delivering superior products and services to customers, and helping your bank identify as a true contributor to consumer well being.

In conclusion, open banking is here to stay. So regardless of what the regulatory status is, banks need to be proactive about open banking and make it a boardroom topic. The sooner you start, the better placed you are when it reaches your region.

WSO2 API Microgateway: Dealing with Revoked JWT Tokens

WSO2 API Micorgateway is a cloud native API Gateway which can be used to expose one or many microservices as APIs. It applies the common quality of service attributes on API requests such as security, rate limiting, and analytics; and also offers a wide range of features which help organizations to deploy APIs to microservice architectures efficiently.

It supports authentication and authorization for API requests in following forms:

  • OAuth2
  • Basic Auth
  • Mutual TLS

OAuth2

OAuth2 tokens can be self contained in JWT format or opaque by specification. WSO2 API Microgateway supports both of these formats:

  • Opaque (An external service validates the token)
  • Self contained in JWT format (The token itself is sufficient to check its validity)

Token Revocation

For opaque OAuth2 tokens, revocation is achieved by marking the token as invalid at the validation service (usually it is the STS). Since the gateway communicates with the validation service to authenticate a request, the gateway can be made aware of a revoked token as soon as it is revoked (assuming there is no caching). However, for self contained tokens, revocation is not straightforward due to the fact that there is no communication with an external service for validation. Hence the task becomes challenging.

When WSO2 Microgateway 2.6 was released back in September 2018, numerous questions were raised by the community regarding JWT token revocation. Back then, there was no direct solution for this and our suggestion was to mitigate the risk of a stolen token by using small expiry times during token generation. However, with the latest release of WSO2 Microgateway 3.0.1, we have introduced a solution. The product has been redesigned cleverly to facilitate a messaging system to revoke JWT tokens, starting from this release.

In this blog, we will discuss two mechanisms for token revocation and guide you through the steps needed to configure your environment to test this feature. You do not need any WSO2 specific components running apart from the microgateways for this.

Listed below are the two methods of token revocation introduced in this release:

  • Real-time non-persistent
  • Non-real-time persistent

WSO2 API Microgateway can be configured to enable either one or both methods at the same time. The following table illustrates the behavior of token revocation depending on whether each of them is enabled or disabled.

Real-time non-persistent Non real-time persistent Behavior
Enabled Disabled Token revocations will be reflected in real-time. If the microgateway is restarted, the revoked token will be treated as valid from there onward.
Disabled Enabled Token revocations will be persisted in etcd and will not be reflected in real-time. Microgateways will fetch revoked token information only during startup. Even if microgateways are restarted, the tokens will still be treated as invalid.
Enabled Enabled Token revocations will be reflected in real-time. Even if the microgateways are restarted, tokens will still be treated as invalid.

Real-time Non-persistent

This method, as suggested in the heading, is non-persistent. A revoked token will still continue to work if the microgateway is restarted since there is no involvement of a persistence mechanism.

Once a token is revoked at the STS, the STS is responsible to push a message to a JMS topic with the JTI of the revoked token. Microgateways will be listening to this topic and updating an in-memory map with the revoked token JTIs.

When a request reaches a microgateway, it checks whether the JTI of the token is in its in-memory map. If it exists, the requests will be blocked and otherwise, it will proceed to the backend. Since the in-memory information will be lost after a restart, a revoked token will be validated successfully upon a restart. In addition to this, a newly spawned microgateway will not be able to fetch the revoked token information since the topics are not durable – only the microgateways which have subscribed to the topic at the moment of revocation will receive the information.

Demo

Prerequisites

  1. WSO2 API Microgateway runtime with an API hosted in it.
  2. A valid JWT token to invoke the API mentioned in 1. This token can be generated via WSO2 API Manager’s token endpoint or an external STS of your choice. Make sure that you are able to invoke the API in the microgateway using this token.
  3. A JMS broker to host the token revocation topic.

Configure the broker

I’ll be using Apache ActiveMQ 5.15.8 as the broker for this example. You can use any broker which supports the JMS specification. Do note that instructions may slightly change depending on the type of broker you use.

  1. Download Apache ActiveMQ 5.15.8 from here and extract it in the filesystem.
  2. Go to the bin directory and execute ‘./activemq start’. This will start activemq server and will listen in various ports for various protocols. The default TCP port is 61616.
  3. Open up your browser and head to http://localhost:8161/admin. This will present you the ActiveMQ web console which we will be using to create a topic. Use admin as the username and password for authentication.
  4. Click on ‘Topics’ on the top menu.
  5. A button will be available to create a topic with the provided name in the corresponding textfield. Create a topic with the name tokenRevocation.

Configure the microgateway to subscribe to the broker Topic

  1. Open micro-gw.conf file in the microgateway runtime.
  2. Scroll down to the tokenRevocationConfig.realtime section and change the configs as follows and save it. Notice the sections in bold which have been changed from the default configuration values. Also note that the following values are specific to ActiveMQ and will be different for any other broker type.
  3. [tokenRevocationConfig.realtime]
        enableRealtimeMessageRetrieval = true
        jmsConnectionTopic = "tokenRevocation"
        jmsConnectioninitialContextFactory = "org.apache.activemq.jndi.ActiveMQInitialContextFactory"
        jmsConnectionProviderUrl= "tcp://localhost:61616"
        jmsConnectionUsername = "admin"
        jmsConnectionPassword = "admin"
  4. Since we have configured ActiveMQ specific jmsConnectioninitialContextFactory we need to provide the relevant client implementation to the microgateway runtime. Therefore copy the following files from the ActiveMQ distribution in {ACTIVEMQ_HOME/}/lib to {MGW_HOME}/runtime/lib directory.
    • activemq-client-5.15.9.jar
    • geronimo-j2ee-management_1.1_spec-1.0.1.jar
  5. Start the microgateway by executing {MGW_HOME}/gateway . If all the configs are in place microgateway logs should print as follows during startup.
  6. INFO [wso2/gateway] – [TokenRevocationJMS] [-] subscriber service for token revocation is started

Testing by revoking a token

  1. Decode the JWT token you need to revoke and copy the value for the jti key in it.
  2. We will be interacting with the ActiveMQ REST API in order to push a message to the tokenRevocation topic. In order to revoke the above JWT token, execute the following curl command in a terminal:
  3. curl -X POST -d 'revokedToken=795c8a79-30ac-4a56-8474-7dd4f4d9551c&ttl=10000' "http://admin:admin@localhost:8161/api/message/tokenRevocation" -v
  4. Try executing the API in your microgateway with the JWT token corresponding to the above JTI. The API call should fail with an error as follows:
  5. {"fault":{"code":900901, "message":"Invalid Credentials", "description":"Invalid Credentials. Make sure you have given the correct access token"}}

Non Real-time Persistent

As opposed to the previous method, this mechanism involves persistence. This means that a revoked token will still continue to be blocked by all the microgateways, even across microgateway restarts. However, the revoked token information will be fetched by the gateways only during the startup. Therefore revocation is not real-time.

The STS is responsible to push a message with a suitable TTL (time to live) value to the etcd server upon a token revocation. Microgateways will fetch the revoked token JTIs from etcd on each startup. Once the TTL exceeds, etcd will automatically remove the corresponding tokens. By specifying a TTL value which slightly exceeds the expiry time of the token, etcd can be optimized to not store expired revoked tokens. In addition to the existing microgateways, if new microgateways are added to the deployment, all of them will still be able to fetch all revoked token information stored in etcd.

The default implementation for this uses etcd as the persistence layer to fetch data during the startup. If needed this can be customized to use a different method other than etcd. In such cases, the STS should push the message to the relevant persistence layer instead of etcd.

Demo

Prerequisites

  1. WSO2 API Microgateway runtime with an API hosted in it.
  2. A valid JWT token to invoke the API mentioned in 1. This token can be generated via WSO2 API Manager’s token endpoint or an external STS of your choice. Make sure that you are able to invoke the API in the microgateway using this token.
  3. Etcd server downloaded. For demo purposes we will be using etcd 3.3.13.
  4. Disable tokenRevocationConfig.realtime configs, if you have already enabled them when you tried out real-time revocation.

Configure etcd server

  1. Start the etcd server by executing the etcd command in the terminal. This will spin up a single node etcd server ready to serve requests via http://localhost:2379.
  2. Execute the following command in the terminal. This command creates a key value pair in etcd where the key is 25e0360d-e20b-44fd-b149-675243bbd994 and this value can be any string. The ttl is set to 3600s. This means after 1 hour etcd will automatically remove the key. Make sure you pass the correct JTI for the token you need to revoke (etcdctl is a command line client to interact with etcd service.)
  3. etcdctl mk 25e0360d-e20b-44fd-b149-675243bbd994  --ttl 3600
  4. Execute the following to check whether the above key has been saved in the server properly. This should print an output with the corresponding value for the key.
  5. etcdctl get 25e0360d-e20b-44fd-b149-675243bbd994

Configure the microgateway

  1. Open micro-gw.conf file in the microgateway runtime.
  2. Scroll down to the tokenRevocationConfig.persistent section and change the configurations as follows and save it. Notice the sections in bold which have been changed from the default configuration values. Keep the username and password fields empty as we have not enabled authentication with the etcd service.
  3. [tokenRevocationConfig.persistent]
          enablePersistentStorageRetrieval = true
          useDefault = true
          hostname = "http://127.0.0.1:2379/v2/keys"
          username = ""
          password = ""
  4. Start the microgateway. This should print a log as follows:
  5. INFO  [wso2/gateway] - [EtcdUtil] [-] One time ETCD revoked token retriever task initiated
  6. Try calling the microgateway API with the JWT token corresponding to the JTI which you revoked. API call should fail with the following error:
  7. {"fault":{"code":900901, "message":"Invalid Credentials", "description":"Invalid Credentials. Make sure you have given the correct access token"}}
  8. Restart the microgateway and perform the API call once more. Notice that the revoked token is being blocked even after the restart.
  9. Try generating a new JWT token and revoking it while the microgateway is running. Notice that API calls with the new token will continue to work until restarted. This is the reason why this method is ‘non-real-time’.

Summary

This blog discusses how WSO2 API Microgateway deals with revoked JWT tokens. There are mainly two ways to achieve this, but you can enable both modes for a hybrid approach if required. This will provide you with the capability to revoke a token in real-time and additionally to persist the revoked tokens so that this information will not be lost if the microgateways are restarted.

Learn more about WSO2 API Microgateway here.

WSO2 API Microgateway 3.0 is Released

The WSO2 API Manager team recently released version 3.0 of its WSO2 API Microgateway. This blog takes a closer look at the key attributes of a microgateway, changes in the new release, new features available, use cases of microgateway, and what to expect in the future from WSO2 API Microgateway.

Key Attributes

Cloud native

  • Comes as lightweight containers (fast boot-up times, low memory footprint, and low distribution size
  • Designed in a stateless manner
  • Isolated from underlying system/OS
  • Can be deployed on self-service, elastic, and cloud infrastructure
  • Agile DevOps and CI/CD
  • Automated capabilities for deployment
  • Developed with frameworks suited for cloud (based on Ballerina)

Developer-centric and enables the following:

  • Creation of microservices
  • Define the open API definition for microservices
  • Initiate the microgateway project from the open API definition
  • Build the microgateway project
  • Locally test the service exposed via microgateway

Decentralized

  • Decentralized per API gateway, with a dedicated gateway for each service
  • Contains a private jet gateway, with a dedicated gateway for clusters of same microservices
  • Contains sidecar gateways, gateways that are deployed in the same node with microservices
  • A gateway for subset of APIs only, to expose several services/APIs using a single API

Immutability

  • Rebuild required if API changes, new resource added
  • Finalize open API definitions prior to deploying
  • Immutable containers
  • Immutable runtime artifacts for non containerized runtimes

Scalability

  • Serves traffic independently (acts without key manager with self contained tokens, local rate limiting capabilities, and stores analytics data)
  • Independent scaling sans the need to scale other components
  • Can be scaled with microservices when used as private jet or side car mode
  • Inbuilt support for container orchestration tools to manage scaling

What Has Changed in the New Release?

1. Introduction of a developer-first approach

The 2.x series of WSO2 API Microgateway depended on the WSO2 API Manager publisher portal when designing APIs to be exposed via the microgateway. WSO2 API Microgateway 3.0 takes a developer-first approach. The API developer who is designing APIs and defining the interfaces of the APIs is now able to develop a microgateway based on the interface of his/her APIs.

In this new version, the microgateway toolkit will accept a valid open API definition of developer services or microservices, with WSO2 specific open API extensions. Then the toolkit will translate this open API definition into an executable format which is accepted by the microgateway runtime component. Once the API developer adds WSO2 specific open API extensions to the open API definition of the microservices, microgateway will add QoS like authentication, authorization, rate limiting, transformations, analytics, etc.

2. Separation of toolkit and runtime into two distributions

The 2.x series of WSO2 API Microgateway had a single distribution where both toolkit and runtime resided. The toolkit created runtime distribution for the user, containing all the APIs which the user had to add to the project. This has changed in WSO2 API Microgateway 3.0, which has two separate distributions, one for the toolkit and the other for the runtime. I’ve explained this in detail in the section below.

  • Microgateway toolkit

Microgateway toolkit is a command line tool designed for API developers to create micro gateway projects by adding open API definitions. This cli creates a project structure for the API developer once the project is initiated. If the API developer has a single open API definition or multiple open API definitions, these can be copied to this newly created project. Once the project is finalized, the cli can be used to build this project which will create an executable file that is accepted by the microgateway runtime.

  • Microgateway runtime

This is the component which actually serves the API requests. Runtime component cannot be run without providing the output created by the toolkit. The runtime component can be dowloaded as a zip file or as a docker image. When using a zip file, the executable file created by this toolkit should be provided as an input argument for the startup scripts of the runtime. When using the docker image, the executable file should be mounted into the docker container.

You can refer to the quick start guide to expose your first API with microgateway in a few steps here:

New Features

Define per resource endpoints

In the microservices world, developers might want to expose their microservices as APIs to the outside world. The API developer will define an interface of these services using open API definitions. Several microservices will be contained in a single open API definition which defines a single API for a particular use case (for example, online store). So when defining the microservices in the open API definition as REST resources, users should be able to define different back ends based on the resource.

Open API extension (“x-wso2-production-endpoints”, “x-wso2-sandbox-endpoints”) introduced by WSO2 enables users to define back end services at the resource level. This way, users can logically collect his microservices into a single API and these can be exposed via the microgateway. Refer to the documentation here.

HTTP2 support

WSO2 API Microgateway is upgraded to support HTTP/2 together with HTTP/1.1 as the incoming and outgoing transport protocol. WSO2 API Microgateway is able to process requests faster and simpler with HTTP/2 enablement. For more information on HTTP/2 and its benefits, refer to the HTTP/2 homepage. It supports both client -> gateway and gateway -> back end communication using http2. Refer to the documentation here.

Mutual SSL based authentication

Microgateway is enabled to serve requests from trusted clients without providing OAuth2 tokens. After sharing the certificates of the trusted client partners are, requests from these trusted certificates will be served. Microgateway can impose the mutual ssl as required or as optional. If required, then requests from only trusted clients will be served, and if it is optional, the trusted client will be served without OAuth2 tokens and untrusted clients (the client who has not shared their public certificates) will need a valid OAuth2 token.

Config based basic authentication support

Microgateway allows users to invoke APIs using their basic authentication credentials, apart from OAuth2 tokens as well. The basic authentication support can be defined per API using the open API definition. Microgateway supports the open API security schemes in order to define the basic authentication for the APIs. Refer to the documentation here.

Response and request schema validation

Microgateway can intercept responses and requests, and validate these against the models defined in the open API definition. Microgateway stores the open API definitions added to the microgateway project and cross check the request and response payloads against the schema models defined in the open API definitions. Refer to the documentation here.

Service discovery with ETCD

One challenge we face with microservices architecture is that the services are dynamic. Services do not have a fixed connection url, it changes with time, and are mostly maintained in a ETCD server as a key value pair. Since microgateway is immutable, it should be able to route traffic to these dynamics endpoints without having to rebuild. Connecting with the ETCD server and resolving dynamic micro services urls in real time are both supported by the microgateway. Refer to the documentation here.

Global throttling

Up to date, the microgateway was able to perform the rate limiting locally using memory. Each gateway maintained its own set of counters and throttling decision were taken in an independent manner. With this new release, the microgateway enables the publication of throttle events to the WSO2 API Manager traffic manager component, and take decisions based on traffic manger subscriptions.

Integration with third party key managers

By default all the APIs in the microgateway are OAuth2 protected. Hence API consumers require a valid OAuth2 token in order to invoke the APIs. Microgateway supports self contained jwt OAuth2 access tokens from any trusted key manager. In order to validate the jwt token sent by the key manager, microgateway requires the public certificate of the key manager in its trust store.

Request and response transformations

Microgateway now has the first class support to plugin external functions written in Ballerina, as interceptors during the request in-flow and the response out-flow. API developers can manipulate request/response headers, body, etc. prior to sending to the back end or responding to the client.

API/Resource level throttling

Earlier versions of microgateway only supported application and subscription level throttling. With this new version onwards, API developers can define new policies in the policy.yaml file of their project and attach them to the APIs using the open API extensions.

JWT revocation

Microgateway self validates the jwt tokens issued by the trusted key manager. It validates the JWT tokens signature using the public certificate of the key manager which signed the JWT. Due to this self validation mechanism microgateway will accept revoked tokens until they are get expired. So there should be a mechanism to notify microgateway about revoked jwt tokens. There are two mechanisms supported by microgateway:

  • Persistant notification via ETCD server

Microgateway can connect an ETCD server during startup and fetch all revoked tokens from the ETCD server. In the key manager component which issues and revokes tokens, there should be an extension point to add the revoked token into an ETCD server. When revoked tokens are added with their validity period, the ETCD server automatically removes them upon the expiration, hence mitigating the aggregation of revoked tokens on the ETCD server.

  • Real time notification via JMS

Microgateway can be configured to subscribe to a JMS topic to fetch details about tokens that are revoked during the runtime. This way, microgateway is notified about the tokens that get revoked after the server startup. In the key manager component, there should be an extension point to add the revoked token to the JMS topic.

Microgateway Deployment Use Cases

1.Monolithic centralized deployments

2.Use in microservices architecture as a private jet or sidecar gateway

3.Exposure point for the microservices as APIs in service mesh

What to Expect in the Near Future

  • GRPC support
  • Observability with Prometheus and Grafana
  • Cookie based authentication for SPAs
  • CI/CD with APIM import export tool and publish to WSO2 API Manager
  • Improved toolkit to fetch open API definitions from any URL
  • K8s CRDs with enhanced dev focussed design

Learn more about WSO2 API Microgateway here.

We have also organized a webinar which will explore in detail the architectural changes, new features and use cases, deployment patterns, and demonstrate the capabilities of WSO2 API Microgateway 3.0. Plus, screencasts that will be shown during this webinar will be published on our blog – so do keep a lookout for them.

Accessibility Requirements in WSO2 API Management

Accessibility standards in the world of web and internet are quite important as it allows people to access web resources without any difficulty, irrespective of their disabilities. There are many standards put forward to help developers implement accessibility into web-based resources. Some of these are:

  • Section 508 of the Rehabilitation Act of 1973
  • W3C Web Content Accessibility Guidelines (WCAG) 2.0 level A
  • W3C Web Content Accessibility Guidelines (WCAG) 1.0
  • W3C Authoring Tools Accessibility Guidelines (ATAG 1.0)

As a middleware vendor we’ve often been asked by Government customers and Federal Agencies in the United States, Europe and other parts of the world, if we are compliant with Section 508, WCAG 1.0/2.0, and ATAG 1.0 to enable a wider audience to use our software. These standards describe the desired accessibility required from information technology based services and products to make them accessible to differently-abled people.

A small explanation for those who can’t relate directly; sometimes you may ask if our software doesn’t touch end users, then why bother? Our software is predominantly catered towards developers and architects and they are the people who engage with our software on a technical level. So for instance, if you’re catering to a colorblind developer, having software complying to Section 508 ensures their disability is addressed.

What Do These Standards Say?

Section 508 states that it “requires Federal Agencies to make their ‘electronic and information technology’ accessible to people with disabilities”. However, this not only applies to Federal Agencies, but also impacts any company that conducts business with a Federal Agency like private contractors, and financial, healthcare, and legal organizations among others.

Section 508 was made part of the Rehabilitation Act of 1973 in 1998. It was revised in 2017 to include requirements for information and communication technology (ICT) in the federal sector. The guidelines were also updated to extend to the telecommunications sector, hence Section 508 was reorganized (along with Section 255) to better align with and reflect recent communication technology innovations.

Similarly, WCAG 1.0/ 2.0 documentation defines how to make ‘web content’ more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Web “content” generally refers to the information on a web page or web application, including:

  • Natural information such as text, images, and sounds
  • Code or markup that defines structure and presentation

It is primarily intended for web content developers (page authors, site designers, etc.), web authoring tool developers, web accessibility evaluation tool developers and others who want or need a standard for web accessibility, including for mobile accessibility.

The WCAG 1.0 is organized around guidelines that have checkpoints while 2.0 is organized around four design principles of web accessibility. The basis of determining conformance of the former are the checkpoints and the latter are the success criteria.

Overall, these different accessibility standards apply in different circumstances but are designed to complement each other. Often, these standards improve over time which is why you come across different versions.

In the open source community, we are as open to individual differences as we are to heterogeneous technologies. WSO2 API Manager, being one of the key products of the WSO2 Integration Agile Platform, has widespread deployments and has also been adopted by Governments and federal organizations. Hence, we designed WSO2 API Manager to be compliant with Section 508 so that it is accessible to all sorts of intended users regardless of their differences. The following section presents how each of the guidelines has been achieved in the product.

Section 508 Compliance in WSO2 API Manager

I have presented the basic guidelines from Section 508 and indicated how WSO2 API Manager has been designed to achieve this particular requirement. In this guideline, only the applicable parts have been discussed.

Addressing the requirements of Subpart B:

Section 508 Technical Standard WSO2 API Manager Achievement (with a few examples)
Software applications and operating systems
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually. WSO2 API Manager can be started up and executed using the command line (Windows)/ terminal (Mac), where the keyboard is the primary tool used to operate the application. Once started up, the API manager functions can be performed using the keyboard. For instance, the API design and implementation can be executed using the keyboard where you use the tab to move to each field where you want to specify API metadata. This is demonstrated in the sample API provided at the first-time launch of the product.
(b) Applications shall not disrupt or disable activated features of other products that are identified as accessibility features, where those features are developed and documented according to industry standards. Applications also shall not disrupt or disable activated features of any operating system that are identified as accessibility features where the application programming interface for those accessibility features has been documented by the manufacturer of the operating system and is available to the product developer. WSO2 API Manager is a web-based application. It does not interfere, disable or disrupt the operation of other applications or operating system on which it is running and vice versa.
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.

Yes, on the startup screen, a walk-through to create an API is presented for first-time users. This shows the current focus and guides the user to the next item after completion of each step.

For experienced users, the tab key can be used to identify the current focus and navigate through the interfaces. When a text field is focused, it shows the cursor in the particular textbox and the textbox is outlined in blue. For dropdowns, the list of options is expanded and shown to the user.

(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology. When an image represents a program element, the information conveyed by the image must also be available in text. Yes, this is made available where necessary.
(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application’s performance. Yes, the images used for APIs and their meanings are often consistent. The first letter of the API name is reflected in the image if it is not uploaded separately.
(f) Textual information shall be provided through operating system functions for displaying text. The minimum information that shall be made available is text content, text input caret location, and text attributes. Yes, textual information is provided through operating system functions. As a minimum, we provide:

  • Short text labels
  • Sample text that reflects the type of input required
  • Text input location identified using the cursor
  • Simple and consistent text attributes for titles, labels, validations, and descriptions across all WSO2 API Manager components
(g) Applications shall not override user selected contrast and color selections and other individual display attributes. WSO2 API Manager shows the default screens, however only affected by the contrast and color selections of the user’s screen/ monitor’s configuration.
(h) When animation is displayed, the information shall be displayable in at least one non-animated presentation mode at the option of the user. Not applicable as animations are not part of WSO2 API Manager.
(i) Color coding shall not be used as the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. Information is conveyed in different means, such as text, color, images and other items. For instance, the action to start creating an API (on the Publisher) is indicated as a rectangular button with text that says ‘Start Creating’.
(j) When a product permits a user to adjust color and contrast settings, a variety of color selections capable of producing a range of contrast levels shall be provided. Not applicable as adjusting color and contrast settings are not part of WSO2 API Manager.
(k) Software shall not use flashing or blinking text, objects, or other elements having a flash or blink frequency greater than 2 Hz and lower than 55 Hz. Not applicable as flashing and blinking text, objects or other elements are not used in WSO2 API Manager.
(l) When electronic forms are used, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues. Screen magnification is available as the interface can be zoomed in and out as preferred. Assistive technology is not built into the WSO2 API Manager however, it can work with such tools available with the OS/browser to enhance such capabilities.

The above table is based on WSO2 API Manager v2.6.0. If you do have any feedback, please email us at bizdev@wso2.com