The Enduring Case for Open Source Software

Photo credits: Clay Banks on Unsplash

Open source software is everywhere we can think of, solving industry challenges. What had its roots in the Free Software Movement (founded by Richard M. Stallman in the early 1980s) began getting more widespread attention in the mid 1990s (think Linux) and is big business today. Which is why 2018 was such a legendary year for open source software. We all remember that early in the past year Salesforce bought Mulesoft for USD 6.5 billion, then Microsoft announced its intention to acquire GitHub for USD 7.5 billion, and the year ended with IBM acquiring RedHat for USD 34 billion. Then there’s the projection that global open source services will grow to USD 32.95 billion by 2022!

Heady numbers aside, open source has been on the “tech trends to watch for year xxx” lists for several years now in multiple publications. Its relevance will only continue to increase in the years to come. This is because transparency, community collaboration, and accessibility have always been the cornerstones of open source software from its earliest days. And ultimately these are the foundations that will contribute to its benefits:

  • The ability to change, alter, and extend the source code without depending on the vendor all the time. We’re talking freedom here – from vendor lock-in.
  • With the community playing such an important role, the transfer of knowledge is one of the biggest assets of open source. This helps you continually improve the code and fix bugs. The result – continuous improvements in standards of your software projects.
  • The lack of a need to rely on a vendor and the flexibility this gives you are precisely what makes open source more cost-effective in the long run.
  • Gives you the option to experiment – and fail and move on quickly if things don’t work as you planned.
  • As you keep experimenting, you are placed in an ideal position to innovate fast and present something new to the market.
  • Finally, in the true spirit of community, you don’t merely “take” – you also “give” back to the community and make sure that others gain from your contributions.

Here at WSO2, we’re advocates of open source and our founders were inspired by its possibilities. We’re also the biggest open source integration vendor with analyst recognition to boot. So why do we believe in an open source approach to API-centric integration?

Because there’s an approaching endpoint explosion. The world is estimated to have around a trillion programmable endpoints and APIs, and no growth of this scale comes sans issues (and opportunities of course.) There are the changing protocols, formats, and diversity of endpoints to take into account. This is where all the best things about open source will help. Increasing changes will need the help of the community, you will need to avoid any kind of lock-in (be it vendor, data, or APIs) to remain flexible, and transparency always helps with accountability and consensus.

You may have many questions (and perhaps even misgivings) about adopting open source software: “Freedom is great but do I have support if needed?” “What about security?” “In spite of the talk, how transparent is this model?” WSO2 has dedicated 24/7 support and we’ll help with your security concerns (by the way, we have an open source identity and access management solution). On the topic of transparency, we take things one step further. WSO2 makes our product/solutions roadmaps and even financials public, in-keeping with our open and transparent ethos.

So, open source is here to stay. The world today is heavily discussing emerging technologies (such as biometrics, artificial intelligence, blockchain, robotics, virtual/augmented reality) and what their possibilities will be for our politics, economy, society, and wellbeing. We’re not here to predict what sci-fi looking future awaits us. But we can tell you that open source will be an ever present constant, to be found in any emerging software project. Because in the words of Ben Balter, senior manager of product management at GitHub: “Open source is the future.”

Discover who we are and our vision for open source API-centric integration.

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.