Ajout de politiques de demande d'authentification et d'autorisation

Découvrez comment ajouter des politiques de demande pour fournir l'authentification et l'autorisation avec la passerelle d'API.

Vous pouvez ajouter des politiques de demande pour fournir l'authentification et l'autorisation à l'aide des éléments suivants :

jetons d'accès à plusieurs arguments définis par l'utilisateur transmis aux fonctions d'autorisation à plusieurs arguments (voir Ajout de politiques d'authentification et de demande d'autorisation pour les jetons d'accès à plusieurs arguments et les fonctions d'autorisation (recommandé))
jetons d'accès à un seul argument transmis aux fonctions d'autorisation à un seul argument (voir Ajout de politiques d'authentification et de demande d'autorisation pour les jetons d'accès à un seul argument et les fonctions d'autorisation)

Ajout de politiques de demande d'authentification et d'autorisation pour les jetons d'accès sous plusieurs arguments et les fonctions d'autorisation (recommandé)

Vous pouvez ajouter des politiques de demande pour fournir l'authentification et l'autorisation à l'aide de jetons d'accès à plusieurs arguments définis par l'utilisateur et de fonctions d'autorisation à plusieurs arguments :

Utilisation de la console pour ajouter des politiques de demande pour l'authentification et l'autorisation sous plusieurs arguments

Pour ajouter des politiques de demande d'authentification et d'autorisation pour des jetons d'accès à plusieurs arguments à une spécification de déploiement d'API à l'aide de la console :

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.

Pour plus d'informations, voir 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.
Sélectionnez Suivant pour afficher la page Authentification.
Sélectionnez Authentification unique pour spécifier que vous voulez utiliser un seul serveur d'authentification pour toutes les demandes.

Ces instructions supposent que vous souhaitez utiliser un seul serveur d'authentification. Sinon, si vous voulez utiliser plusieurs serveurs d'authentification, sélectionnez Authentification multiple et suivez les instructions sous Utilisation de la console pour ajouter plusieurs serveurs d'authentification au même déploiement d'API.
Cochez ou désélectionnez la case Activer l'accès anonyme : pour spécifier si les utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes du déploiement d'API.

Par défaut, cette option n'est pas sélectionnée. Si vous voulez que des utilisateurs anonymes ne puissent jamais accéder aux routes, ne sélectionnez pas cette option. Notez que si vous sélectionnez cette option, vous devez également spécifier explicitement toutes les routes pour lesquelles un accès anonyme est autorisé en sélectionnant Anonyme comme Type d'autorisation dans la politique d'autorisation de chaque route.
Sélectionnez Fonction d'autorisation dans la liste d'options Type d'authentification.
Spécifiez la fonction d'autorisation à plusieurs arguments à utiliser pour authentifier le jeton d'accès à plusieurs arguments :
- Application Oracle Functions dans <compartiment-nom> : Nom de l'application du service des fonctions pour OCI, qui contient la fonction d'autorisation. Vous pouvez sélectionner une application dans un compartiment différent.
- Nom de la fonction : Nom de la fonction d'autorisation du service des fonctions pour OCI.
Sélectionnez Fonction d'autorisation à plusieurs arguments pour spécifier que vous voulez transmettre un ou plusieurs éléments d'une demande en tant que jeton d'accès à une fonction d'autorisation qui peut accepter des jetons d'accès à plusieurs arguments.
Dans le panneau Arguments de fonction, spécifiez une ou plusieurs variables de contexte fournissant des valeurs à transmettre à la fonction d'autorisation en tant qu'arguments avec les noms d'argument que vous entrez :
1. Spécifiez une variable de contexte fournissant une valeur à transmettre à la fonction d'autorisation en tant qu'argument :
  - Table de contexte : Sélectionnez dans la liste la table de contexte contenant la variable de contexte :
    - Table de contexte request.query, contenant les noms et les valeurs des paramètres d'interrogation inclus dans la demande
    - Table de contexte request.headers, contenant les noms d'en-tête et les valeurs incluses dans la demande
    - Table de contexte request.cert, contenant une version encodée par Base64 du certificat présenté par un client d'API et validée avec succès lors d'une liaison mTLS
    - Table de contexte request.host, contenant le nom de l'hôte auquel la demande a été envoyée (extrait du champ d'en-tête Host dans la demande)
    - Table de contexte request.body, contenant le corps de la demande
  - Nom d'en-tête ou Nom du paramètre d'interrogation : Si vous avez sélectionné la table de contexte request.headers ou request.params, entrez le nom du paramètre d'en-tête ou d'interrogation à transmettre à la fonction d'autorisation. Par exemple X-Api-Key, state.
  - Nom de l'argument : Entrez le nom de l'argument auquel affecter la valeur de la variable de contexte. L'argument est transmis à la fonction d'autorisation. Le nom d'argument que vous entrez doit correspondre au nom d'argument que la fonction d'autorisation attend recevoir.
2. Spécifiez des variables de contexte et des arguments supplémentaires si nécessaire (sélectionnez Un autre argument si nécessaire).
Facultativement, personnalisez la façon de mettre en mémoire cache la réponse à partir d'une fonction d'autorisation à plusieurs arguments :
1. Sélectionnez Afficher les options avancées.
  Le panneau Mise en mémoire cache des résultats de la fonction indique les arguments présents dans la clé de mémoire cache. La clé de cache identifie de manière unique la réponse en mémoire cache retournée par la fonction d'autorisation, à l'aide des arguments et des valeurs d'argument transmis dans la demande d'authentification initiale. Par défaut, tous les arguments et valeurs d'argument (à l'exception d'un argument avec une valeur de la table de contexte request.body) que vous avez spécifiés pour transmettre à la fonction d'autorisation sont utilisés pour créer la clé de mémoire cache.
