Ajout de plusieurs serveurs d'authentification au même déploiement d'API

Afin d'ajouter plusieurs serveurs d'authentification pour le même déploiement d'API à une spécification de déploiement d'API à l'aide de la console, procédez comme suit :

1. Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option Entièrement nouveau, puis saisissez les détails sur la page Informations de base.

   Pour plus d'informations, reportez-vous à Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et à Mise à jour d'une passerelle d'API.

2. Sélectionnez Suivant pour afficher la page Authentification.
3. Sélectionnez Authentification multiple pour indiquer que les demandes d'authentification doivent être acheminées vers différents serveurs d'authentification, en fonction de la variable de contexte et des règles que vous entrez :
   1. Dans la liste Sélecteur, sélectionnez la table de contexte (contenant la variable de contexte) à utiliser pour déterminer le serveur d'authentification auquel envoyer la demande d'authentification, comme suit :
      • Authentification : utilisez la valeur d'une réclamation contenue dans un jeton JWT (et enregistrée dans la table de contexte request.auth) pour déterminer le serveur d'authentification. Si vous sélectionnez Authentification, vous devez indiquer des serveurs d'authentification de type JWT (JSON Web Token) pour toutes les règles de serveur d'authentification dans le déploiement d'API. Si vous sélectionnez Authentification dans la liste Sélecteur, notez également que l'emplacement des JWT doit être le même pour tous les serveurs d'authentification JWT (JSON Web Token) (soit le même en-tête de demande et modèle d'autorisation, soit le même paramètre de requête).
      • En-têtes : utilisez la valeur d'un en-tête de la demande d'origine (et enregistrée dans la table de contexte request.headers) pour déterminer le serveur d'authentification.
      • Hôte : utilisez le nom de l'hôte auquel la demande d'origine a été envoyée (extrait du champ hôte de l'en-tête d'hôte de la demande et enregistré dans la table de contexte request.host) pour déterminer le serveur d'authentification.
      • Chemin : utilisez un paramètre de chemin de la demande d'origine (et enregistré dans la table de contexte request.path) pour déterminer le serveur d'authentification.
      • Paramètres de requête : utilisez la valeur d'un paramètre de requête de la demande d'origine (et enregistrée dans la table de contexte request.query) pour déterminer le serveur d'authentification.
      • Sous-domaine : utilisez la partie principale du nom d'hôte auquel la demande d'origine a été envoyée (c'est-à-dire la partie du nom d'hôte non spécifiée comme clé et enregistrée dans la table de contexte request.subdomain) pour déterminer le serveur d'authentification. Notez que la clé est la dernière partie du nom d'hôte à ne pas utiliser.
   2. Selon la table de contexte que vous sélectionnez, saisissez le nom de la clé à utiliser pour déterminer le serveur d'authentification auquel envoyer la demande d'authentification.
