WSO2 API Microgateway Security patterns

In this post, I’m going to discuss the security aspect of the deployment with WSO2 API Microgateway. The reason I’m writing this post is that depending on the token type, extension model the functionality you could get from the MGW varies. In this article, I’m mainly discussing 2 aspects of API security supported by MGW which is

I won’t be discussing the

in this article, since it will make this article too long.

If you are designing your API program according to the modern standards, there is a high chance that you end up using OAuth 2.0 based security for APIs. In the world of OAuth2.0 tokens, there are 2 types that WSO2 API MGW supports.

Based on the above description, it is evident that there is a clear difference in the way how MGW validates a given token type and that makes the way for this article.

This is the default pattern of using WSO2 API Microgateway along with the WSO2 API Manager.

As depicted in the above figure, in this deployment model, the WSO2 API Key Manager acts as the token issuer. When setting up the deployment, users have to add the public certificate used for signing the tokens by the key manager to the MGW.

The API consumer can generate an access token (JWT) by calling the token API exposed by the KM component. Alternatively, a user can also generate a token using the API Developer portal. This JWT token contains information about the user and his subscription details. Given below is a sample JWT in decoded form.

Based on this information, MGW will take the decision to do further validations like subscription and rate-limiting in addition to validating the certificate of the token.

With this approach, the full functionality of the MGW can be achieved which includes

— Application-based throttling

— Subscription-based throttling

— API level throttling

— Resource level throttling

One particular challenge with this mode of operation is the revocation of JWT. Since there is no communication between MGW and KM, when a certain JWT is revoked from the KM, there should be a mechanism to share that information with the MGW runtime. There is an approach recommended by WSO2 to achieve this functionality. You can find more details in the below link.

Even though there is a mechanism proposed by the vendor to get over the JWT token revocation problem, sometimes it is not easy to implement given that you need some 3rd party tools to support that. But it is a trade-off you have to bear if you go down the path of JWT. But if you don’t want to go with the JWT route, you can achieve similar functionality by using the OAuth 2.0 opaque token-based approach.

As depicted in the above figure, API consumers can generate an OAuth 2.0 opaque token using the same flow by doing the OAuth 2.0 dance and based on a certain grant type. This can be done either using the token API or using the developer portal. The main difference here is that, when the MGW receives this token from the consumer, it contacts the WSO2 API Key Manager for further validation of the token and the subscriptions since token does not carry any information. With this approach, users can achieve the full capability set of the API MGW. In addition to that, this approach makes the token revocation and synchronization much simpler since there is a connection between MGW and the KM.

One drawback of this approach is that since there is an additional network call for validating the token, the performance can be lower than the JWT mode. But again this is a trade-off you have to bear if you go with opaque token based approach.

The above pattern 1 and 2 are the most common security patterns recommended by WSO2. But that does not mean those are the only patterns that are supported by the product. In the modern enterprise ecosystem, there are many different vendors playing different roles based on their specialization. Because of that nature, sometimes WSO2 API Manager has to integrate with existing products to get certain functionalities like security, monitoring, etc. This 3rd pattern discusses how a user can utilize an already existing Identity Provider (IdP) as the key manager of the API manager deployment.

The major difference of this diagram from the first pattern is that the actual token management happens at an external 3rd party Identity Provider. But all these token management activities are going through the WSO2 API Manager Key Manager and that functionality is extended by means of a java extension. You can find more details on how to write this extension with the below links.

https://medium.com/@nuwandiwickramasinghe/using-wso2-api-manager-store-with-third-party-key-manager-50e2428ba76f

With this mode of deployment, users have to add the public certificate used by the external IDP for signing the JWT into the MGW. Users can generate tokens using the token endpoint or through the developer portal. In this model, subscription information is managed at the WSO2 Key Manager side while the actual tokens are managed by the external IDP. The user store is connected to a 3rd party external IDP. In this mode, API Publisher and Store portals can be configured to login with external IDP through the concept of federation. You can find more details on how to configure Developer Portal and Publisher with an external IDP in the below link.

https://medium.com/@athiththan11/wso2-api-manager-okta-sso-f04e9c6141e1

Users can follow a similar approach mentioned in the pattern1 section for token revocation. In addition to the token revocation challenge, users have to implement the custom key manager extension to integrate with an external IDP.

The next variant of the deployment is to have an external IDP manage the tokens while using OAuth 2.0 opaque tokens. With this approach, a custom extension needs to be developed to integrate external IDP with the WSO2 API Key Manager component.

As depicted in the above figure, API consumers will generate the OAuth 2.0 opaque token through the developer portal or by calling the token endpoint which will subsequently call the external IDP for creating applications, generating tokens and validating tokens. Once the token is received by the consumer, it will present that to the MGW where it communicates to the key manager for validation of the token which will eventually call the external IDP.

With this model, tokens and applications are managed by the external IDP while the subscriptions are maintained at the API key manager component. The user store is connected to the external IDP. The API publisher and developer portal can be configured to access through the external IDP by using the identity federation. Users will be able to get the full set of functionality with this model. There won’t be any additional set up required for token revocation since MGW communicates with KM for token validation. The same resources mentioned in the pattern3 can be used to implement the custom key manager extension and SSO configuration with external IDP.

The above mentioned 4 patterns are the recommended patterns you can use when implementing security with WSO2 API Microgateway. With those patterns, users will get the full set of functionalities provided through the MGW. This pattern 5 can be used, if any of the above-mentioned patterns are not possible to implement. If you really want to integrate WSO2 API MGW along with your existing Identity Provider without any customization to the product, this is the pattern for such a scenario.

In this pattern, the API consumer will receive the JWT token by calling the external IDP which is connected to the user store. The public certificate used for JWT signing by the external IDP needs to be added to the MGW trust store. Once this is done, the JWT token can be used by the API consumer to access the APIs which are deployed in the MGW runtime. It will validate the signature of the JWT and allow the user to access the API if the signature is valid.

One key thing to note here is that this JWT token does not carry the additional information which was there in the JWT token produced by the key manager in the pattern1. Since external IDP does not have a connection with API KM here, it does not know about the API applications and subscriptions and this information is not included in the JWT token. Because of that, with this approach, users will not be able to get the following capabilities through the MGW.

If you are fine with running the MGW without the aforementioned capabilities, this approach would work for you.

API publisher and developer portal can be configured with the external IDP for SSO through identity federation and you can follow the same links mentioned in the above pattern3 section.

In this article, I discussed various approaches a user can take to implement security for WSO2 API Microgateway. It showcases the flexibility of the product to run on its own and integrate with external IDPs through customizations as well as without any customizations. This article only discussed the security with OAuth 2.0 for MGW and it supports several other mechanisms including basic authentication, certificate-based (mutual SSL) authentication which you can find more details from the below link.

Related posts:

Collagen injections have long been used to treat minor facial imperfections like fine lines, wrinkles, crow’s feet, and acne scars. They have also been used to create fuller lips and have been…

The condition of the roads in many cities are in a pathetic condition. Either they are full of potholes or they are dusty and bumpy. In fact in the hilly terrains leading to the highways, there would…

The report offers a thorough investigation of the various patterns as well as factors impacting the progression of the global P2P Internet Financing Platform market. It has in-depth data associated…