API Gateway:Configure custom authentication and authorization

Contexte

Les serveurs s'appuient généralement sur des identifiants (jetons) présents dans les requêtes clientes pour sécuriser les communications des API exposées en externe.

• Si vos jetons sont des JSON Web Tokens (JWT), vous pouvez valider leurs signatures n'importe où à l'aide d'une clé publique, sans avoir besoin d'accéder à un service d'authentification centralisé.

• Si vos jetons utilisent un format personnalisé, le serveur doit appeler un service centralisé pour effectuer les vérifications d'authentification et d'autorisation. Ce processus permet de sécuriser les communications API. Cloud-native API Gateway prend en charge cette méthode d'authentification et d'autorisation personnalisée.

L'exemple suivant illustre le flux de traitement des requêtes après l'intégration d'un Cloud-native API Gateway avec un service d'authentification personnalisé.

1. Un client envoie une requête d'authentification, telle qu'une opération de connexion, à la passerelle.

2. La passerelle transfère directement la requête d'authentification au service d'authentification.

3. Le service d'authentification valide les identifiants contenus dans la requête, tels qu'un nom d'utilisateur et un mot de passe. En cas de validation réussie, il renvoie un jeton à la passerelle, qui le relaie ensuite au client.

4. Le client envoie une requête métier, par exemple une demande vers le chemin /order pour passer une commande. La requête inclut le jeton émis après l'authentification réussie.

5. La passerelle intercepte le chemin (y compris les paramètres de requête), la méthode HTTP (telle que GET ou POST) et le jeton de la requête métier d'origine. Elle utilise ces informations pour construire une nouvelle requête et l'envoie au service d'authentification personnalisé pour autorisation. Dans la console de la passerelle, vous devez configurer l'en-tête HTTP contenant le jeton. Vous pouvez également autoriser l'inclusion du corps de la requête d'origine.

   Si l'API d'authentification du service d'authentification personnalisé est /validateToken, la passerelle forme le chemin réel de la requête d'autorisation en ajoutant le chemin de la requête métier d'origine au chemin de l'API d'authentification, ce qui donne /validateToken/order.

6. Lorsque le service d'authentification reçoit la requête d'autorisation, il peut valider le jeton et vérifier si le client est autorisé à accéder au chemin de la requête d'origine.

   • Si votre service d'authentification peut modifier le code d'état HTTP dans sa réponse, vous pouvez utiliser ce code pour indiquer le résultat de l'autorisation.

     • Un code d'état HTTP 200 indique que le jeton est valide et autorisé à accéder à la ressource backend. La passerelle transfère alors la requête métier d'origine au service backend protégé. Après avoir reçu la réponse du backend, la passerelle la transmet au client, ce qui finalise l'opération de passation de commande.

     • Un code d'état HTTP 401 ou 403 indique que le jeton est invalide ou non autorisé à accéder à la ressource backend. La passerelle renvoie immédiatement la réponse du service d'authentification au client, ce qui entraîne l'échec de l'opération de passation de commande.

   • Si votre service d'authentification doit toujours renvoyer un code d'état HTTP 200 en raison de contraintes métier, vous pouvez utiliser l'en-tête HTTP intégré x-mse-external-authz-check-result.

     • Si le service d'authentification renvoie une réponse avec l'en-tête x-mse-external-authz-check-result défini sur true, cela indique que le jeton est valide et dispose de l'autorisation d'accès à la ressource backend. La passerelle transfère alors la requête d'origine au service backend protégé et relaie la réponse au client, ce qui finalise l'opération de passation de commande.

     • Si le service d'authentification renvoie une réponse avec l'en-tête x-mse-external-authz-check-result défini sur false, cela indique que le jeton est invalide ou ne dispose pas de l'autorisation d'accès à la ressource backend. La passerelle renvoie directement la réponse du service d'authentification au client, ce qui entraîne l'échec de l'opération de passation de commande.

Créer une règle d'authentification personnalisée

1. Connectez-vous à la console API Gateway.

2. Dans le volet de navigation de gauche, cliquez sur Cloud-native API Gateway > Instance. Dans la barre de navigation supérieure, sélectionnez une région.

3. Sur la page Instance, cliquez sur le nom de l'instance de passerelle cible.

4. Dans le volet de navigation de gauche, cliquez sur Security Management > Global Authentication.