4. Sélectionnez Définir une stratégie pour entrer une règle pour la variable de contexte qui, si elle est remplie, achemine la demande d'authentification vers le serveur d'authentification que vous définissez.
5. Entrez les détails de la règle de serveur d'authentification comme suit :
   • Nom : Entrez le nom de la règle de serveur d'authentification. Utilisez le nom que vous entrez pour identifier le serveur d'authentification lorsqu'il fait référence aux journaux et aux mesures. Le nom doit être unique dans toutes les règles de serveur d'authentification définies pour le déploiement d'API.
   • Type de correspondance : indiquez dans quelle mesure la valeur de variable de contexte doit correspondre à une valeur que vous entrez pour que la demande soit acheminée vers ce serveur d'authentification. Sélectionnez Une des valeurs si la variable de contexte doit correspondre exactement à la valeur du champ Valeurs. Sélectionnez Caractère générique si la variable de contexte doit correspondre à une valeur du champ Expression contenant des caractères génériques. La mise en correspondance des valeurs n'est pas sensible à la casse si vous sélectionnez Une des valeurs, et la casse si vous sélectionnez Caractère générique.
   • Valeurs : (affiché si vous avez sélectionné Une valeur parmi dans le champ Type de correspondance.) Indiquez une valeur (ou plusieurs valeurs dans une liste séparée par des virgules) à laquelle la variable de contexte doit correspondre exactement. Notez que la correspondance n'est pas sensible à la casse si vous avez sélectionné Un des éléments. Notez également que les valeurs doivent être uniques au sein d'une règle de serveur d'authentification unique et dans toutes les règles de serveur d'authentification définies pour le déploiement d'API.
   • Expression : (affichée si vous avez sélectionné Caractère générique dans le champ Type de correspondance) Indiquez une valeur commençant par ou se terminant par un caractère générique auquel la variable de contexte doit correspondre. Utilisez le caractère générique * (astérisque) pour indiquer zéro ou plusieurs caractères, et/ou le caractère générique + (signe plus) pour indiquer un ou plusieurs caractères. Notez que la correspondance est sensible à la casse si vous avez sélectionné Caractère générique. Notez que vous ne pouvez pas inclure plusieurs caractères génériques dans une valeur et que vous ne pouvez pas inclure de caractères génériques au milieu d'une valeur.
   • Définir comme valeur par défaut : indiquez si le serveur d'authentification défini pour cette règle doit être utilisé si aucune autre règle de serveur d'authentification ne correspond à la valeur de variable de contexte. Vous ne pouvez indiquer qu'une seule règle de serveur d'authentification comme règle par défaut pour un déploiement d'API. Si aucune règle n'est marquée comme règle par défaut et que la valeur de variable de contexte dans une demande entrante ne correspond à aucune règle de serveur d'authentification définie pour un déploiement d'API, la demande renvoie une réponse d'erreur 401 Unauthorized.

6. Cochez ou désélectionnez la case Activer l'accès anonyme pour indiquer si les utilisateurs finals non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routages dans le déploiement d'API.

   Par défaut, cette option n'est pas sélectionnée. Si vous voulez que les utilisateurs anonymes ne puissent jamais accéder aux routages, ne sélectionnez pas cette option. Si vous sélectionnez cette option, vous devez également indiquer explicitement tous les routages auxquels l'accès anonyme est autorisé en sélectionnant Anonyme comme type d'autorisation dans la stratégie d'autorisation de chaque routage.

7. Entrez les détails du serveur d'authentification comme suit :
   1. Dans le champ Type d'authentification, sélectionnez JWT (JSON Web Token) ou Fonction d'autorisation comme serveur d'authentification vers lequel acheminer la demande d'authentification si la règle que vous avez entrée est satisfaite.

      Si vous avez sélectionné Authentification dans la liste Sélecteur, vous devez sélectionner le type de serveur d'authentification JWT (JSON Web Token). Si vous avez sélectionné Authentification dans la liste Sélecteur, notez également que l'emplacement des JWT doit être le même pour tous les serveurs d'authentification JWT (JSON Web Token) (soit le même en-tête de demande et modèle d'autorisation, soit le même paramètre de requête).

   2. Entrez les détails du serveur d'authentification que vous avez sélectionné. Les détails à saisir dépendent du type de serveur d'authentification que vous avez sélectionné :
      • Pour un serveur d'authentification par jeton Web JSON (JWT), reportez-vous à Utilisation de la console pour ajouter des stratégies de demande d'authentification et d'autorisation par jeton.
      • Pour un serveur d'authentification de fonction d'autorisation, indiquez le nom de la fonction d'autorisation, l'application dans OCI Functions qui la contient, puis sélectionnez Fonction d'autorisation à arguments multiples ou Fonction d'autorisation à arguments uniques. Pour plus d'informations, reportez-vous à :
        • Utilisation de la console afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation multi-arguments
        • Utilisation de la console afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation à un seul argument
   3. Sélectionnez Définir pour créer le serveur d'authentification et la règle associée.
