Posts tagged with gateway

One common request we hear is how to create custom URL patterns for the Apiman Gateway.

For example, this means allowing changing the (Public API) default:

To a custom alternative. As a simple example we’re going to hard-code an organisation in. We’ll assume that we’ve established a convention to always publish our APIs to a particular org. That will change the pattern to:

In this blog, we’ll outline a few simple tweaks you can make to improve the performance of the Apiman Gateway when running on servlet platforms (WildFly, EAP, Tomcat, etc).

Most of the focus will be on WildFly and EAP, but others will be more broadly applicable.

Naturally, these are very rough pointers and should merely be hints for areas that could prove fruitful. There’s no one-size-fits all approach to tuning, so always profile and keep tweaking to find the best settings for your workloads.

In a world where APIs are quickly becoming the standard, most of us understand the importance of following best practices for API security. We authenticate, authorize and throttle requests. We encrypt the data that we share with other applications (hopefully!). But we often neglect one of the most essential components of the API layer: data storage.

One of the strongest features of apiman, in general, is its excellent extensibility. Not only is it easy to add new policies, for example, but many of its core components are also pluggable. This includes, for example, the registry used by the API Gateway to store configuration information published to it by the manager. This blog post will detail a new JDBC based implementation of that registry, explaining how you can store that information in a Database instead of in Elasticsearch (the default setting).

In a recent blog post I explained why APIs used to be completely frozen once they were published, and how we have loosened that restriction for Public APIs. Similarly, we did not allow Client Apps to be changed and then re-registered. This was never a good decision, since the Client App does not have anything "connected" to it (the way that an API may). So we should never have restricted the registration of a Client App!

The last thing you want after carefully setting up your system with apiman is for someone to be able to call around the gateway and hit your APIs directly. The typical solution for this is to lock down your network so that the only publicly accessible part is the apiman gateway, whilst APIs are hidden in the private part of the network, which apiman can access, but not someone in the outside world. However, in some situations fine-grained network controls may not be available, such as the cloud; or, you may wish to have an additional layer of security to be reassured that no funny business is going on (such as imposters).

The class of solutions to this problem generally falls under the banner of mutual authentication. One such mutual auth offering apiman supports is Mutually Authenticated TLS^[1].

One great advantage of API Management is centralising auth concerns, thereby avoiding burdensome reimplementation issues and streamlining your security processes. The good news is that you can easily configure apiman to handle many common auth use-cases, such as OAuth2 with our popular Keycloak OAuth2 policy which I’ll outline in this blogpost.