1

Background

I am working on a project where we are setting up an integration platform/ESB and along side this an API management product.

The strategy is to have an integration layer through which much of the integration is handled. This decouples the individual systems, makes it possible to control access and monitoring in one place.

I am kind of new to API management as well but have worked with enterprise application integration for several years.

Scenario

In the first integrations we are to expose a backend API through the API Management platform. The backend API as well as the calling application exists on the internet and the backend API is secured with OAuth 2 (grant type = password). There is however not any end user credentials being sent this is kind of a machine-to-machine flow.

We've been given the client as well as the user credentials and the idea is to abstract this away from the application(s) who will instead authenticate against the API management product.

Problem

This scenario was however hard to implement in the API management product, it seems to require mediation since the API gateway can't just send the request to the backend API it first needs to get a token to be able to call the API.

I've posted another question (WSO2 APIM - Backend service uses OAuth 2 with Password Grant) which is more focused on the product but I want to parallelly ask about this scenario in a broader perspective.

Possible solution

Use the ESB to mediate the OAuth flow towards the backend API and have the API management product as a facade where authentication and other aspects is managed for calling applications.

Questions

  • Since the API management product doesn't support authentication with OAuth 2 towards the backend API I'm wondering if this scenario is unusual? I.e. to abstract away the backend API authentication when using OAuth.
  • Is this a use case for an API management product?
  • Is the possible solution reasonable?
ohlaj
  • 11
  • 2

1 Answers1

0

There are two scenarios which are pretty commons

                           ⌐---------------> internal services
consumer --> gateway --> esb --> gateway --> external services

and 

                           ⌐---------------> internal services
consumer --> gateway --> esb --------------> external services

the first one is preferred if your gateway has OAuth capabilities (in your case) because normally gateways are use as security enforcement points, and in both the idea is the same, encapsulate the complexity of the provider and make its functionality available for the rest of services / consumers in your ESB.

By the way, in cloud you should consider a microservices approach instead of a ESB, as ESB do not scale well.

jmhostalet
  • 4,399
  • 4
  • 38
  • 47