8. Vous pouvez éventuellement sélectionner à nouveau Définir une stratégie pour définir des serveurs d'authentification supplémentaires et les règles associées.
9. Sélectionnez Suivant pour saisir les détails de chaque routage dans le déploiement d'API sur la page Routages.
10. Sélectionnez Enregistrer les modifications, puis Suivant afin de vérifier les détails saisis pour le déploiement d'API.
11. Sélectionnez Créer ou Enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
12. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).

Afin d'ajouter plusieurs serveurs d'authentification pour le même déploiement d'API à une spécification de déploiement d'API dans un fichier JSON, procédez comme suit :

1. A l'aide de l'éditeur JSON de votre choix, créez une spécification de déploiement d'API (reportez-vous à Création d'une spécification de déploiement d'API) au format suivant :

   {
     "requestPolicies": {
       "dynamicAuthentication": {
         "selectionSource": {
           "selector": "<context-table-key>",
           "type": "SINGLE"
         },
         "authenticationServers": [
           {
             "key": {
               "type": "<ANY_OF|WILDCARD>",
               "values": ["<context-variable-value>"],
               "isDefault": "<true|false>",
               "name": "<rule-name>"
             },
             "authenticationServerDetail": {
               "type": "<authentication-server-type>",
               "<auth-server-attribute-name>": "<auth-server-attribute-value>",
               ...
               "<auth-server-attribute-name>": "<auth-server-attribute-value>"
             }
           }
         ]
       }
     },
     "routes": []
   }

   où :

   • "dynamicAuthentication" indique que la passerelle d'API doit sélectionner dynamiquement le serveur d'authentification à utiliser pour authentifier les demandes, en fonction d'un élément de la demande.
   • "selector": "<context-table-key>" indique la table de contexte (et la clé, le cas échéant) à partir de laquelle obtenir la valeur de variable de contexte qui détermine le serveur d'authentification auquel envoyer les demandes d'authentification, comme suit :
     • request.auth[<key>] Utilisez la valeur d'une réclamation contenue dans un jeton Web JSON (JWT) pour déterminer le serveur d'authentification. <key> est le nom de la réclamation. Par exemple, request.auth[tenant]. Si vous indiquez request.auth[<key>], vous devez indiquer des serveurs d'authentification de type JWT_AUTHENTICATION pour toutes les règles de serveur d'authentification dans le déploiement d'API. Si vous indiquez request.auth[<key>], l'emplacement des jetons JWT doit être le même pour tous les serveurs d'authentification (le même en-tête de demande et le même modèle d'autorisation, ou le même paramètre de requête).
     • request.headers[<key>] Utilisez la valeur d'un en-tête de la demande d'origine pour déterminer le serveur d'authentification. <key> est le nom de l'en-tête. Par exemple, request.headers[Accept]
     • request.host Utilisez le nom de l'hôte auquel la demande d'origine a été envoyée (extrait du champ hôte de l'en-tête de l'hôte dans la demande) pour déterminer le serveur d'authentification.
     • request.path[<key>] Utilisez un paramètre de chemin de la demande d'origine pour déterminer le serveur d'authentification. <key> est le nom du paramètre de chemin. Par exemple, request.path[region]
     • request.query[<key>] Utilisez la valeur d'un paramètre de requête de la demande d'origine pour déterminer le serveur d'authentification. <key> est le nom du paramètre de requête. Par exemple, request.query[state].
     • request.subdomain[<key>] Utilisez la première partie du nom d'hôte auquel la demande d'origine a été envoyée (la seule partie du nom d'hôte non spécifiée en tant que clé) pour déterminer le serveur d'authentification. <key> est la dernière partie du nom d'hôte à ne pas utiliser. Par exemple, request.subdomain[example.com]
   • "type": "SINGLE" indique que vous voulez utiliser une seule variable de contexte pour sélectionner dynamiquement le serveur d'authentification.
   • "key": {...} indique la règle à respecter pour envoyer une demande au serveur d'authentification indiqué par "authenticationServerDetail": {…}.
   • "type": "<ANY_OF|WILDCARD>" indique dans quelle mesure la valeur de la variable de contexte identifiée par <context-table-key> doit correspondre à la valeur saisie pour <context-variable-value> afin que la demande soit envoyée au serveur d'authentification indiqué par "authenticationServerDetail": {…}. Indiquez ANY_OF si la valeur de la variable de contexte identifiée par <context-table-key> doit correspondre exactement à la valeur indiquée pour <context-variable-value>. Indiquez WILDCARD si la valeur de la variable de contexte identifiée par <context-table-key> doit correspondre à une valeur contenant des caractères génériques que vous indiquez pour <context-variable-value>. La mise en correspondance des valeurs ne fait pas la distinction entre les majuscules et les minuscules si vous indiquez ANY_OF et la casse si vous indiquez WILDCARD.
   • <context-variable-value> est une valeur qui peut correspondre à la valeur de la variable de contexte identifiée par <context-table-key>. Vous pouvez inclure plusieurs entrées "<context-variable-value>" dans le tableau values:[...], séparées par des virgules. La demande est envoyée au serveur d'authentification indiqué par "authenticationServerDetail": {…} si les valeurs correspondent, comme suit :
     • Si vous avez spécifié "type": "ANY_OF", les valeurs doivent correspondre exactement. Notez que les valeurs doivent être uniques dans une règle de serveur d'authentification unique et dans toutes les règles de serveur d'authentification définies pour un déploiement d'API. La correspondance de valeur ne fait pas la distinction entre les majuscules et les minuscules si vous avez spécifié ANY_OF.
     • Si vous avez spécifié "type": "WILDCARD", vous pouvez indiquer une valeur pour <context-variable-value> qui commence par ou se termine par un caractère générique. Utilisez le caractère générique * (astérisque) pour indiquer zéro ou plusieurs caractères, et/ou le caractère générique + (signe plus) pour indiquer des caractères. Notez que vous ne pouvez pas inclure plus d'un caractère générique dans une valeur et que vous ne pouvez pas inclure un caractère générique au milieu d'une valeur. La mise en correspondance des valeurs respecte la casse si vous avez spécifié WILDCARD.
     Par exemple, si vous souhaitez qu'une demande d'un client API capable d'accepter une réponse xml (comme indiqué dans l'en-tête Accepter de la demande) soit acheminée vers un serveur d'authentification particulier, vous pouvez spécifier :
     • "selector": "request.headers[Accept]"
     • "type": "ANY_OF"
     • "values": ["application/xml"]
   • "isDefault": "<true|false>" est une valeur booléenne facultative (true ou false) indiquant si le serveur d'authentification doit être utilisé pour cette règle si aucune autre règle de serveur d'authentification ne correspond à la valeur de variable de contexte. Si aucune valeur n'est indiquée, "isDefault": "false" est utilisé. Vous ne pouvez indiquer qu'une seule règle de serveur d'authentification comme règle par défaut pour un déploiement d'API. Si aucune règle n'est marquée comme règle par défaut et que la valeur de variable de contexte dans une demande entrante ne correspond à aucune règle de serveur d'authentification définie pour un déploiement d'API, la demande renvoie une réponse d'erreur 401 Unauthorized.
   • "name": "<rule-name>" indique le nom de la règle. Utilisez ce nom pour identifier le serveur d'authentification lors de la référence aux journaux et aux mesures. Le nom doit être unique dans toutes les règles de serveur d'authentification définies pour le déploiement d'API.
   • "type": "<authentication-server-type>" indique le type du serveur d'authentification. Les valeurs valides sont JWT_AUTHENTICATION et CUSTOM_AUTHENTICATION. Si vous avez indiqué request.auth[<key>], vous devez indiquer des serveurs d'authentification de type JWT_AUTHENTICATION pour toutes les règles de serveur d'authentification dans le déploiement d'API. Si vous avez spécifié request.auth[<key>], l'emplacement des jetons JWT doit être le même pour tous les serveurs d'authentification (le même en-tête de demande et le même modèle d'autorisation, ou le même paramètre de requête).
   • "<auth-server-attribute-name>": "<auth-server-attribute-value>" sont des attributs et des valeurs d'attribut pour le type de serveur d'authentification indiqué. Les attributs et les valeurs d'attribut à saisir dépendent du type de serveur d'authentification que vous avez indiqué :
     • pour un serveur d'authentification JWT_AUTHENTICATION, reportez-vous à Modification d'un fichier JSON afin d'ajouter des stratégies de demande d'autorisation et d'authentification par jeton
     • pour un serveur d'authentification CUSTOM_AUTHENTICATION, reportez-vous aux sections suivantes :
       • Modification d'un fichier JSON afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation multi-arguments
       • Modification d'un fichier JSON afin d'ajouter des stratégies de demande pour l'authentification et l'autorisation à un seul argument

   Par exemple, la spécification de déploiement d'API suivante inclut une sélection de serveur d'authentification dynamique qui gère les demandes d'authentification en fonction de la valeur du paramètre de requête vehicle-type transmis dans la demande. Pour obtenir une explication plus détaillée de cet exemple, reportez-vous à l'Exemple 1 : sélection de JWT ou d'une fonction sans serveur en tant que serveur d'authentification à l'aide d'un paramètre de requête (y compris la sélection de caractères génériques et par défaut).

   {
     "requestPolicies": {
       "dynamicAuthentication": {
         "selectionSource": {
           "selector": "request.query[vehicle-type]",
           "type": "SINGLE"
         },
         "authenticationServers": [
           {
             "key": {
               "type": "ANY_OF",
               "values": ["car"],
               "isDefault": "true",
               "name": "authServer1"
             },
             "authenticationServerDetail": {
               "type": "JWT_AUTHENTICATION",
               "tokenHeader": "Authorization",
               "tokenAuthScheme": "Bearer",
               "isAnonymousAccessAllowed": true,
               "issuers": ["https://recommend-app.eu.auth0.com/"],
               "audiences": ["api.dev.io"],
               "maxClockSkewInSeconds": 0,
               "verifyClaims": [
                 {
                   "key": "gty",
                   "value": ["client-credentials"],
                   "isRequired": true
                 }
               ],
               "publicKeys": {
                 "type": "REMOTE_JWKS",
                 "uri": "https://recommend-app.eu.auth0.com/.well-known/jwks.json",
                 "maxCacheDurationInHours": 1
               }
             }
           },
           {
             "key": {
               "type": "WILDCARD",
               "expression": "mini*",
               "name": "authServer2"
             },
             "authenticationServerDetail": {
               "type": "CUSTOM_AUTHENTICATION",
               "functionId": "ocid1.fnfunc.oc1.iad.aaaaaaaaac______dfa",
               "isAnonymousAccessAllowed": true
             }
           }
         ]
       }
     },
     "routes": []
   }

2. Enregistrez le fichier JSON qui contient la spécification de déploiement d'API.

3. Utilisez la spécification de déploiement d'API lorsque vous créez ou mettez à jour un déploiement d'API en :

   • spécifiant le fichier JSON dans la console lorsque vous sélectionnez l'option Télécharger une API existante,
   • spécifiant le fichier JSON dans une demande adressée à l'API REST d'API Gateway.

   Pour plus d'informations, reportez-vous à Déploiement d'une API sur une passerelle d'API en créant un déploiement d'API et à Mise à jour d'une passerelle d'API.

4. (Facultatif) Vérifiez que l'API a été déployée en l'appelant (reportez-vous à Appel d'une API déployée sur une passerelle d'API).