Authentification de l'API Gateway

Yong Qian

November 25, 2022

Technology

Importance de l'authentification et de l'autorisation pour les passerelles API

La fonction principale d'une passerelle API peut être résumée comme connecter les consommateurs d'API et les fournisseurs d'API.

En pratique, à l'exception de quelques API permettant un accès anonyme, les fournisseurs restreignent souvent les consommateurs : seuls les consommateurs éligibles peuvent accéder à l'API. De plus, les fournisseurs peuvent ne pas avoir la même politique d'accès pour différents consommateurs, par exemple, les consommateurs A et B peuvent tous deux accéder à l'API /send_mail, mais la fréquence des appels par minute doit être calculée différemment.

À partir de ces deux points, nous pouvons voir qu'il est crucial d'identifier et de vérifier l'identité des consommateurs d'API au niveau de la passerelle API. Dans ce qui suit, nous présenterons comment la passerelle API open-source Apache APISIX implémente l'authentification des consommateurs et les méthodes d'authentification largement adoptées par les entreprises, puis nous expliquerons comment le système d'authentification des utilisateurs d'APISIX peut être utilisé conjointement avec d'autres fonctionnalités de sécurité pour renforcer davantage la protection des passerelles API.

authentification de la passerelle API

Authentification et autorisation d'Apache APISIX

Les proxies HTTP traditionnels ne peuvent identifier le demandeur qu'à partir de moyens grossiers tels que le domaine de la requête et l'IP du client, ce qui est insuffisant pour une passerelle API. Nous avons besoin de méthodes d'authentification plus raffinées pour répondre à des besoins métier de plus en plus complexes. L'un des principaux avantages d'APISIX par rapport aux proxies traditionnels est sa capacité d'extension flexible via des plugins, y compris une collection de plugins pour l'authentification des utilisateurs qui peuvent être divisés en deux catégories selon la méthode d'implémentation :

  1. Interface avec des services d'authentification externes

service d'authentification externe

  1. Authentification interne de la passerelle par l'objet Consumer conçu par APISIX

authentification interne

Ces deux méthodes d'authentification seront présentées tour à tour.

Interface avec des services d'authentification externes

Avant qu'une entreprise n'adopte une passerelle API, il y a souvent un service d'authentification distinct déployé dans le système. Alors, comment pouvons-nous interfacer APISIX avec le service d'authentification existant ? APISIX fournit une série de plugins qui fonctionnent en interfacant avec divers services d'authentification externes et en leur confiant la tâche de compléter l'authentification.

Par exemple, nous pouvons utiliser le plugin openid-connect pour interfacer avec tout service d'authentification prenant en charge le protocole OIDC. Voici un exemple de configuration pour interfacer avec le service keycloak :

curl http://127.0.0.1:9180/apisix/admin/routes -H "X-Api-Key: your-API-key" -XPOST -d '
{
    "uri":"/*",
    "plugins":{
        "openid-connect":{
            "client_id":"apisix", // Généré lors de la création d'un client dans keycloak
            "client_secret":"d5c42c50-3e71-4bbe-aa9e-31083ab29da4",
            "discovery":"http://keycloak:8080/auth/realms/apisix_test_realm/.well-known/openid-configuration", // Endpoint OpenID de keycloak
            "scope":"openid profile",
            "bearer_only":false,
            "realm":"apisix_test_realm",
            "introspection_endpoint_auth_method":"client_secret_post",
            "redirect_uri":"http://127.0.0.1:9080/"
        }
    },
    "upstream":{
        ...
    }
}'

Authentification interne de la passerelle

Consumer

consumer

Lorsque des requêtes provenant de diverses sources arrivent à la passerelle API, celle-ci doit identifier ces appelants. Apache APISIX propose le concept de "Consumer" pour représenter les appelants d'un certain type de service.

L'objet Consumer nécessite la configuration d'un plugin d'authentification pour être utilisé. Prenons l'exemple du plugin key-auth le plus simple :

$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "auth-jack"
        }
}'

La configuration ci-dessus signifie que lorsque la requête porte la clé spécifiée (auth-jack), la requête actuelle sera associée au Consumer - jack. Comme vous pouvez le voir, le plugin d'authentification configuré sur le Consumer est en fait une preuve d'identité sous un mécanisme d'authentification spécifié. Dans le plugin key-auth, la clé est la preuve qui identifie un consommateur, similaire au nom d'utilisateur et au mot de passe du plugin basic-auth.

Configuration du plugin d'authentification pour la route