2. Pour ajouter ou supprimer des arguments de la clé de mémoire cache, sélectionnez Modifier.
3. Sélectionnez ou désélectionnez les arguments transmis à la fonction d'autorisation pour les inclure ou les exclure de la clé de cache.
Voir Notes sur la mise en mémoire cache des résultats de fonction d'autorisation à plusieurs arguments.
Facultativement, personnalisez la façon de traiter une réponse d'authentification en échec à partir d'une fonction d'autorisation à plusieurs arguments en configurant une politique d'échec de validation :
1. Sélectionnez Afficher les options avancées.
  Le panneau Réponse personnalisée en cas d'échec de l'authentification. affiche le code de statut HTTP et le corps du message à retourner au client d'API si la fonction d'autorisation ne peut pas authentifier la demande. Par défaut, la passerelle d'API envoie un code de statut HTTP 401 et l'en-tête WWW-Authenticate dans la réponse. Voir Notes sur les politiques d'échec de validation et le traitement des réponses d'authentification ayant échoué à partir de fonctions d'autorisation à plusieurs arguments.
2. Spécifiez un code de statut (et un corps de message facultatif) à retourner au client d'API si la fonction d'autorisation ne peut pas authentifier la demande :
  - Code de statut HTTP : Entrez un autre code de statut HTTP (par exemple, 500). Vous pouvez également inclure une variable de contexte pour renvoyer le code retourné par la fonction d'autorisation. Par exemple, si la fonction d'autorisation retourne un code de réponse dans le paramètre responseCode, spécifiez request.auth[responseCode].
  - Corps du message : Entrez un corps de message. Par exemple, Unfortunately, authentication failed.Le corps du message peut inclure n'importe quelle variable de contexte (à l'exception de request.body). Par exemple, Unfortunately, authentication failed ${request.auth[my-auth-variable]}.
3. Facultativement, modifiez les en-têtes de la réponse retournée par la passerelle d'API au client d'API en sélectionnant Afficher les options avancées et en spécifiant une politique de réponse de transformation d'en-tête :
  - Pour limiter les en-têtes inclus dans une réponse, spécifiez les données suivantes :
    - Action : Filtrer.
    - Type : Bloquer pour supprimer de la réponse les en-têtes que vous listez explicitement ou Autoriser pour autoriser uniquement dans la réponse les en-têtes que vous listez explicitement (tous les autres en-têtes sont supprimés de la réponse).
    - Noms d'en-tête : Liste des en-têtes à supprimer ou à autoriser pour la réponse (selon le paramètre Type). Les noms que vous spécifiez ne sont pas sensibles à la casse et ne doivent pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple User-Agent.
  - Pour modifier le nom d'un en-tête inclus dans une réponse (tout en conservant sa valeur initiale), spécifiez les données suivantes :
    - Action : Renommer.
    - Nom d'en-tête : Nom initial de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route. Par exemple X-Username.
    - Nom du nouvel en-tête : Nouveau nom de l'en-tête que vous renommez. Le nom que vous spécifiez n'est pas sensible à la casse (la capitalisation peut être ignorée) et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments des listes ALLOW). Par exemple X-User-ID.
  - Pour ajouter un nouvel en-tête à une réponse (ou pour modifier ou conserver les valeurs d'un en-tête existant déjà inclus dans une réponse), spécifiez les données suivantes :
    - Action : Définir.
    - Comportement : Si l'en-tête existe déjà, spécifiez ce qu'il faut faire avec la valeur existante de l'en-tête :
      - Remplacer, pour remplacer la valeur existante de l'en-tête par la valeur que vous spécifiez.
      - Ajouter, pour ajouter la valeur que vous spécifiez à la valeur existante de l'en-tête.
      - Ignorer, pour conserver la valeur existante de l'en-tête.
    - Nom d'en-tête : Nom de l'en-tête à ajouter à la réponse (ou pour en modifier la valeur). Le nom que vous spécifiez n'est pas sensible à la casse et ne doit pas être inclus dans d'autres politiques de réponse de transformation pour la route (à l'exception des éléments filtrés comme étant autorisés). Par exemple X-Api-Key.
    - Valeurs : Valeur du nouvel en-tête (ou valeur à remplacer ou à ajouter à la valeur d'un en-tête existant, selon le paramètre Comportement). Vous pouvez spécifier plusieurs valeurs. La valeur que vous spécifiez peut être une chaîne simple ou peut inclure des variables de contexte (à l'exception de request.body) entourées des délimiteurs ${...}. Par exemple "value": "zyx987wvu654tsu321".
  Pour plus d'informations sur les politiques de réponse de transformation d'en-tête, voir Ajout de politiques de réponse de transformation d'en-tête
Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
Dans la section Route 1, spécifiez la première route du déploiement d'API qui mappe un chemin et une ou plusieurs méthodes à un service dorsal :
- Chemin : Chemin des appels d'API utilisant les méthodes indiquées au service dorsal. Notez que le chemin de routage que vous spécifiez :
  - Est relatif au préfixe du chemin de déploiement.
  - Doit être précédé d'une barre oblique (/) et peut être simplement cette seule barre oblique.
  - Peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes) et peut se terminer par une barre oblique.
  - Peut inclure des caractères alphanumériques en majuscules et en minuscules.
  - peut inclure les caractères spéciaux $ - _ . + ! * ' ( ) , % ; : @ & =
  - Peut inclure des paramètres et des caractères génériques (voir Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
- Méthodes : Une ou plusieurs méthodes acceptées par le service dorsal, séparées par des virgules. Par exemple, GET, PUT.
- Ajouter un seul serveur dorsal ou Ajouter plusieurs serveurs dorsaux : Indique s'il faut acheminer toutes les demandes vers le même serveur dorsal ou acheminer les demandes vers différents serveurs dorsaux en fonction de la variable de contexte et des règles que vous entrez.
  
  Ces instructions supposent que vous voulez utiliser un seul élément dorsal. Sélectionnez donc Ajouter un seul élément dorsal. Sinon, si vous voulez utiliser des éléments dorsaux différents, sélectionnez Ajouter plusieurs éléments dorsaux et suivez les instructions sous Utilisation de la console pour ajouter une sélection d'élément dorsal dynamique à une spécification de déploiement d'API.
- Type dorsal : Type du service dorsal, parmi l'un des suivants :
  - HTTP : Pour un élément dorsal HTTP, vous devez également spécifier une URL, les détails de temporisation et déterminer s'il faut désactiver ou non la vérification SSL (voir Ajout d'une URL HTTP ou HTTPS comme élément dorsal du service de passerelle d'API).
  - Oracle Functions : Pour un élément dorsal du service des fonctions pour OCI, vous devez également spécifier l'application et la fonction (voir Ajout d'une fonction du service des fonctions pour OCI en tant qu'élément dorsal du service de passerelle d'API).
  - Réponse standard : Pour un élément dorsal de réponse standard, vous devez également spécifier le code de statut HTTP, le contenu du corps de la réponse et un ou plusieurs champs d'en-tête HTTP (voir Ajout de réponses standard comme élément dorsal du service de passerelle d'API).