5. Sur la page Global Authentication, cliquez sur Create Authentication. Dans le panneau Create Authentication, configurez les paramètres et cliquez sur OK.

   Paramètre	Remarque : Custom Authentication Service
   Enable	Indique s'il faut activer l'authentification et l'autorisation pour Cloud-native API Gateway.
   Authentication Name	Nom personnalisé pour la règle d'authentification et d'autorisation.
   Authentication Type	Sélectionnez Custom Authentication Service.
   Authentication Service	Le service backend utilisé pour l'authentification et l'autorisation. Vous pouvez ajouter des services dans la gestion des services. Pour plus d'informations, consultez Ajouter un service. Remarque Seuls les services utilisant le protocole HTTP sont pris en charge. Les services utilisant d'autres protocoles, tels que Dubbo, ne sont pas pris en charge. Si un service Kubernetes possède plusieurs ports, le premier port est utilisé par défaut. Si vous souhaitez utiliser un autre port, créez un service Kubernetes supplémentaire dans Container Service for Kubernetes (ACK) qui expose uniquement le port cible.
   Authentication API	Le chemin de l'API fournie par le service d'authentification. La passerelle utilise ce chemin pour la correspondance de préfixe. Par exemple, si votre service d'authentification est basé sur Spring MVC, expose l'API d'authentification /check et que vous souhaitez gérer les requêtes pour les chemins commençant par /check/, vous pouvez le configurer comme suit : @RequestMapping("/check/") public ResponseEntity<RestResult<String>> check(){}
   Token Location	L'emplacement du jeton dans l'en-tête de la requête, généralement Authorization ou Cookie. Vous pouvez soit Select dans une liste, soit Add Manually pour définir l'emplacement du jeton.
   Allowed Headers in Authentication Rrequest	Spécifie quels en-têtes de la requête cliente d'origine doivent être transmis au service d'authentification. Remarque Les en-têtes Host, Method, Path et Content-Length sont inclus par défaut et n'ont pas besoin d'être ajoutés manuellement.
   Allowed Headers in Authentication Response	Spécifie quels en-têtes de la réponse du service d'authentification doivent être ajoutés à la requête envoyée au service backend. Remarque Si un en-tête spécifié ici existe déjà dans la requête cliente, la passerelle écrase sa valeur.
   Allow Body in Authentication Request	Allow Body in Authentication Request : Inclut le corps de la requête cliente d'origine dans la requête envoyée au service d'authentification. Maximum Body Size : La taille maximale du corps de la requête pouvant être transférée, en octets.
   Timeout Period	Le temps maximal, en secondes, d'attente d'une réponse du service d'authentification. Valeur par défaut : 10.
   Mode	Spécifie le comportement lorsque le service d'authentification est indisponible. Le mode Loose Mode et le mode Strict Mode sont pris en charge. Nous vous recommandons d'utiliser le mode Loose Mode. Loose Mode : Si le service d'authentification est indisponible (par exemple, échec de la connexion ou erreur 5xx renvoyée par le service), la passerelle autorise la requête cliente à se poursuivre. Strict Mode : Si le service d'authentification est indisponible (par exemple, échec de la connexion ou erreur 5xx renvoyée par le service), la passerelle rejette la requête cliente.
   Simple Conditions	À côté de Authorization, cliquez sur Simple Conditions. Ce mode prend en charge le Whitelist Mode et le Blacklist Mode. Whitelist Mode : Les requêtes correspondant aux hôtes et aux chemins de la liste blanche peuvent contourner la validation. Tous les autres hôtes et chemins nécessitent une validation. Blacklist Mode : Les requêtes correspondant aux hôtes et aux chemins de la liste noire nécessitent une validation. Tous les autres hôtes et chemins peuvent être accédés directement. Cliquez sur Rule Condition pour définir des conditions basées sur le domaine de la requête, le chemin et les en-têtes. Domain Name : Le domaine hôte de la requête. Path : Le chemin de l'API demandée. Path Match Condition : Le chemin peut être mis en correspondance par correspondance exacte, correspondance de préfixe ou correspondance par expression régulière. Exact Match : Saisissez un chemin complet, par exemple /app/v1/order. Prefix Match : Saisissez un préfixe de chemin se terminant par un astérisque (). Par exemple, pour mettre en correspondance toutes les requêtes commençant par /app, saisissez /app/. Regular Expression Match : La syntaxe suit la norme Google RE2. Pour plus d'informations, consultez RE2 Syntax. Case sensitive : Rend la mise en correspondance des chemins sensible à la casse. Header : L'en-tête de la requête. Cliquez sur Request Header pour configurer plusieurs en-têtes. Une opération ET logique est effectuée sur les en-têtes. HeaderKey : Le nom du champ d'en-tête. Condition : La condition de mise en correspondance pour l'en-tête. Equals To : La valeur de l'en-tête spécifié est égale à la valeur saisie. Does Not Equal To : La valeur de l'en-tête spécifié n'est pas égale à la valeur saisie. Exists : L'en-tête spécifié existe dans la requête. Does Not Exist : L'en-tête spécifié n'existe pas dans la requête. Contains : La valeur de l'en-tête spécifié contient la valeur saisie. Excludes : La valeur de l'en-tête spécifié ne contient pas la valeur saisie. Prefix : La valeur de l'en-tête spécifié commence par la valeur saisie. Suffix : La valeur de l'en-tête spécifié se termine par la valeur saisie. Regular Expression Match : La valeur de l'en-tête spécifié correspond à l'expression régulière saisie. La syntaxe suit la norme Google RE2. Pour plus d'informations, consultez RE2 Syntax. Value : La valeur à comparer avec le champ d'en-tête.
   Complex Conditions	À côté de Authorization, cliquez sur Complex Conditions. Ce mode vous permet de définir des règles d'autorisation à l'aide d'une configuration YAML de la structure de données permission d'Envoy. Vous pouvez créer des règles avec une logique combinée ET, OU et NON. La passerelle envoie les requêtes correspondant aux conditions configurées pour authentification. Les requêtes non correspondantes peuvent accéder directement aux ressources. Remarque Pour une description complète des champs de la structure de données permission, consultez la documentation officielle d'Envoy. Pour des exemples de configuration, consultez Exemples d'autorisation avec conditions complexes.

   Revenez à la page Global Authentication. Si la nouvelle règle apparaît dans la liste, elle a été créée avec succès.