Une fois que nous avons associé les informations d'identification à un consommateur spécifique via le Consumer, nous devons également activer le plugin d'authentification sur la route correspondante :

$ curl http://127.0.0.1:9180/apisix/admin/routes/orders -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "uri": "/orders",
    "plugins": {
        "key-auth": {
            "header": "Authorization"
        }
    }
}'

La configuration ci-dessus signifie que le plugin key-auth est activé sur la route /orders, et l'effet d'authentification est le suivant :

$ curl http://127.0.0.1:9080/orders -H 'Authorization: auth-jack' -i
HTTP/1.1 200 OK
...
$ curl http://127.0.0.1:9080/orders -H 'Authorization: wrong-key' -i
HTTP/1.1 401 Unauthorized
...
{"message":"Invalid API key in request"}

Lorsqu'une requête d'un utilisateur atteint cette route, APISIX essaiera d'obtenir la clé fournie par l'utilisateur via l'en-tête Authorization. Si elle n'est pas obtenue, ou si la clé obtenue n'est pas légitime, la requête sera directement rejetée par la passerelle, protégeant ainsi le service en amont.

On peut voir que dans les deux méthodes d'authentification ci-dessus, le plugin d'authentification est au cœur du système, dont la richesse affecte directement le choix des utilisateurs pour les passerelles API afin de réaliser l'authentification. Voici quelques-unes des méthodes d'authentification principales et leurs avantages et inconvénients respectifs pour votre référence.

Méthodes d'authentification principales

L'authentification et l'autorisation, un mécanisme de base qui existe depuis que nous sommes entrés dans le monde de l'informatique, ont évolué vers un domaine très diversifié après tant d'itérations au fil des années. Le mécanisme de plugins d'APISIX a grandement réduit le coût de développement pour implémenter diverses méthodes d'authentification. Voici quelques-unes des méthodes d'authentification principales déjà supportées par APISIX :

Key Auth

Key Auth est le plus simple de tous les plugins d'authentification, mais il a un large éventail d'applications dans des scénarios réels, tels que les licences pour les logiciels payants, les jetons pour identifier les développeurs sur les plateformes d'API ouvertes, etc., qui peuvent tous être facilement implémentés avec Key Auth. De plus, basé sur la capacité de configuration et d'allocation entièrement dynamique d'APISIX, les clés peuvent être créées et révoquées rapidement, prenant effet en temps réel.

Basic Auth

Basic Auth est une méthode d'authentification basée sur le nom d'utilisateur et le mot de passe, souvent utilisée dans les scénarios de connexion web. Par exemple, l'interface d'administration d'un site web peut être utilisée après la connexion de l'administrateur, où nous pouvons utiliser Basic Auth pour l'authentification.

LDAP

LDAP (Lightweight Directory Access Protocol) est un protocole d'accès léger aux répertoires basé sur la norme X.500, fournissant un contrôle d'accès et une maintenance des répertoires d'informations distribués via le protocole IP. Avec LDAP, les développeurs d'applications et d'opérations peuvent contrôler l'accès des utilisateurs aux ressources à un niveau granulaire. Avec le plugin ldap-auth d'APISIX, vous pouvez facilement interfacer avec des plateformes implémentant le protocole LDAP, comme Active Directory de Microsoft, ou OpenLDAP Server pour les plateformes Linux, pour contrôler finement l'accès des consommateurs à des routes spécifiques.

OIDC

OpenID est un système d'authentification en ligne décentralisé. Pour les sites supportant OpenID, les utilisateurs n'ont pas besoin de se souvenir des jetons d'authentification traditionnels tels que les noms d'utilisateur et les mots de passe. Au lieu de cela, ils n'ont qu'à s'inscrire à l'avance sur un site web agissant comme un fournisseur d'identité OpenID (IdP), et peuvent ensuite utiliser ce compte pour se connecter à toutes les applications interfacées avec ce fournisseur, par exemple, pour authentifier les utilisateurs de notre propre système via les comptes des services bien connus de Google ou Facebook.

Pour OIDC, APISIX fournit le plugin openid-connect, qui peut être utilisé pour interfacer avec des services d'authentification supportant le protocole OIDC.

Forward Auth

Lorsque le plugin d'authentification standard d'APISIX ne répond pas à vos besoins actuels, ou si un service d'authentification dédié et non standard a été déployé dans votre système, vous pouvez envisager d'utiliser le plugin forward-auth. En utilisant ce plugin, vous pouvez transférer les requêtes des utilisateurs au service d'authentification via HTTP et retourner des erreurs personnalisées ou rediriger les utilisateurs vers la page d'authentification si le service d'authentification répond avec un statut non normal (code d'erreur autre que 20x).