Pour spécifier une politique d'autorisation qui s'applique à une route individuelle, sélectionnez Afficher les politiques de demande de routage, sélectionnez le bouton Ajouter à côté du champ Autorisation, puis spécifiez les données suivantes :
- Type d'autorisation : Comment accorder l'accès à la route. Spécifiez les données suivantes :
  - Au choix : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si la fonction d'autorisation a également retourné une des étendues d'accès que vous spécifiez dans le champ Étendue autorisée. Dans ce cas, l'option Activer l'accès anonyme de la politique d'authentification n'a aucun effet.
  - Anonyme : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés par la fonction d'autorisation. Dans ce cas, vous devez avoir sélectionné l'option Activer l'accès anonyme de la politique d'authentification.
  - Authentification uniquement : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés par la fonction d'autorisation. Dans ce cas, l'option Activer l'accès anonyme de la politique d'authentification n'a aucun effet.
- Étendue autorisée : Si vous avez sélectionné Au choix comme Type d'autorisation, indiquez une liste délimitée par des virgules contenant une ou plusieurs chaînes correspondant aux étendues d'accès retournées par la fonction d'autorisation. L'accès ne sera accordé qu'aux utilisateurs finaux qui ont été authentifiés si la fonction d'autorisation retourne une des étendues d'accès que vous spécifiez. Par exemple, read:hello.
Note

Si vous n'incluez pas de politique d'autorisation pour une route particulière, l'accès est accordé comme si une telle politique existait et le type d'autorisation est réglé à Authentification uniquement. Autrement dit, quel que soit le paramètre de l'option Activer l'accès anonyme de la politique d'authentification :
- Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
- Tous les utilisateurs finaux authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès retournées par la fonction d'autorisation.
- Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.
Sélectionnez Appliquer les modifications, puis sélectionnez Suivant pour vérifier les détails que vous avez entrés pour le déploiement d'API.
Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter des politiques de demande pour l'authentification et l'autorisation sous plusieurs arguments

Pour ajouter des politiques de demande d'authentification et d'autorisation pour des jetons d'accès à plusieurs arguments à une spécification de déploiement d'API dans un fichier JSON :

Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter les fonctionnalités d'authentification et d'autorisation ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).