Consulter et gérer les services d'authentification

1. Connectez-vous à la console API Gateway.

2. Dans le volet de navigation de gauche, cliquez sur Cloud-native API Gateway > Instance. Dans la barre de navigation supérieure, sélectionnez une région.

3. Sur la page Instance, cliquez sur le nom de l'instance de passerelle cible.

4. Dans le volet de navigation de gauche, cliquez sur Security Management > Global Authentication.

5. Sur la page Authentication, recherchez la règle d'authentification cible et cliquez sur Description dans la colonne Actions. Vous pouvez consulter les Basic Information et la Authentication Configuration, et gérer les Authorization Information.

   La section Authentication Configuration comprend des champs tels que Authentication Service, Authentication API, Token Location, Timeout Period, Mode (tel que Loose Mode), Allow Body in Authentication Request, Allowed Headers in Authentication Request et Allowed Headers in Authentication Response. La section Authorization Information affiche le mode actuel (tel que Whitelist Mode). Plusieurs conditions de règle ont une relation logique « OU » entre elles. La liste des règles d'autorisation comprend des colonnes telles que Request Domain, Request Path Matchers, case-sensitive et Request Header Matchers.

   Dans la section Authorization Information, cliquez sur Create Authorization. Dans la boîte de dialogue qui s'affiche, saisissez le Request Domain Name et le Request Path, sélectionnez un Match Mode, puis cliquez sur OK pour ajouter la règle d'autorisation.

Opérations connexes

• Activer l'authentification et l'autorisation : Sur la page Global Authentication, recherchez la règle cible et cliquez sur Enable dans la colonne Actions pour l'activer.

• Désactiver l'authentification et l'autorisation : Sur la page Global Authentication, recherchez la règle cible et cliquez sur Close dans la colonne Actions pour la désactiver.

• Modifier l'authentification et l'autorisation : Sur la page Global Authentication, recherchez la règle cible et cliquez sur Edit dans la colonne Actions pour modifier sa configuration.

• Supprimer l'authentification et l'autorisation : Sur la page Global Authentication, recherchez la règle cible et cliquez sur Delete dans la colonne Actions pour la supprimer.

Exemples d'autorisation avec conditions complexes

permissions:
# and_rules: Triggers authentication if all the following rules are met.
- and_rules:
    rules:
      - url_path:
          # Path prefix matching.
          path:
            prefix: /
      - header:
          # Regular expression matching.
          safe_regex_match:
            regex: "(exampleA\\.com|exampleB\\.com)"
          # The domain name can be obtained from the ":authority" header,
          # according to the HTTP pseudo-header specification.
          name: ":authority"

permissions:
# or_rules: Triggers authentication if any of the following rules are met.
- or_rules:
    rules:
      # and_rules: This rule is met only if all the following sub-rules are met.
      # Rule 1
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/bbb/ccc
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      # Rule 2                
      - and_rules:
          rules:
            - url_path:
                path:
                  exact: /api/appc/ccc/ddd
            - header:
                exact_match: "exampleB.com"
                name: ":authority"
      - and_rules:
          rules:
            # Rule 3
            - url_path:
                path:
                  prefix: /api/
            # not_rule: Matches if the nested rule does not match.
            # Rule 4
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # Rule 5
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc                                
            - header:
                exact_match: "exampleA.com"
                name: ":authority"                                
      - and_rules:
          rules:
            # Rule 6
            - url_path:
                path:
                  prefix: /
            # not_rule: Matches if the nested rule does not match.
            # Rule 7
            - not_rule:
                url_path:
                  path:
                    exact: /api/appa/bbb
            # Rule 8
            - not_rule:
                url_path:
                  path:
                    exact: /api/appb/ccc
            # Rule 9
            - not_rule:
                url_path:
                  path:
                    prefix: /api/appc/                                         
            - header:
                exact_match: "exampleB.com"
                name: ":authority"