Avec la puissance du plugin forward-auth, la logique d'authentification et d'autorisation peut être très astucieusement transférée à un service externe dédié et non standard.

Liaison avec d'autres plugins après l'authentification

L'authentification des utilisateurs n'est que la première étape pour sécuriser l'API avec APISIX. Combiner les capacités d'authentification avec d'autres plugins de sécurité amplifiera davantage les capacités de sécurité de la passerelle.

ACL (consumer-restriction)

Dans un système backend complexe, il peut y avoir des API qui ont des restrictions de sécurité plus élevées que d'autres, nécessitant non seulement de bloquer les utilisateurs anonymes mais aussi de restreindre les utilisateurs authentifiés, par exemple, en permettant uniquement aux utilisateurs en liste blanche d'accéder à l'API de gestion des utilisateurs.

liste blanche

Dans ce cas, nous pouvons utiliser le plugin consumer-restriction fourni par APISIX pour implémenter le mécanisme de contrôle d'accès.

$ curl http://127.0.0.1:9180/apisix/admin/routes -H 'X-API-KEY: your-API-key' -X POST -i -d '
{
    "uri": "/api/v1/users/admin",
    "plugins": {
        "key-auth": {},
        "consumer-restriction": {
            "whitelist": [
                "Rose",
                "Peter
            ]
        }
    },
    "upstream": {
        ...
    },
}'

La route ci-dessus restreint la route /api/v1/users/admin pour exiger une authentification par clé via les plugins key-auth et consumer-restriction, et seuls Rose et Peter peuvent y accéder.

Limitation de débit (limit-count)

Nous avons décrit précédemment que vous pouvez associer les informations d'identification des utilisateurs aux consommateurs en configurant des plugins d'authentification dans le Consumer, mais en réalité, les objets Consumer d'APISIX peuvent non seulement monter des plugins d'authentification, mais aussi n'importe quel plugin comme Route et Service.

Par exemple, dans l'application réelle, la politique de limitation de débit n'est souvent pas statique mais personnalisée. Il est souvent demandé que les appelants de différents niveaux de service aient des politiques de limitation de débit d'API différentes. Cependant, une telle demande ne peut pas être résolue en montant le plugin de limitation de débit sur la route. Par conséquent, nous devons monter le plugin de limitation de débit sur le Consumer et spécifier une politique de limitation de débit ciblée pour chaque consommateur.

$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "jack",
    "plugins": {
        "key-auth": {
            "key": "jack"
        },
        "limit-count": {
            "count": 200,
            "time_window": 60,
            "rejected_code": 503,
            "key": "$consumer_name",
        }
}'
$ curl http://127.0.0.1:9180/apisix/admin/consumers  -H 'X-API-KEY: your-API-key' -X PUT -i -d '
{
    "username": "rose",
    "plugins": {
        "key-auth": {
            "key": "rose"
        },
        "limit-count": {
            "count": 1000,
            "time_window": 60,
            "rejected_code": 503,
            "key": "$consumer_name",
        }
}'

Avec la configuration ci-dessus, nous spécifions des politiques de limitation de débit différentes pour jack et rose, avec rose ayant un quota de requêtes plus élevé de 1000 en 60 secondes, tandis que jack n'a que 200.

Résumé

En tant que capacité indispensable des passerelles API, l'authentification et l'autorisation est l'un des facteurs importants que les utilisateurs prennent en compte lors de la sélection des passerelles API.

Apache APISIX, la passerelle open-source présentée dans cet article, couvre toutes les principales méthodes d'authentification et peut répondre aux besoins des utilisateurs d'entreprise en matière d'authentification et d'autorisation. APISIX présente également les avantages suivants :

  • Une riche collection de plugins d'authentification prêts à l'emploi
  • Support des méthodes d'authentification internes et externes, que les utilisateurs peuvent choisir librement
  • Support du développement secondaire, facile à interfacer avec des centres d'authentification personnalisés

Ces avantages peuvent aider les entreprises à mettre en œuvre plus facilement l'authentification et l'autorisation au niveau de la passerelle et à renforcer la sécurité des API.

Bienvenue pour en savoir plus sur Apache APISIX. Vous pouvez nous contacter à https://api7.ai/contact.

Tags:
Authentication & Authorization
OIDC
API Gateway Concept