Au minimum, la spécification de déploiement d'API inclura une section routes contenant les éléments suivants :
- Un chemin. Par exemple /hello.
- Une ou plusieurs méthodes. Par exemple GET
- La définition d'un élément dorsal. Par exemple, une URL ou l'OCID d'une fonction du service des fonctions pour OCI.
Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Ajoutez une politique de demande authentication qui s'applique à toutes les routes de la spécification de déploiement d'API :
1. Insérez une section requestPolicies avant la section routes, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
2. Ajoutez la politique authentication suivante à la nouvelle section requestPolicies.
```
{
  "requestPolicies": {
    "authentication": {
      "type": "<type-value>",
      "isAnonymousAccessAllowed": <true|false>,
      "functionId": "<function-ocid>",
      "parameters": {
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>"
      },
      "cacheKey": [
        "<cache-key-argument-n>", "<cache-key-argument-n>"
      ]
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - <type-value> est le type d'authentification. Pour utiliser une fonction d'autorisation pour l'authentification, spécifiez CUSTOM_AUTHENTICATION.
  - "isAnonymousAccessAllowed": <true|false> indique facultativement si des utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes de la spécification de déploiement d'API. Si vous voulez que des utilisateurs finaux anonymes ne puissent jamais accéder aux routes, réglez cette propriété à false. Si vous n'incluez pas cette propriété dans la politique authentication, la valeur par défaut false est utilisée. Notez que si vous n'incluez pas cette propriété et que vous la réglez à true, vous devez également spécifier explicitement toutes les routes auxquelles l'accès anonyme est autorisé en réglant la propriété type à "ANONYMOUS" dans la politique authorization de chaque route.
  - <function-ocid> est l'OCID de la fonction d'autorisation déployée dans le service des fonctions pour OCI.
  - <argument-n> est le nom de l'argument auquel affecter la valeur d'une variable de contexte et d'une seule. L'argument est transmis à la fonction d'autorisation. Le nom d'argument que vous entrez doit correspondre au nom d'argument que la fonction d'autorisation attend recevoir. Vous pouvez inclure plusieurs paires de variables argument-contexte.
  - <context-variable> est une variable de contexte dont la valeur doit être affectée à l'argument correspondant. <context-variable> doit être dans le format <context-table-name> ou <context-table-name>[<key>], où <context-table-name> est l'un des suivants :
    - request.query, une table de contexte contenant les noms et les valeurs des paramètres d'interrogation inclus dans la demande. Si vous voulez spécifier un paramètre d'interrogation, vous devez spécifier à la fois la table de contexte request.query et le nom du paramètre d'interrogation en tant que clé, dans le format request.query[<query-parameter-name>]. Par exemple, request.query[state]
    - request.headers, une table de contexte contenant les noms d'en-tête et les valeurs incluses dans la demande. Si vous voulez spécifier un en-tête, vous devez spécifier à la fois la table de contexte request.headers et le nom de l'en-tête en tant que clé, dans le format request.headers[<header-name>]. Par exemple request.headers[X-Api-Key]
    - Table de contexte request.cert, contenant une version encodée par Base64 du certificat présenté par un client d'API et validée avec succès lors d'une liaison mTLS
    - request.host, une table de contexte contenant le nom de l'hôte auquel la demande a été envoyée (extrait du champ d'en-tête Host dans la demande)
    - request.body, une table de contexte contenant le corps de la demande.
  - "cacheKey": ["<cache-key-argument-n>", "<cache-key-argument-n>"] limite facultativement la clé de cache à l'utilisation uniquement des arguments que vous spécifiez. La clé de cache identifie de manière unique la réponse en mémoire cache retournée par la fonction d'autorisation, à l'aide des arguments et des valeurs d'argument transmis dans la demande d'authentification initiale. Par défaut, tous les arguments et valeurs d'argument (à l'exception d'un argument ayant une valeur de la table de contexte request.body) de la liste parameters: {…} sont utilisés pour créer la clé de mémoire cache. Un argument que vous spécifiez pour <cache-key-argument-n> doit être l'un des arguments de la liste parameters: {…}. Voir Notes sur la mise en mémoire cache des résultats de fonction d'autorisation à plusieurs arguments.
3. Facultativement, ajoutez une valeur validationFailurePolicy à la section de politique authentication :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "<type-value>",
      "isAnonymousAccessAllowed": <true|false>,
      "functionId": "<function-ocid>",
      "parameters": {
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>",
        "<argument-n>": "<context-variable>"
      },
      "cacheKey": [
        "<cache-key-argument-n>", "<cache-key-argument-n>"
      ],
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "<alternative-response-code>",
        "responseMessage": "<custom-message-body>",
        "responseTransformations": {
          "headerTransformations": {
            <valid-header-transformation-response-policy>
          }
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - "validationFailurePolicy": {…} vous permet facultativement de modifier le code de statut HTTP, le corps du message et les en-têtes dans la réponse au client d'API si la fonction d'autorisation ne peut pas authentifier une demande. Par défaut, la passerelle d'API envoie un code de statut HTTP 401 et l'en-tête WWW-Authenticate dans la réponse. Voir Notes sur les politiques d'échec de validation et le traitement des réponses d'authentification ayant échoué à partir de fonctions d'autorisation à plusieurs arguments.
  - <policy-type> est le type de politique en cas d'échec de validation. Pour modifier la réponse, spécifiez MODIFY_RESPONSE.
  - "responseCode": "<alternative-response-code>" spécifie un autre code de statut HTTP. Par exemple, "responseCode": "500". Vous pouvez également inclure une variable de contexte pour renvoyer le code retourné par la fonction d'autorisation. Par exemple, si la fonction d'autorisation retourne un code de réponse dans le paramètre responseCode, spécifiez "request.auth[responseCode]".
  - "responseMessage": "<custom-message-body>" spécifie le contenu à inclure dans le corps du message. Par exemple, "responseMessage": "Unfortunately, authentication failed.". Le corps du message peut inclure n'importe quelle variable de contexte (à l'exception de request.body). Par exemple, "responseMessage": "Unfortunately, authentication failed ${request.auth[my-auth-variable]}".
  - "headerTransformations": {<valid-header-transformation-response-policy>} est une politique de réponse de transformation d'en-tête valide. Voir Modification d'un fichier JSON pour ajouter des politiques de réponse de transformation d'en-tête.
Ajoutez une politique de demande authorization pour chaque route de la spécification de déploiement d'API :
1. Insérez une section requestPolicies après la section backend de la première route, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      .
      .
      .
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}
```
2. Ajoutez la politique authorization suivante à la section requestPolicies :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      .
      .
      .
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
    }
  ]
}
```
  où :
  - "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indique comment accorder l'accès à la route :
    - "AUTHENTICATION_ONLY" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANY_OF" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si la fonction d'autorisation a également retourné une des étendues d'accès que vous spécifiez dans la propriété allowedScope. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANONYMOUS" : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés. Dans ce cas, vous devez explicitement régler la propriété "isAnonymousAccessAllowed" à true dans la politique authentication de la spécification de déploiement d'API.
  - "allowedScope": [ "<scope>" ] est une liste délimitée par des virgules, contenant une ou plusieurs chaînes correspondant aux étendues d'accès retournées par la fonction d'autorisation. Dans ce cas, vous devez régler la propriété type à "ANY_OF" (la propriété "allowedScope" est ignorée si la propriété type est réglée à "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Notez également que si vous spécifiez plusieurs étendues, l'accès à la route est accordé si l'une des étendues que vous spécifiez est retournée par la fonction d'autorisation.
  Par exemple, la politique de demande suivante définit une route /hello qui autorise uniquement les utilisateurs finaux authentifiés avec l'étendue read:hello à y accéder :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      .
      .
      .
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}
```
3. Ajoutez une politique de demande authorization pour toutes les routes restantes de la spécification de déploiement d'API.
Note

