2017-09-28 5 views
1

Contextecas d'utilisation pour les produits de gestion de l'API lorsque l'API back-end existe sur Internet et est sécurisé par OAuth2

Je travaille sur un projet où nous mettons en place une plate-forme d'intégration/ESB et le long du côté ce une gestion de l'API produit.

La stratégie consiste à avoir une couche d'intégration à travers laquelle une grande partie de l'intégration est gérée. Cela découpe les systèmes individuels, permet de contrôler l'accès et le suivi en un seul endroit.

Je suis un peu nouveau dans la gestion des API, mais j'ai travaillé avec l'intégration d'applications d'entreprise pendant plusieurs années.

Scénario

Dans les premières intégrations, nous sommes d'exposer une API back-end grâce à la plate-forme de gestion de l'API. L'API backend ainsi que l'application appelante existent sur Internet et l'API backend est sécurisée avec OAuth 2 (grant type = mot de passe). Il n'y a cependant pas d'informations d'identification de l'utilisateur final envoyées, ce type de flux de machine à machine.

Nous avons reçu le client ainsi que les informations d'identification de l'utilisateur et l'idée est de l'abstraire des applications qui s'authentifieront à la place par rapport au produit de gestion de l'API.

Problème

Ce scénario a toutefois été difficile à mettre en œuvre dans le produit de gestion de l'API, il semble exiger la médiation depuis la passerelle API ne peut pas simplement envoyer la demande à l'API back-end, il doit d'abord obtenir un jeton pour pouvoir appeler l'API.

J'ai posté une autre question (WSO2 APIM - Backend service uses OAuth 2 with Password Grant) qui est plus centrée sur le produit mais je veux parallèlement poser des questions sur ce scénario dans une perspective plus large.

Solution possible

Utilisez le ESB pour arbitrer le flux OAuth vers l'API back-end et que le produit de gestion de l'API comme une façade où l'authentification et d'autres aspects sont gérés pour appeler des applications.

Questions

  • Étant donné que le produit de gestion de l'API ne prend pas en charge l'authentification avec OAuth 2 vers l'API back-end, je me demande si ce scénario est inhabituel? C'est à dire. faire abstraction de l'authentification de l'API backend lors de l'utilisation d'OAuth.
  • Est-ce un cas d'utilisation pour un produit de gestion d'API?
  • La solution possible est-elle raisonnable?

Répondre

0

Il y a deux scénarios qui sont communs jolis

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

et

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

le premier est préféré si votre passerelle possède des capacités de OAuth (dans votre cas), car normalement les passerelles sont l'utilisation en tant que points d'application de la sécurité, et dans les deux cas l'idée est la même, encapsuler la complexité du fournisseur et rendre ses fonctionnalités disponibles pour le reste des services/consommateurs dans votre ESB. Par ailleurs, dans le cloud, vous devriez envisager une approche de microservices au lieu d'un ESB, car les ESB ne se développent pas bien.