Appliquez un contrôle d’accès granulaire et un routage avec API Connectivity Manager

Veena Raja Rathna

Un aspect important de la gestion des API tout au long de leur cycle de vie consiste à contrôler précisément l’accès aux API et le routage du trafic. Les jetons d’accès se sont imposés comme la norme de facto pour gérer l’accès aux API. L’un des avantages des mécanismes d’authentification basés sur les jetons web JSON (JWT) est la possibilité d’exploiter les revendications du JWT afin de mettre en œuvre ce contrôle précis des accès. Les autorisations peuvent être encodées sous forme de revendications personnalisées, que les propriétaires d’API peuvent utiliser pour contrôler l’accès à leurs API. Une fois que le proxy d’API a validé le JWT, il peut accéder à tous les champs du jeton sous forme de variables et s’appuyer sur ceux-ci pour prendre des décisions en matière d’accès.

Dans un article précédent, nous avons expliqué comment API Connectivity Manager peut aider les équipes d’exploitation et de développement à mieux collaborer. Les équipes des différentes branches d’activité qui possèdent et exploitent des API doivent disposer d’un contrôle total lorsqu’elles développent et améliorent l’expérience offerte par leurs API et leurs services.

API Connectivity Manager fournit des stratégies qui permettent aux propriétaires d’API de configurer des paramètres au niveau du service, tels que l’authentification et l’autorisation des API, ainsi que des exigences de sécurité supplémentaires. Dans cet article, nous montrons comment les propriétaires d’API peuvent utiliser la stratégie Access Control Routing pour appliquer un contrôle précis à des routes spécifiques et l’affiner davantage afin qu’elle s’applique par méthode HTTP et par route, en fonction de revendications spécifiques contenues dans le jeton.

Prérequis

Vous devez disposer d’un abonnement d’essai ou payant à F5 NGINX Management Suite, qui comprend Instance Manager et API Connectivity Manager, ainsi que NGINX Plus en tant que passerelle d’API et NGINX App Protect pour sécuriser vos API. Pour commencer, demandez un essai gratuit de 30 jours de NGINX Management Suite.

Pour savoir comment installer NGINX Management Suite et API Connectivity Manager, consultez le Guide d’installation.

Accorder l’accès et acheminer le trafic vers un service spécifique

Supposons que nous ayons publié un proxy d’API d’entrepôt avec plusieurs points de terminaison, tels que inventory, orders, etc. Nous souhaitons maintenant introduire un nouveau service appelé pricing, mais le rendre accessible uniquement à quelques clients inscrits à un essai bêta. Ces clients sont identifiés par une revendication appelée betatester. Dans cet exemple de jeton d’accès, cette revendication a la valeur true pour l’utilisateur identifié dans la revendication sub, user1@abc.com.

Header
{
  "kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
  "alg": "RS256"
}
Payload

{
  "ver": 1,
  "jti": "AT.xxxxxxxxxxxx",
  "iss": "https://oauthserver/oauth2/", "aud": "inventoryAPI", "iat": 1670290877, "exp": 1670294477, "cid": "AcvfDzzzzzzzzz", "uid": "yyyyyyyWPXulqE4x6", "scp": [ "apigw" ], "auth_time": 1670286138, "sub": "user1@abc.com", "betatester": true, "domain": "abc" }

Pour user2@abc.com, qui n’a pas été sélectionné pour le programme bêta, la revendication betatester est définie sur
false :

"sub": "user2@abc.com","betatester": false,

Nous configurons maintenant la politique de routage du contrôle d’accès (access-control-routing) afin d’autoriser l’accès au service pricing pour les utilisateurs dont le JWT contient la revendication betatester avec la valeur true.

Par souci de concision, nous présentons uniquement la charge utile de la stratégie. Cette stratégie fonctionne uniquement avec les stratégies basées sur des jetons dans API Connectivity Manager, telles que JWT Assertion et OAuth2 Introspection.

"policies": {  "access-control-routing": [
    {
      "action": {
        "conditions": [
          {
            "allowAccess": {
              "uri": "/pricing"
            },
            "when": [
              {
                "key": "token.betatester",
                  "matchOneOf": {
                    "values": [
                      "true"
                    ]
                  }
              }
            ]
          }
        ],
        "returnCode": 403
      }
    }
  ]
}

Une fois la politique appliquée, le proxy d’API valide les revendications du JWT pour les utilisateurs authentifiés et effectue un contrôle d’accès précis afin d’acheminer les requêtes de user1@abc.com et de rejeter celles de user2@abc.com.

Contrôle de l’utilisation de méthodes spécifiques

Nous pouvons affiner davantage la stratégie access-control-routing afin de déterminer quels utilisateurs peuvent employer certaines méthodes HTTP. Dans cet exemple, le proxy d’API autorise uniquement les administrateurs (les utilisateurs dont le jeton contient la valeur « Admin ») à utiliser la méthode DELETE.

"policies":{  "access-control-routing":[
    "action":{
      "conditions":[
        {
          "when":[
            {
              "key":"token.{claims}",
              "matchOneOf":{
                "values":[
                  "Admin"
                ]
              }
            }
          ],
          "allowAccess":{
            "uri":"/v1/customer",
            "httpMethods":[
              "DELETE"
            ]
          },
          "routeTo" : {
            "targetBackendLabel" : ""
          }
        }
      ]
    }
  ]
}

Routage basé sur les en-têtes

Une autre utilisation de la politique access-control-routing consiste à prendre des décisions de routage en fonction des valeurs d’en-tête des requêtes entrantes. Les propriétaires d’API peuvent configurer des règles ou des conditions qui précisent les valeurs d’en-tête auxquelles la requête doit correspondre pour être acheminée. Les requêtes sont transférées si elles contiennent l’en-tête et rejetées dans le cas contraire.

Dans cet exemple, une requête est acheminée vers le point de terminaison /seasons uniquement lorsque l’en-tête de requête version a pour valeur v1. La valeur returnCode indique le code d’erreur à renvoyer lorsque version n’est pas égal à v1 – dans ce cas, il s’agit de 403 (Interdit).

"access-control-routing": [  {
    "action": {
      "conditions": [
        {
          "allowAccess": {
            "uri": "/seasons"
          },
          "when": [
            {
              "key": "header.version",
              "matchOneOf": {
                "values": [
                  "v1"
                ]
              }
            }
          ]
        }
      ],
      "returnCode": 403
    }
  }
]

Dans cet exemple de requête curl, nous envoyons une requête au service seasons avec l’en-tête version défini sur v2 :

curl -H "version: v2" http://example.com/seasons

Étant donné que la valeur de l’en-tête « version » n’est pas « v1 », comme l’exige la stratégie, le service renvoie le code d’état 403.

Inclure plusieurs règles dans la stratégie

Vous pouvez inclure plusieurs règles dans une stratégie de routage avec contrôle d’accès afin de contrôler le routage en fonction d’un, de deux ou des trois critères abordés dans cet article : les revendications JWT, les méthodes valides et les valeurs des en-têtes de requête. Pour être acheminée, une requête doit remplir les conditions de toutes les règles ; dans le cas contraire, elle est bloquée.

Résumé

API Connectivity Manager permet aux propriétaires d’API de contrôler et d’améliorer l’expérience offerte par leurs API et services grâce à des stratégies au niveau des API qui appliquent un contrôle d’accès précis et prennent des décisions de routage dynamiques.

Pour commencer à utiliser API Connectivity Manager, demandez un essai gratuit de 30 jours de NGINX Management Suite.

À propos de l’auteur

Veena Raja Rathna

Autres articles de Veena Raja Rathna