Si vous n'incluez pas de politique authorization pour une route particulière, l'accès est accordé comme si une telle politique existe et la propriété type est réglée à "AUTHENTICATION_ONLY". Autrement dit, quelle que soit la définition de la propriété isAnonymousAccessAllowed dans la politique authentication de la spécification de déploiement d'API :
- Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
- Tous les utilisateurs finaux authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès retournées par la fonction d'autorisation.
- Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.
Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
Utilisez comme suit 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 Charger une API existante.
- En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.
Pour plus d'informations, voir 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.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Notes sur l'utilisation des fonctions d'autorisation à plusieurs arguments et des jetons d'accès

Notes sur la mise en cache des résultats de la fonction d'autorisation à plusieurs arguments

Lors de l'utilisation de fonctions d'autorisation, la passerelle d'API met en mémoire cache la réponse de la fonction d'autorisation par défaut. La mise en cache de la réponse permet de la réutiliser ultérieurement pour répondre à une demande d'authentification similaire, sans appeler à nouveau la fonction d'autorisation.

Pour identifier de manière unique une réponse en mémoire cache retournée par une fonction d'autorisation pour une demande d'authentification, la passerelle d'API utilise une clé de cache dérivée des arguments et des valeurs d'argument transmis à la fonction d'autorisation qui a déclenché la réponse. Si les valeurs d'argument et d'argument d'une demande d'authentification ultérieure correspondent à une clé de cache, la réponse mise en cache est utilisée au lieu d'appeler inutilement la fonction d'autorisation.

Dans le cas des fonctions d'autorisation à plusieurs arguments, par défaut, tous les arguments et les valeurs d'argument (à l'exception d'un argument avec une valeur de la table de contexte request.body) transmis à la fonction d'autorisation sont utilisés pour créer la clé de mémoire cache. Toutefois, vous pouvez personnaliser les arguments et les valeurs d'argument utilisés pour créer la clé de cache, de sorte que la clé de cache inclut uniquement les arguments et les valeurs d'argument que vous spécifiez. Notez que si vous supprimez des arguments et des valeurs d'argument de la clé de cache, vous risquez d'introduire le risque qu'une demande d'authentification non valide entrante corresponde à la clé de cache d'une réponse précédente à une demande authentifiée avec succès. Supprimez uniquement les arguments de la clé de cache si vous êtes sûr que ces arguments n'ont aucun rôle dans l'authentification de la demande.

Notes sur les politiques d'échec de validation et le traitement des réponses d'authentification en échec à partir de fonctions d'autorisation à plusieurs arguments

Lorsque vous utilisez une fonction d'autorisation à plusieurs arguments, vous pouvez définir une stratégie d'échec de validation. Une politique d'échec de validation vous permet de personnaliser le code de statut HTTP, les en-têtes de message et de réponse que la passerelle d'API envoie à un client d'API en cas d'échec d'une réponse d'authentification à partir d'une fonction d'autorisation à plusieurs arguments.

Une fonction d'autorisation à plusieurs arguments doit retourner une réponse HTTP 200 (avec le corps JSON de la réponse contenant "active": false et un en-tête WWW-Authenticate) si un jeton d'accès a été vérifié avec succès auprès d'un fournisseur d'identités, mais le fournisseur d'identités a déterminé que le jeton n'est pas valide,

Si la fonction d'autorisation retourne une réponse HTTP 200 avec "active": false dans le corps de la réponse, la passerelle d'API envoie par défaut un code de statut HTTP 401 au client d'API (ainsi que l'en-tête WWW-Authenticate dans la réponse). Toutefois, vous pouvez définir une politique d'échec de validation pour spécifier un code de statut HTTP différent à retourner et pour spécifier un message personnalisé à retourner dans le corps de la réponse.

Vous pouvez également inclure une politique de réponse de transformation d'en-tête dans une politique d'échec de validation pour modifier l'en-tête de la réponse retournée par la passerelle d'API au client d'API. En incluant une politique de réponse de transformation d'en-tête dans une politique d'échec de validation, vous pouvez :

limiter les en-têtes inclus dans une réponse
modifier le nom d'en-tête inclus dans une réponse (tout en conservant sa valeur initiale)
ajouter un nouvel en-tête à une réponse (ou modifier ou conserver les valeurs d'en-tête existant déjà inclus dans une réponse)

Pour plus d'informations sur l'ajout d'une politique d'échec de validation, voir Modification d'un fichier JSON pour ajouter des politiques de demande pour l'authentification et l'autorisation sous plusieurs arguments.

Exemple de spécification de déploiement utilisant des jetons d'accès sous plusieurs arguments

La spécification de déploiement d'API suivante définit :

Politique de demande d'authentification qui appelle une fonction d'autorisation à plusieurs arguments pour effectuer l'authentification.
Politique de demande d'autorisation qui spécifie ce que les utilisateurs finaux authentifiés peuvent faire.

{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "isAnonymousAccessAllowed": true,
      "parameters": {
        "xapikey": "request.headers[X-Api-Key]",
        "referer": "request.headers[Referer]",
        "state": "request.query[state]",
        "city": "request.query[city]",
        "cert": "request.cert",
        "body": "request.body",
        "host": "request.host"
        },
      "cacheKey": [
        "xapikey", "referer"
        ],
      "validationFailurePolicy": {
        "type": "MODIFY_RESPONSE",
        "responseCode": "request.auth[responseCode]",
        "responseMessage": "Unfortunately, authentication failed.",
        "responseTransformations": {
        "headerTransformations": {
          "setHeaders": {
            "items": [
              {
                "name": "Location",
                "values": [
                  "${request.auth[location]}"
                  ]
                }
              ]
            },
          "filterHeaders": {
            "type": "BLOCK",
            "items": [
              {
                "name": "topSecret"
                }
              ]
            }
          }
        }
      }
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}

La politique de demande d'authentification dans cette spécification de déploiement d'API :

Spécifie la fonction d'autorisation à plusieurs arguments à appeler pour effectuer l'authentification et définit les arguments xapikey, referer, state, city, cert, body et host à transmettre à la fonction d'autorisation. Les valeurs de ces arguments sont obtenues à partir de variables de contexte qui ont des valeurs de la demande initiale.
Définit une clé de cache personnalisée identifiant de manière unique la réponse en mémoire cache retournée par la fonction d'autorisation. Plutôt que d'utiliser la clé de cache par défaut (qui inclut tous les arguments envoyés à la fonction d'autorisation, et est recommandée), cette politique de demande d'authentification spécifie que la clé de cache doit comprendre uniquement les valeurs des arguments xapikey et referrer transmis à la fonction d'autorisation.
Inclut une politique d'échec de validation qui modifie la réponse d'échec de validation par défaut pour remplacer le code de statut HTTP 401 par défaut par la valeur de la variable de contexte request.auth[responseCode]. La variable de contexte request.auth[responseCode] a la valeur d'un paramètre d'authentification (dans ce cas, nommé responseCode) retourné par la fonction d'autorisation. De même, le message d'échec de validation par défaut est remplacé par une chaîne de message personnalisée ("Unfortunately, authentication failed.").
Inclut une politique de demande de transformation d'en-tête dans la politique d'échec de validation qui ajoute l'en-tête location à la réponse d'échec de validation. L'en-tête location reçoit la valeur de la variable de contexte request.auth[location], qui a la valeur d'un paramètre d'authentification (dans ce cas, nommé location) retourné par la fonction d'autorisation. La politique de demande de transformation d'en-tête supprime également les en-têtes nommés topSecret de la réponse.

La politique de demande d'autorisation de cette spécification de déploiement d'API permet uniquement aux utilisateurs finaux authentifiés par la fonction d'autorisation et avec la portée read:hello d'accéder à la route /hello.

Ajout de politiques de demande d'authentification et d'autorisation pour les jetons d'accès à un seul argument et les fonctions d'autorisation

Vous pouvez ajouter des politiques de demande pour fournir l'authentification et l'autorisation à l'aide de jetons d'accès à un seul argument et de fonctions d'autorisation à un seul argument :

Note

Oracle recommande d'utiliser des fonctions d'autorisation à plusieurs arguments plutôt que des fonctions d'autorisation à un seul argument en raison de leur polyvalence supplémentaire. Des fonctions d'autorisation à argument unique ont été fournies dans des versions antérieures et continuent d'être prises en charge. Cependant, comme les fonctions d'autorisation à plusieurs arguments peuvent également accepter des jetons d'accès à un seul argument contenus dans les en-têtes de demande et les paramètres d'interrogation, il n'y a aucune raison de créer de nouvelles fonctions d'autorisation à un seul argument. En outre, des fonctions d'autorisation à argument unique sont prévues pour l'abandon dans une version ultérieure.

Utilisation de la console pour ajouter des politiques de demande d'authentification et d'autorisation pour un seul argument

Pour ajouter des politiques de demande d'authentification et d'autorisation pour des jetons d'accès à un seul argument à une spécification de déploiement d'API à l'aide de la console :

Créez ou mettez à jour un déploiement d'API à l'aide de la console, sélectionnez l'option À partir de zéro et entrez les détails dans la page Informations de base.

Pour plus d'informations, voir 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.
Sélectionnez Suivant pour afficher la page Authentification.
Sélectionnez Authentification unique pour spécifier que vous voulez utiliser un seul serveur d'authentification pour toutes les demandes.

Ces instructions supposent que vous souhaitez utiliser un seul serveur d'authentification. Sinon, si vous voulez utiliser plusieurs serveurs d'authentification, sélectionnez Authentification multiple et suivez les instructions sous Utilisation de la console pour ajouter plusieurs serveurs d'authentification au même déploiement d'API.
Cochez ou désélectionnez la case Activer l'accès anonyme : pour spécifier si les utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes du déploiement d'API.

Par défaut, cette option n'est pas sélectionnée. Si vous voulez que des utilisateurs anonymes ne puissent jamais accéder aux routes, ne sélectionnez pas cette option. Notez que si vous sélectionnez cette option, vous devez également spécifier explicitement toutes les routes pour lesquelles un accès anonyme est autorisé en sélectionnant Anonyme comme Type d'autorisation dans la politique d'autorisation de chaque route.
Sélectionnez Fonction d'autorisation dans la liste d'options Type d'authentification.
Spécifiez la fonction d'autorisation à un seul argument à utiliser pour authentifier le jeton d'accès à un seul argument :
- Application Oracle Functions dans <compartiment-nom> : Nom de l'application du service des fonctions pour OCI, qui contient la fonction d'autorisation. Vous pouvez sélectionner une application dans un compartiment différent.
- Nom de la fonction : Nom de la fonction d'autorisation du service des fonctions pour OCI.
Sélectionnez Fonction d'autorisation à un seul argument pour spécifier que vous voulez transmettre un jeton d'accès à un seul argument dans un en-tête ou un paramètre d'interrogation à une fonction d'autorisation à un seul argument.
Dans le panneau Jeton d'accès, identifiez le jeton d'accès à utiliser pour l'authentification :
- Emplacement du jeton : Sélectionnez En-tête ou Paramètre d'interrogation pour spécifier l'emplacement du jeton d'accès dans la demande.
- Nom de l'en-tête de jeton ou Nom du paramètre de jeton : Selon l'emplacement du jeton d'accès, entrez le nom de l'en-tête ou du paramètre d'interrogation contenant le jeton d'accès.
Sélectionnez Suivant pour entrer les détails des routes individuelles du déploiement d'API dans la page Routes.
Dans la section Route 1, spécifiez la première route du déploiement d'API qui mappe un chemin et une ou plusieurs méthodes à un service dorsal :
- Chemin : Chemin des appels d'API utilisant les méthodes indiquées au service dorsal. Notez que le chemin de routage que vous spécifiez :
  - Est relatif au préfixe du chemin de déploiement.
  - Doit être précédé d'une barre oblique (/) et peut être simplement cette seule barre oblique.
  - Peut contenir plusieurs barres obliques (à condition qu'elles ne soient pas adjacentes) et peut se terminer par une barre oblique.
  - Peut inclure des caractères alphanumériques en majuscules et en minuscules.
  - peut inclure les caractères spéciaux $ - _ . + ! * ' ( ) , % ; : @ & =
  - Peut inclure des paramètres et des caractères génériques (voir Ajout de paramètres de chemin et de caractères génériques aux chemins de routage).
- Méthodes : Une ou plusieurs méthodes acceptées par le service dorsal, séparées par des virgules. Par exemple, GET, PUT.
- Ajouter un seul serveur dorsal ou Ajouter plusieurs serveurs dorsaux : Indique si toutes les demandes doivent être acheminées vers le même serveur dorsal ou si elles doivent être acheminées vers différents serveurs dorsaux en fonction de la variable de contexte et des règles que vous entrez.
  
  Ces instructions supposent que vous voulez utiliser un seul élément dorsal. Sélectionnez donc Ajouter un seul élément dorsal. Sinon, si vous voulez utiliser des éléments dorsaux différents, sélectionnez Ajouter plusieurs éléments dorsaux et suivez les instructions sous Utilisation de la console pour ajouter une sélection d'élément dorsal dynamique à une spécification de déploiement d'API.
- Type dorsal : Type du service dorsal, parmi l'un des suivants :
  - HTTP : Pour un élément dorsal HTTP, vous devez également spécifier une URL, les détails de temporisation et déterminer s'il faut désactiver ou non la vérification SSL (voir Ajout d'une URL HTTP ou HTTPS comme élément dorsal du service de passerelle d'API).
  - Oracle Functions : Pour un élément dorsal du service des fonctions pour OCI, vous devez également spécifier l'application et la fonction (voir Ajout d'une fonction du service des fonctions pour OCI en tant qu'élément dorsal du service de passerelle d'API).
  - Réponse standard : Pour un élément dorsal de réponse standard, vous devez également spécifier le code de statut HTTP, le contenu du corps de la réponse et un ou plusieurs champs d'en-tête HTTP (voir Ajout de réponses standard comme élément dorsal du service de passerelle d'API).
Pour spécifier une politique d'autorisation qui s'applique à une route individuelle, sélectionnez Afficher les politiques de demande de routage, sélectionnez le bouton Ajouter à côté du champ Autorisation, puis spécifiez les données suivantes :
- Type d'autorisation : Comment accorder l'accès à la route. Spécifiez les données suivantes :
  - Au choix : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si la fonction d'autorisation a également retourné une des étendues d'accès que vous spécifiez dans le champ Étendue autorisée. Dans ce cas, l'option Activer l'accès anonyme de la politique d'authentification n'a aucun effet.
  - Anonyme : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés par la fonction d'autorisation. Dans ce cas, vous devez avoir sélectionné l'option Activer l'accès anonyme de la politique d'authentification.
  - Authentification uniquement : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés par la fonction d'autorisation. Dans ce cas, l'option Activer l'accès anonyme de la politique d'authentification n'a aucun effet.
- Étendue autorisée : Si vous avez sélectionné Au choix comme Type d'autorisation, indiquez une liste délimitée par des virgules contenant une ou plusieurs chaînes correspondant aux étendues d'accès retournées par la fonction d'autorisation. L'accès ne sera accordé qu'aux utilisateurs finaux qui ont été authentifiés si la fonction d'autorisation retourne une des étendues d'accès que vous spécifiez. Par exemple, read:hello.
Note

Si vous n'incluez pas de politique d'autorisation pour une route particulière, l'accès est accordé comme si une telle politique existait et le type d'autorisation est réglé à Authentification uniquement. Autrement dit, quel que soit le paramètre de l'option Activer l'accès anonyme de la politique d'authentification :
- Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
- Tous les utilisateurs finaux authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès retournées par la fonction d'autorisation.
- Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.
Sélectionnez Suivant pour vérifier les détails que vous avez entrés pour le déploiement d'API.
Sélectionnez Créer ou enregistrer les modifications pour créer ou mettre à jour le déploiement d'API.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Modification d'un fichier JSON pour ajouter des politiques de demande pour l'authentification et l'autorisation à un seul argument

Pour ajouter des politiques de demande d'authentification et d'autorisation pour des jetons d'accès à un seul argument à une spécification de déploiement d'API dans un fichier JSON :

Dans votre éditeur JSON préféré, modifiez la spécification de déploiement d'API existante à laquelle vous souhaitez ajouter les fonctionnalités d'authentification et d'autorisation ou créez une spécification de déploiement d'API (voir Création d'une spécification de déploiement d'API).

Au minimum, la spécification de déploiement d'API inclura une section routes contenant les éléments suivants :
- Un chemin. Par exemple /hello.
- Une ou plusieurs méthodes. Par exemple GET
- La définition d'un élément dorsal. Par exemple, une URL ou l'OCID d'une fonction du service des fonctions pour OCI.
Par exemple, la spécification de déploiement d'API de base suivante définit une simple fonction sans serveur Hello World du service des fonctions pour OCI en tant qu'élément dorsal unique :
```
{
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Ajoutez une politique de demande authentication qui s'applique à toutes les routes de la spécification de déploiement d'API :
1. Insérez une section requestPolicies avant la section routes, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {},
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
2. Ajoutez la politique authentication suivante à la nouvelle section requestPolicies.
```
{
  "requestPolicies": {
    "authentication": {
      "type": "<type-value>",
      "isAnonymousAccessAllowed": <true|false>,
      "functionId": "<function-ocid>",
      <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>">
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
  où :
  - <type-value> est le type d'authentification. Pour utiliser une fonction d'autorisation pour l'authentification, spécifiez CUSTOM_AUTHENTICATION.
  - "isAnonymousAccessAllowed": <true|false> indique facultativement si des utilisateurs finaux non authentifiés (c'est-à-dire anonymes) peuvent accéder aux routes de la spécification de déploiement d'API. Si vous voulez que des utilisateurs finaux anonymes ne puissent jamais accéder aux routes, réglez cette propriété à false. Si vous n'incluez pas cette propriété dans la politique authentication, la valeur par défaut false est utilisée. Notez que si vous n'incluez pas cette propriété et que vous la réglez à true, vous devez également spécifier explicitement toutes les routes auxquelles l'accès anonyme est autorisé en réglant la propriété type à "ANONYMOUS" dans la politique authorization de chaque route.
  - <function-ocid> est l'OCID de la fonction d'autorisation déployée dans le service des fonctions pour OCI.
  - <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indique si le jeton d'accès est contenu dans un en-tête de demande (et, si c'est le cas, le nom de l'en-tête) ou un paramètre d'interrogation (et, si c'est le cas, le nom du paramètre d'interrogation). Notez que vous pouvez spécifier "tokenHeader": "<token-header-name>" ou "tokenQueryParam": "<token-query-param-name>">, mais pas les deux.
  Par exemple, la politique authentication suivante spécifie une fonction OCI qui valide le jeton d'accès dans l'en-tête de la demande d'autorisation :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      }
    }
  ]
}
```
Ajoutez une politique de demande authorization pour chaque route de la spécification de déploiement d'API :
1. Insérez une section requestPolicies après la section backend de la première route, si elle n'existe pas déjà. Par exemple :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
         "type": "ORACLE_FUNCTIONS_BACKEND",
         "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {}
    }
  ]
}
```
2. Ajoutez la politique authorization suivante à la section requestPolicies :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS">, 
          "allowedScope": [ "<scope>" ]
        }
      }
    }
  ]
}
```
  où :
  - "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indique comment accorder l'accès à la route :
    - "AUTHENTICATION_ONLY" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANY_OF" : Accorder uniquement l'accès aux utilisateurs finaux qui ont été authentifiés, si la fonction d'autorisation a également retourné une des étendues d'accès que vous spécifiez dans la propriété allowedScope. Dans ce cas, la propriété "isAnonymousAccessAllowed" dans la politique authentication de la spécification de déploiement d'API n'a aucun effet.
    - "ANONYMOUS" : Accorder l'accès à tous les utilisateurs finaux, même s'ils n'ont pas été authentifiés. Dans ce cas, vous devez explicitement régler la propriété "isAnonymousAccessAllowed" à true dans la politique authentication de la spécification de déploiement d'API.
  - "allowedScope": [ "<scope>" ] est une liste délimitée par des virgules, contenant une ou plusieurs chaînes correspondant aux étendues d'accès retournées par la fonction d'autorisation. Dans ce cas, vous devez régler la propriété type à "ANY_OF" (la propriété "allowedScope" est ignorée si la propriété type est réglée à "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Notez également que si vous spécifiez plusieurs étendues, l'accès à la route est accordé si l'une des étendues que vous spécifiez est retournée par la fonction d'autorisation.
  Par exemple, la politique de demande suivante définit une route /hello qui autorise uniquement les utilisateurs finaux authentifiés avec l'étendue read:hello à y accéder :
```
{
  "requestPolicies": {
    "authentication": {
      "type": "CUSTOM_AUTHENTICATION",
      "isAnonymousAccessAllowed": false,
      "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaac2______kg6fq",
      "tokenHeader": "Authorization"
    }
  },
  "routes": [
    {
      "path": "/hello",
      "methods": ["GET"],
      "backend": {
        "type": "ORACLE_FUNCTIONS_BACKEND",
        "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
      },
      "requestPolicies": {
        "authorization": {
          "type": "ANY_OF",
          "allowedScope": [ "read:hello" ]
        }
      }
    }
  ]
}
```
3. Ajoutez une politique de demande authorization pour toutes les routes restantes de la spécification de déploiement d'API.
Note

Si vous n'incluez pas de politique authorization pour une route particulière, l'accès est accordé comme si une telle politique existe et la propriété type est réglée à "AUTHENTICATION_ONLY". Autrement dit, quelle que soit la définition de la propriété isAnonymousAccessAllowed dans la politique authentication de la spécification de déploiement d'API :
- Seuls les utilisateurs finaux authentifiés peuvent accéder à la route.
- Tous les utilisateurs finaux authentifiés peuvent accéder à la route, quelles que soient les étendues d'accès retournées par la fonction d'autorisation.
- Les utilisateurs finaux anonymes ne peuvent pas accéder à la route.
Enregistrez le fichier JSON contenant la spécification de déploiement d'API.
Utilisez comme suit 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 Charger une API existante.
- En spécifiant le fichier JSON dans une demande à l'API REST du service Passerelle d'API.
Pour plus d'informations, voir 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.
(Facultatif) Vérifiez que l'API a été déployée avec succès en l'appelant (voir Appel d'une API déployée sur une passerelle d'API).

Documentation sur Oracle Cloud Infrastructure