Aggiunta di criteri di autenticazione e richiesta di autorizzazione

Per aggiungere criteri di autenticazione e richiesta di autorizzazione per i token di accesso a più argomenti a una specifica di distribuzione API utilizzando la console, procedere come segue.

1. Creare o aggiornare una distribuzione API utilizzando la console, selezionare l'opzione Da zero e immettere i dettagli nella pagina Informazioni di base.

   Per ulteriori informazioni, vedere Distribuzione di un'interfaccia API in un gateway API mediante la creazione di una distribuzione API e Aggiornamento di un gateway API o di una distribuzione API.

2. Fare clic su Avanti per visualizzare la pagina Autenticazione.

3. Selezionare Autenticazione singola per specificare che si desidera utilizzare un singolo server di autenticazione per tutte le richieste.

   Queste istruzioni si basano sul presupposto che si desidera utilizzare un singolo server di autenticazione. In alternativa, se si desidera utilizzare più server di autenticazione, selezionare Autenticazione multipla e seguire le istruzioni in Utilizzo della console per aggiungere più server di autenticazione alla stessa distribuzione API.

4. Selezionare o deselezionare la casella di controllo Abilita accesso anonimo per specificare se gli utenti finali non autenticati (ovvero anonimi) possono accedere agli instradamenti nella distribuzione dell'API.

   Per impostazione predefinita, questa opzione non è selezionata. Se non si desidera che utenti anonimi possano accedere ai percorsi, non selezionare questa opzione. Tenere presente che se si seleziona questa opzione, è inoltre necessario specificare in modo esplicito ogni instradamento per il quale è consentito l'accesso anonimo selezionando Anonimo come Tipo di autorizzazione nel criterio di autorizzazione di ogni instradamento.

5. Selezionare Funzione responsabile autorizzazioni dalla lista di opzioni Tipo di autenticazione.
6. Specificare la funzione di autorizzazione a più argomenti da utilizzare per autenticare il token di accesso a più argomenti:
   • Applicazione Oracle Functions in <compartment-name>: il nome dell'applicazione nelle funzioni OCI che contengono la funzione del responsabile autorizzazioni. È possibile selezionare un'applicazione da un altro compartimento.
   • Nome funzione: il nome della funzione del responsabile autorizzazioni in Funzioni OCI.
7. Selezionare Funzione del responsabile autorizzazioni multi-argomento per specificare che si desidera passare uno o più elementi di una richiesta come token di accesso a una funzione del responsabile autorizzazioni in grado di accettare token di accesso multi-argomento.
8. Nel pannello Argomenti funzione specificare una o più variabili di contesto che forniscono i valori da passare alla funzione del responsabile autorizzazioni come argomenti con i nomi degli argomenti immessi:
   1. Specificare una variabile di contesto che fornisca un valore da passare alla funzione del responsabile autorizzazioni come argomento:
      • Tabella di contesto: selezionare dalla lista la tabella di contesto contenente la variabile di contesto.
        • Tabella di contesto request.query, contenente i nomi e i valori dei parametri di query inclusi nella richiesta
        • Tabella di contesto request.headers, contenente i nomi e i valori di intestazione inclusi nella richiesta
        • Tabella di contesto request.cert, contenente una versione del certificato con codifica Base64 presentata da un client API e convalidata correttamente durante un handshake mTLS
        • Tabella di contesto request.host, contenente il nome dell'host a cui è stata inviata la richiesta (estratta dal campo dell'intestazione Host nella richiesta)
        • Tabella di contesto request.body, contenente il corpo della richiesta
      • Nome intestazione o Nome parametro query: se è stata selezionata la tabella di contesto request.headers o request.params, immettere il nome dell'intestazione o del parametro di query che si desidera passare alla funzione del responsabile autorizzazioni. Ad esempio, X-Api-Key, state.
      • Nome argomento: immettere il nome dell'argomento al quale assegnare il valore della variabile di contesto. L'argomento viene passato alla funzione del responsabile autorizzazioni. Il nome dell'argomento immesso deve corrispondere al nome dell'argomento che la funzione del responsabile autorizzazioni prevede di ricevere.
   2. Specificare variabili e argomenti di contesto aggiuntivi in base alle esigenze (se necessario, fare clic su Altro argomento).

9. Facoltativamente, personalizzare la modalità di inserimento nella cache della risposta da una funzione del responsabile autorizzazioni per più argomenti:

   1. Fare clic su Mostra opzioni avanzate.

      Il pannello Inserimento dei risultati della funzione nella cache mostra gli argomenti presenti nella chiave cache. La chiave cache identifica in modo univoco la risposta inserita nella cache restituita dalla funzione del responsabile autorizzazioni, utilizzando gli argomenti e i valori degli argomenti passati nella richiesta di autenticazione originale. Per impostazione predefinita, tutti gli argomenti e i valori degli argomenti (ad eccezione di un argomento con un valore della tabella di contesto request.body) che si è specificato di passare alla funzione del responsabile autorizzazioni vengono utilizzati per creare la chiave cache.

   2. Per aggiungere o rimuovere argomenti dalla chiave cache, fare clic su Modifica.
   3. Selezionare o deselezionare gli argomenti passati alla funzione del responsabile autorizzazioni per includerli o escluderli dalla chiave cache.

   Vedere Note sull'inserimento nella cache dei risultati della funzione del responsabile autorizzazioni più argomenti.

10. Facoltativamente, personalizzare la modalità di gestione di una risposta di autenticazione non riuscita da una funzione del responsabile autorizzazioni multiargomento impostando un criterio di errore di convalida:

    1. Fare clic su Mostra opzioni avanzate.

       Il pannello Risposta personalizzata per autenticazione non riuscita mostra il codice di stato HTTP e il corpo del messaggio da restituire al client API se la funzione del responsabile autorizzazioni non è in grado di autenticare la richiesta. Per impostazione predefinita, il gateway API invia un codice di stato HTTP 401 e l'intestazione WWW-Authenticate nella risposta. Vedere Note sui criteri di errore di convalida e gestione delle risposte di autenticazione non riuscite dalle funzioni del responsabile autorizzazioni più argomenti.

    2. Specificare un codice di stato (e un corpo del messaggio facoltativo) per tornare al client API se la funzione del responsabile autorizzazioni non è in grado di autenticare la richiesta:
       • Codice di stato HTTP: immettere un codice di stato HTTP alternativo (ad esempio, 500). In alternativa, è possibile includere una variabile di contesto per restituire il codice restituito dalla funzione del responsabile autorizzazioni. Ad esempio, se la funzione del responsabile autorizzazioni restituisce un codice di risposta nel parametro responseCode, specificare request.auth[responseCode].
       • Corpo del messaggio: immettere un corpo del messaggio. Ad esempio, Unfortunately, authentication failed.Il corpo del messaggio può includere qualsiasi variabile di contesto (ad eccezione di request.body). Ad esempio, Unfortunately, authentication failed ${request.auth[my-auth-variable]}.

    3. Facoltativamente, modificare le intestazioni della risposta restituita dal gateway API al client API facendo clic su Mostra opzioni avanzate e specificando un criterio di risposta di trasformazione dell'intestazione:

       • Per limitare le intestazioni incluse in una risposta, specificare:

         • Azione: filtro.
         • Tipo: Blocca per rimuovere dalla risposta le intestazioni elencate in modo esplicito oppure Consenti di consentire solo nella risposta le intestazioni elencate in modo esplicito (qualsiasi altra intestazione viene rimossa dalla risposta).
         • Nomi intestazione: la lista di intestazioni da rimuovere dalla risposta o da consentire nella risposta (a seconda dell'impostazione di Tipo). I nomi specificati non fanno distinzione tra maiuscole e minuscole e non devono essere inclusi in altri criteri di risposta di trasformazione per l'instradamento (ad eccezione degli elementi filtrati come consentito). Ad esempio, User-Agent.

       • Per modificare il nome di un'intestazione inclusa in una risposta (mantenendo il valore originale), specificare:

         • Azione: rinominare.
         • Nome intestazione: il nome originale dell'intestazione che si sta rinominando. Il nome specificato non fa distinzione tra maiuscole e minuscole e non deve essere incluso in altri criteri di risposta di trasformazione per l'instradamento. Ad esempio, X-Username.
         • Nuovo nome intestazione: il nuovo nome dell'intestazione che si sta rinominando. Il nome specificato non fa distinzione tra maiuscole e minuscole (la capitalizzazione potrebbe essere ignorata) e non deve essere incluso in altri criteri di risposta di trasformazione per l'instradamento (ad eccezione degli elementi negli elenchi ALLOW). Ad esempio, X-User-ID.

       • Per aggiungere una nuova intestazione a una risposta (o per modificare o conservare i valori di un'intestazione esistente già inclusa in una risposta), specificare:

         • Azione: impostare.

         • Comportamento: se l'intestazione esiste già, specificare le operazioni da eseguire con il valore esistente dell'intestazione:

           • Sovrascrivi, per sostituire il valore esistente dell'intestazione con il valore specificato.
           • Aggiungi, per aggiungere il valore specificato al valore esistente dell'intestazione.
           • Salta, per mantenere il valore esistente dell'intestazione.
         • Nome intestazione: il nome dell'intestazione da aggiungere alla risposta (o per modificare il valore di). Il nome specificato non fa distinzione tra maiuscole e minuscole e non deve essere incluso in altri criteri di risposta alla trasformazione per l'instradamento (ad eccezione degli elementi filtrati come consentito). Ad esempio, X-Api-Key.
         • Valori: il valore della nuova intestazione (o il valore da sostituire o aggiungere al valore di un'intestazione esistente, a seconda dell'impostazione di Comportamento). È possibile specificare più valori. Il valore specificato può essere una stringa semplice o includere variabili di contesto (ad eccezione di request.body) racchiuse nei delimitatori ${...}. Ad esempio, "value": "zyx987wvu654tsu321".

       Per ulteriori informazioni sui criteri di risposta per la trasformazione dell'intestazione, vedere Aggiunta di criteri di risposta per la trasformazione dell'intestazione

11. Fare clic su Avanti per immettere i dettagli relativi ai singoli instradamenti nella distribuzione API nella pagina Instradamenti.

12. Nella sezione Route 1 specificare il primo instradamento nella distribuzione API che esegue il mapping di un percorso e di uno o più metodi a un servizio backend:

    • Percorso: un percorso per le chiamate API che utilizzano i metodi elencati per il servizio backend. Tenere presente che il percorso di instradamento specificato è il seguente:

      • è relativo al prefisso del percorso di distribuzione
      • deve essere preceduta da una barra ( / ) e può essere solo la singola barra
      • può contenere più barre in avanti (a condizione che non siano adiacenti) e può terminare con una barra in avanti
      • può includere caratteri alfanumerici maiuscoli e minuscoli
      • può includere i caratteri speciali $ - _ . + ! * ' ( ) , % ; : @ & =
      • può includere parametri e caratteri jolly (vedere Aggiunta di parametri di percorso e caratteri jolly ai percorsi di instradamento)
    • Metodi: uno o più metodi accettati dal servizio backend, separati da virgole. Ad esempio, GET, PUT.

    • Aggiungere un backend singolo o Aggiungere più backend: indica se instradare tutte le richieste allo stesso backend o instradare le richieste a backend diversi in base alla variabile di contesto e alle regole immesse.

      Queste istruzioni presuppongono di voler utilizzare un singolo backend, quindi selezionare Aggiungi un backend singolo. In alternativa, se si desidera utilizzare backend diversi, selezionare Aggiungi più backend e seguire le istruzioni in Utilizzo della console per aggiungere la selezione backend dinamica a una specifica di distribuzione API.

    • Tipo backend: il tipo di servizio backend, ovvero uno dei seguenti:
      • HTTP: per un backend HTTP, è inoltre necessario specificare un URL, i dettagli del timeout e se disabilitare la verifica SSL (vedere Aggiunta di un URL HTTP o HTTPS come backend del gateway API).
      • Oracle Functions: per un backend OCI Functions, è necessario specificare anche l'applicazione e la funzione (vedere Aggiunta di una funzione nelle funzioni OCI come backend del gateway API).
      • Risposta scorte: per un back-end di risposta scorte, è necessario specificare anche il codice di stato HTTP, il contenuto nel corpo della risposta e uno o più campi di intestazione HTTP (vedere Aggiunta di risposte scorte come backend del gateway API).

13. Per specificare un criterio di autorizzazione applicabile a un singolo instradamento, fare clic su Mostra criteri richiesta di instradamento, fare clic sul pulsante Aggiungi accanto a Autorizzazione e specificare:

    • Tipo di autorizzazione: procedura per concedere l'accesso all'instradamento. Specificare:

      • Qualsiasi: concedere l'accesso solo agli utenti finali che sono stati autenticati correttamente, a condizione che la funzione del responsabile autorizzazioni abbia restituito anche uno degli ambiti di accesso specificati nel campo Ambito consentito. In questo caso, l'opzione Abilita accesso anonimo del criterio di autenticazione non ha alcun effetto.
      • Anonimo: concede l'accesso a tutti gli utenti finali, anche se la funzione del responsabile autorizzazioni non li ha autenticati correttamente. In questo caso, è necessario aver selezionato l'opzione Abilita accesso anonimo del criterio di autenticazione.
      • Solo autenticazione: concede l'accesso solo agli utenti finali che sono stati autenticati correttamente dalla funzione del responsabile autorizzazioni. In questo caso, l'opzione Abilita accesso anonimo del criterio di autenticazione non ha alcun effetto.
    • Ambito consentito: se si seleziona Qualsiasi come Tipo di autorizzazione, immettere una lista delimitata da virgole di una o più stringhe che corrispondono agli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni. L'accesso verrà concesso solo agli utenti finali che sono stati autenticati correttamente se la funzione del responsabile autorizzazioni restituisce uno degli ambiti di accesso specificati. Ad esempio read:hello
    Nota
    
    

    Se non si include un criterio di autorizzazione per un instradamento particolare, viene concesso l'accesso come se tale criterio esistesse e l'opzione Tipo di autorizzazione fosse impostata su Solo autenticazione. In altre parole, indipendentemente dall'impostazione dell'opzione Abilita accesso anonimo del criterio di autenticazione:

    • solo gli utenti finali autenticati possono accedere al percorso
    • tutti gli utenti finali autenticati possono accedere all'instradamento indipendentemente dagli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni
    • gli utenti finali anonimi non possono accedere al percorso
14. Fare clic su Applica modifiche, quindi su Avanti per esaminare i dettagli immessi per la distribuzione dell'API.
15. Fare clic su Crea o su Salva modifiche per creare o aggiornare la distribuzione API.
16. (Facoltativo) Confermare che l'interfaccia API sia stata distribuita correttamente chiamandola (vedere Chiamata di un'interfaccia API distribuita in un gateway API).

Per aggiungere criteri di autenticazione e richiesta di autorizzazione per i token di accesso multiargomento a una specifica di distribuzione API in un file JSON, effettuare le operazioni riportate di seguito.

1. Utilizzando l'editor JSON preferito, modificare la specifica di distribuzione API esistente alla quale si desidera aggiungere la funzionalità di autenticazione e autorizzazione oppure creare una nuova specifica di distribuzione API (vedere Creazione di una specifica di distribuzione API).

   La specifica di distribuzione API includerà almeno una sezione routes contenente:

   • Un percorso. Ad esempio /hello
   • Uno o più metodi. Ad esempio, GET
   • Definizione di un back end. Ad esempio, un URL o l'OCID di una funzione in Funzioni OCI.

   Ad esempio, la seguente specifica di distribuzione API di base definisce una semplice funzione serverless Hello World in Funzioni OCI come un singolo backend:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

2. Aggiungere un criterio di richiesta authentication che si applica a tutti gli instradamenti nella specifica di distribuzione API:

   1. Se non esiste già, inserire una sezione requestPolicies prima della sezione routes. Ad esempio:

      
      {
        "requestPolicies": {},
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
               "type": "ORACLE_FUNCTIONS_BACKEND",
               "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            }
          }
        ]
      }

   2. Aggiungere il seguente criterio authentication alla nuova sezione 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"
            }
          }
        ]
      }

      dove:

      • <type-value> è il tipo di autenticazione. Per utilizzare una funzione del responsabile autorizzazioni per l'autenticazione, specificare CUSTOM_AUTHENTICATION.
      • "isAnonymousAccessAllowed": <true|false> indica facoltativamente se gli utenti finali non autenticati (ovvero anonimi) possono accedere agli instradamenti nella specifica di distribuzione API. Se non si desidera che gli utenti finali anonimi possano accedere ai percorsi, impostare questa proprietà su false. Se non si include questa proprietà nel criterio authentication, viene utilizzato il valore predefinito false. Tenere presente che se si include questa proprietà e la si imposta su true, è inoltre necessario specificare in modo esplicito ogni instradamento per il quale è consentito l'accesso anonimo impostando la proprietà type su "ANONYMOUS" nel criterio authorization di ogni instradamento.
      • <function-ocid> è l'OCID della funzione del responsabile autorizzazioni distribuita nelle funzioni OCI.
      • <argument-n> è il nome dell'argomento al quale assegnare il valore di una variabile di contesto e di una sola variabile. L'argomento viene passato alla funzione del responsabile autorizzazioni. Il nome dell'argomento immesso deve corrispondere al nome dell'argomento che la funzione del responsabile autorizzazioni prevede di ricevere. È possibile includere più coppie di variabili argomento-contesto.
      • <context-variable> è una variabile di contesto il cui valore si desidera assegnare all'argomento corrispondente. Il formato <context-variable> deve essere <context-table-name> o <context-table-name>[<key>], dove <context-table-name> è uno dei seguenti:
        • request.query, una tabella di contesto contenente i nomi e i valori dei parametri di query inclusi nella richiesta. Se si desidera specificare un parametro di query, è necessario specificare sia la tabella di contesto request.query che il nome del parametro di query come chiave, nel formato request.query[<query-parameter-name>]. Ad esempio, request.query[state]
        • request.headers, una tabella di contesto contenente i nomi e i valori di intestazione inclusi nella richiesta. Se si desidera specificare un'intestazione, è necessario specificare sia la tabella di contesto request.headers che il nome dell'intestazione come chiave, nel formato request.headers[<header-name>]. Ad esempio, request.headers[X-Api-Key]
        • Tabella di contesto request.cert, contenente una versione del certificato con codifica Base64 presentata da un client API e convalidata correttamente durante un handshake mTLS
        • request.host, una tabella di contesto contenente il nome dell'host a cui è stata inviata la richiesta (estratta dal campo dell'intestazione Host nella richiesta)
        • request.body, una tabella di contesto contenente il corpo della richiesta.
      • "cacheKey": ["<cache-key-argument-n>", "<cache-key-argument-n>"] limita facoltativamente la chiave cache all'uso solo degli argomenti specificati. La chiave cache identifica in modo univoco la risposta inserita nella cache restituita dalla funzione del responsabile autorizzazioni, utilizzando gli argomenti e i valori degli argomenti passati nella richiesta di autenticazione originale. Per impostazione predefinita, tutti gli argomenti e i valori degli argomenti (ad eccezione di un argomento con un valore della tabella di contesto request.body) nella lista parameters: {…} vengono utilizzati per creare la chiave cache. Un argomento specificato per <cache-key-argument-n> deve essere uno degli argomenti della lista parameters: {…}. Vedere Note sull'inserimento nella cache dei risultati della funzione del responsabile autorizzazioni più argomenti.
   3. Facoltativamente, aggiungere validationFailurePolicy alla sezione dei criteri 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": {
              "category": "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"
            }
          }
        ]
      }

      dove:

      • "validationFailurePolicy": {…} consente facoltativamente di modificare il codice di stato HTTP, il corpo del messaggio e le intestazioni nella risposta al client API se la funzione del responsabile autorizzazioni non è in grado di autenticare una richiesta. Per impostazione predefinita, il gateway API invia un codice di stato HTTP 401 e l'intestazione WWW-Authenticate nella risposta. Vedere Note sui criteri di errore di convalida e gestione delle risposte di autenticazione non riuscite dalle funzioni del responsabile autorizzazioni più argomenti.
      • <policy-category> è il tipo di criterio di errore di convalida. Per modificare la risposta, specificare MODIFY_RESPONSE.
      • "responseCode": "<alternative-response-code>" specifica un codice di stato HTTP alternativo. Ad esempio "responseCode": "500". In alternativa, è possibile includere una variabile di contesto per restituire il codice restituito dalla funzione del responsabile autorizzazioni. Ad esempio, se la funzione del responsabile autorizzazioni restituisce un codice di risposta nel parametro responseCode, specificare "request.auth[responseCode]".
      • "responseMessage": "<custom-message-body>" specifica il contenuto da includere nel corpo del messaggio. Ad esempio, "responseMessage": "Unfortunately, authentication failed.". Il corpo del messaggio può includere qualsiasi variabile di contesto (ad eccezione di request.body). Ad esempio, "responseMessage": "Unfortunately, authentication failed ${request.auth[my-auth-variable]}".
      • "headerTransformations": {<valid-header-transformation-response-policy>} è un criterio di risposta di trasformazione intestazione valido. Vedere Modifica di un file JSON per aggiungere i criteri di risposta di trasformazione dell'intestazione.

3. Aggiungere un criterio di richiesta authorization per ogni instradamento nella specifica di distribuzione API:

   1. Inserire una sezione requestPolicies dopo la sezione backend della prima route, se non esiste già. Ad esempio:

      
      {
        "requestPolicies": {
          "authentication": {
            "type": "CUSTOM_AUTHENTICATION",
            .
            .
            .
          }
        },
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
               "type": "ORACLE_FUNCTIONS_BACKEND",
               "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            },
            "requestPolicies": {}
          }
        ]
      }

   2. Aggiungere il seguente criterio authorization alla sezione 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>" ]
              }
            }
          }
        ]
      }

      dove:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica come concedere l'accesso al percorso:

        • "AUTHENTICATION_ONLY": concede l'accesso solo agli utenti finali che sono stati autenticati correttamente. In questo caso, la proprietà "isAnonymousAccessAllowed" nel criterio authentication della specifica di distribuzione API non ha alcun effetto.
        • "ANY_OF": concede l'accesso solo agli utenti finali che sono stati autenticati correttamente, a condizione che la funzione del responsabile autorizzazioni abbia restituito anche uno degli ambiti di accesso specificati nella proprietà allowedScope. In questo caso, la proprietà "isAnonymousAccessAllowed" nel criterio authentication della specifica di distribuzione API non ha alcun effetto.
        • "ANONYMOUS": concede l'accesso a tutti gli utenti finali, anche se non sono stati autenticati correttamente. In questo caso, è necessario impostare in modo esplicito la proprietà "isAnonymousAccessAllowed" su true nel criterio authentication della specifica di distribuzione API.
      • "allowedScope": [ "<scope>" ] è una lista delimitata da virgole di una o più stringhe che corrispondono agli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni. In questo caso, è necessario impostare la proprietà type su "ANY_OF" (la proprietà "allowedScope" viene ignorata se la proprietà type è impostata su "AUTHENTICATION_ONLY" o "ANONYMOUS"). Si noti inoltre che se si specificano più ambiti, l'accesso all'instradamento viene concesso se uno qualsiasi degli ambiti specificati viene restituito dalla funzione del responsabile autorizzazioni.

      Ad esempio, il seguente criterio di richiesta definisce un instradamento /hello che consente solo agli utenti finali autenticati con l'ambito read:hello di accedervi:

      {
        "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. Aggiungere un criterio di richiesta authorization per tutti gli instradamenti rimanenti nella specifica di distribuzione API.
   Nota
   
   

   Se non si include un criterio authorization per un instradamento particolare, viene concesso l'accesso come se tale criterio esistesse e la proprietà type fosse impostata su "AUTHENTICATION_ONLY". In altre parole, indipendentemente dall'impostazione della proprietà isAnonymousAccessAllowed nel criterio authentication della specifica di distribuzione API:

   • solo gli utenti finali autenticati possono accedere al percorso
   • tutti gli utenti finali autenticati possono accedere all'instradamento indipendentemente dagli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni
   • gli utenti finali anonimi non possono accedere al percorso
4. Salvare il file JSON contenente la specifica di distribuzione API.

5. Utilizzare la specifica di distribuzione API quando si crea o si aggiorna una distribuzione API nei modi riportati di seguito.

   • specificando il file JSON nella console quando si seleziona l'opzione Carica un'interfaccia API esistente
   • specificando il file JSON in una richiesta all'API REST del gateway API

   Per ulteriori informazioni, vedere Distribuzione di un'interfaccia API in un gateway API mediante la creazione di una distribuzione API e Aggiornamento di un gateway API o di una distribuzione API.

6. (Facoltativo) Confermare che l'interfaccia API sia stata distribuita correttamente chiamandola (vedere Chiamata di un'interfaccia API distribuita in un gateway API).

La seguente specifica di distribuzione API definisce:

• Criterio di richiesta di autenticazione che chiama una funzione del responsabile autorizzazioni per più argomenti per eseguire l'autenticazione.
• Criterio di richiesta di autorizzazione che specifica le azioni che gli utenti finali autenticati possono eseguire.

{
  "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": {
        "category": "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" ]
        }
      }
    }
  ]
}

Il criterio di richiesta di autenticazione in questa specifica di distribuzione API:

• Specifica la funzione del responsabile autorizzazioni multi-argomento da chiamare per eseguire l'autenticazione e definisce gli argomenti xapikey, referer, state, city, cert, body e host da passare alla funzione del responsabile autorizzazioni. I valori di questi argomenti vengono ottenuti da variabili di contesto con valori della richiesta originale.
• Definisce una chiave cache personalizzata per identificare in modo univoco la risposta inserita nella cache restituita dalla funzione del responsabile autorizzazioni. Anziché utilizzare la chiave cache predefinita (che include tutti gli argomenti inviati alla funzione del responsabile autorizzazioni ed è consigliata), questo criterio di richiesta di autenticazione specifica che la chiave cache deve comprendere solo i valori degli argomenti xapikey e referrer passati alla funzione del responsabile autorizzazioni.
• Include un criterio di errore di convalida che modifica la risposta di errore di convalida predefinita per sostituire il codice di stato HTTP 401 predefinito con il valore della variabile di contesto request.auth[responseCode]. La variabile di contesto request.auth[responseCode] ha il valore di un parametro di autenticazione (in questo caso, denominato responseCode) restituito dalla funzione del responsabile autorizzazioni. Analogamente, il messaggio di errore di convalida predefinito viene sostituito con una stringa di messaggio personalizzata ("Unfortunately, authentication failed.").
• Include un criterio di richiesta di trasformazione dell'intestazione all'interno del criterio di errore di convalida che aggiunge l'intestazione location alla risposta di errore di convalida. All'intestazione location viene assegnato il valore della variabile di contesto request.auth[location], che ha il valore di un parametro di autenticazione (in questo caso, denominato location) restituito dalla funzione del responsabile autorizzazioni. Il criterio di richiesta di trasformazione dell'intestazione rimuove anche le intestazioni denominate topSecret dalla risposta.

Il criterio di richiesta di autorizzazione in questa specifica di distribuzione API consente solo agli utenti finali autenticati dalla funzione del responsabile autorizzazioni e con l'ambito read:hello di accedere all'instradamento /hello.

Per aggiungere criteri di autenticazione e richiesta di autorizzazione per i token di accesso a un singolo argomento a una specifica di distribuzione API utilizzando la console, procedere come segue.

1. Creare o aggiornare una distribuzione API utilizzando la console, selezionare l'opzione Da zero e immettere i dettagli nella pagina Informazioni di base.

   Per ulteriori informazioni, vedere Distribuzione di un'interfaccia API in un gateway API mediante la creazione di una distribuzione API e Aggiornamento di un gateway API o di una distribuzione API.

2. Fare clic su Avanti per visualizzare la pagina Autenticazione.

3. Selezionare Autenticazione singola per specificare che si desidera utilizzare un singolo server di autenticazione per tutte le richieste.

   Queste istruzioni si basano sul presupposto che si desidera utilizzare un singolo server di autenticazione. In alternativa, se si desidera utilizzare più server di autenticazione, selezionare Autenticazione multipla e seguire le istruzioni in Utilizzo della console per aggiungere più server di autenticazione alla stessa distribuzione API.

4. Selezionare o deselezionare la casella di controllo Abilita accesso anonimo per specificare se gli utenti finali non autenticati (ovvero anonimi) possono accedere agli instradamenti nella distribuzione dell'API.

   Per impostazione predefinita, questa opzione non è selezionata. Se non si desidera che utenti anonimi possano accedere ai percorsi, non selezionare questa opzione. Tenere presente che se si seleziona questa opzione, è inoltre necessario specificare in modo esplicito ogni instradamento per il quale è consentito l'accesso anonimo selezionando Anonimo come Tipo di autorizzazione nel criterio di autorizzazione di ogni instradamento.

5. Selezionare Funzione responsabile autorizzazioni dalla lista di opzioni Tipo di autenticazione.
6. Specificare la funzione del responsabile autorizzazione a argomento singolo da utilizzare per autenticare il token di accesso a argomento singolo:
   • Applicazione Oracle Functions in <compartment-name>: il nome dell'applicazione nelle funzioni OCI che contengono la funzione del responsabile autorizzazioni. È possibile selezionare un'applicazione da un altro compartimento.
   • Nome funzione: il nome della funzione del responsabile autorizzazioni in Funzioni OCI.
7. Selezionare Funzione del responsabile autorizzazioni ad argomento singolo per specificare che si desidera passare un token di accesso ad argomento singolo in un'intestazione o parametro di query a una funzione del responsabile autorizzazioni ad argomento singolo.
8. Nel pannello Token di accesso, identificare il token di accesso da utilizzare per l'autenticazione.
   • Posizione token: selezionare Intestazione o Parametro query per specificare la posizione del token di accesso nella richiesta.
   • Nome intestazione token o Nome parametro token: a seconda della posizione del token di accesso, immettere il nome dell'intestazione o del parametro di query contenente il token di accesso.

9. Fare clic su Avanti per immettere i dettagli relativi ai singoli instradamenti nella distribuzione API nella pagina Instradamenti.

10. Nella sezione Route 1 specificare il primo instradamento nella distribuzione API che esegue il mapping di un percorso e di uno o più metodi a un servizio backend:

    • Percorso: un percorso per le chiamate API che utilizzano i metodi elencati per il servizio backend. Tenere presente che il percorso di instradamento specificato è il seguente:

      • è relativo al prefisso del percorso di distribuzione
      • deve essere preceduta da una barra ( / ) e può essere solo la singola barra
      • può contenere più barre in avanti (a condizione che non siano adiacenti) e può terminare con una barra in avanti
      • può includere caratteri alfanumerici maiuscoli e minuscoli
      • può includere i caratteri speciali $ - _ . + ! * ' ( ) , % ; : @ & =
      • può includere parametri e caratteri jolly (vedere Aggiunta di parametri di percorso e caratteri jolly ai percorsi di instradamento)
    • Metodi: uno o più metodi accettati dal servizio backend, separati da virgole. Ad esempio, GET, PUT.

    • Aggiungere un backend singolo o Aggiungere più backend: indica se instradare tutte le richieste allo stesso backend o instradare le richieste a backend diversi in base alla variabile di contesto e alle regole immesse.

      Queste istruzioni presuppongono di voler utilizzare un singolo backend, quindi selezionare Aggiungi un backend singolo. In alternativa, se si desidera utilizzare backend diversi, selezionare Aggiungi più backend e seguire le istruzioni in Utilizzo della console per aggiungere la selezione backend dinamica a una specifica di distribuzione API.

    • Tipo backend: il tipo di servizio backend, ovvero uno dei seguenti:
      • HTTP: per un backend HTTP, è inoltre necessario specificare un URL, i dettagli del timeout e se disabilitare la verifica SSL (vedere Aggiunta di un URL HTTP o HTTPS come backend del gateway API).
      • Oracle Functions: per un backend OCI Functions, è necessario specificare anche l'applicazione e la funzione (vedere Aggiunta di una funzione nelle funzioni OCI come backend del gateway API).
      • Risposta scorte: per un back-end di risposta scorte, è necessario specificare anche il codice di stato HTTP, il contenuto nel corpo della risposta e uno o più campi di intestazione HTTP (vedere Aggiunta di risposte scorte come backend del gateway API).

11. Per specificare un criterio di autorizzazione applicabile a un singolo instradamento, fare clic su Mostra criteri richiesta di instradamento, fare clic sul pulsante Aggiungi accanto a Autorizzazione e specificare:

    • Tipo di autorizzazione: procedura per concedere l'accesso all'instradamento. Specificare:

      • Qualsiasi: concedere l'accesso solo agli utenti finali che sono stati autenticati correttamente, a condizione che la funzione del responsabile autorizzazioni abbia restituito anche uno degli ambiti di accesso specificati nel campo Ambito consentito. In questo caso, l'opzione Abilita accesso anonimo del criterio di autenticazione non ha alcun effetto.
      • Anonimo: concede l'accesso a tutti gli utenti finali, anche se la funzione del responsabile autorizzazioni non li ha autenticati correttamente. In questo caso, è necessario aver selezionato l'opzione Abilita accesso anonimo del criterio di autenticazione.
      • Solo autenticazione: concede l'accesso solo agli utenti finali che sono stati autenticati correttamente dalla funzione del responsabile autorizzazioni. In questo caso, l'opzione Abilita accesso anonimo del criterio di autenticazione non ha alcun effetto.
    • Ambito consentito: se si seleziona Qualsiasi come Tipo di autorizzazione, immettere una lista delimitata da virgole di una o più stringhe che corrispondono agli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni. L'accesso verrà concesso solo agli utenti finali che sono stati autenticati correttamente se la funzione del responsabile autorizzazioni restituisce uno degli ambiti di accesso specificati. Ad esempio read:hello
    Nota
    
    

    Se non si include un criterio di autorizzazione per un instradamento particolare, viene concesso l'accesso come se tale criterio esistesse e l'opzione Tipo di autorizzazione fosse impostata su Solo autenticazione. In altre parole, indipendentemente dall'impostazione dell'opzione Abilita accesso anonimo del criterio di autenticazione:

    • solo gli utenti finali autenticati possono accedere al percorso
    • tutti gli utenti finali autenticati possono accedere all'instradamento indipendentemente dagli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni
    • gli utenti finali anonimi non possono accedere al percorso
12. Fare clic su Successivo per esaminare i dettagli immessi per la distribuzione API.
13. Fare clic su Crea o su Salva modifiche per creare o aggiornare la distribuzione API.
14. (Facoltativo) Confermare che l'interfaccia API sia stata distribuita correttamente chiamandola (vedere Chiamata di un'interfaccia API distribuita in un gateway API).

Per aggiungere criteri di autenticazione e richiesta di autorizzazione per i token di accesso a un singolo argomento a una specifica di distribuzione API in un file JSON, effettuare le operazioni riportate di seguito.

1. Utilizzando l'editor JSON preferito, modificare la specifica di distribuzione API esistente alla quale si desidera aggiungere la funzionalità di autenticazione e autorizzazione oppure creare una nuova specifica di distribuzione API (vedere Creazione di una specifica di distribuzione API).

   La specifica di distribuzione API includerà almeno una sezione routes contenente:

   • Un percorso. Ad esempio /hello
   • Uno o più metodi. Ad esempio, GET
   • Definizione di un back end. Ad esempio, un URL o l'OCID di una funzione in Funzioni OCI.

   Ad esempio, la seguente specifica di distribuzione API di base definisce una semplice funzione serverless Hello World in Funzioni OCI come un singolo backend:

   {
     "routes": [
       {
         "path": "/hello",
         "methods": ["GET"],
         "backend": {
           "type": "ORACLE_FUNCTIONS_BACKEND",
           "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
         }
       }
     ]
   }

2. Aggiungere un criterio di richiesta authentication che si applica a tutti gli instradamenti nella specifica di distribuzione API:

   1. Se non esiste già, inserire una sezione requestPolicies prima della sezione routes. Ad esempio:

      
      {
        "requestPolicies": {},
        "routes": [
          {
            "path": "/hello",
            "methods": ["GET"],
            "backend": {
               "type": "ORACLE_FUNCTIONS_BACKEND",
               "functionId": "ocid1.fnfunc.oc1.phx.aaaaaaaaab______xmq"
            }
          }
        ]
      }

   2. Aggiungere il seguente criterio authentication alla nuova sezione 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"
            }
          }
        ]
      }

      dove:

      • <type-value> è il tipo di autenticazione. Per utilizzare una funzione del responsabile autorizzazioni per l'autenticazione, specificare CUSTOM_AUTHENTICATION.
      • "isAnonymousAccessAllowed": <true|false> indica facoltativamente se gli utenti finali non autenticati (ovvero anonimi) possono accedere agli instradamenti nella specifica di distribuzione API. Se non si desidera che gli utenti finali anonimi possano accedere ai percorsi, impostare questa proprietà su false. Se non si include questa proprietà nel criterio authentication, viene utilizzato il valore predefinito false. Tenere presente che se si include questa proprietà e la si imposta su true, è inoltre necessario specificare in modo esplicito ogni instradamento per il quale è consentito l'accesso anonimo impostando la proprietà type su "ANONYMOUS" nel criterio authorization di ogni instradamento.
      • <function-ocid> è l'OCID della funzione del responsabile autorizzazioni distribuita nelle funzioni OCI.
      • <"tokenHeader"|"tokenQueryParam">: <"<token-header-name>"|"<token-query-param-name>"> indica se si tratta di un'intestazione di richiesta che contiene il token di accesso (e, in caso affermativo, il nome dell'intestazione) o un parametro di query che contiene il token di accesso (e, in caso affermativo, il nome del parametro di query). Si noti che è possibile specificare "tokenHeader": "<token-header-name>" o "tokenQueryParam": "<token-query-param-name>">, ma non entrambi.

      Ad esempio, il seguente criterio authentication specifica una funzione OCI che convaliderà il token di accesso nell'intestazione della richiesta di autorizzazione:

      {
        "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"
            }
          }
        ]
      }

3. Aggiungere un criterio di richiesta authorization per ogni instradamento nella specifica di distribuzione API:

   1. Inserire una sezione requestPolicies dopo la sezione backend della prima route, se non esiste già. Ad esempio:

      
      {
        "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. Aggiungere il seguente criterio authorization alla sezione 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>" ]
              }
            }
          }
        ]
      }

      dove:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica come concedere l'accesso al percorso:

        • "AUTHENTICATION_ONLY": concede l'accesso solo agli utenti finali che sono stati autenticati correttamente. In questo caso, la proprietà "isAnonymousAccessAllowed" nel criterio authentication della specifica di distribuzione API non ha alcun effetto.
        • "ANY_OF": concede l'accesso solo agli utenti finali che sono stati autenticati correttamente, a condizione che la funzione del responsabile autorizzazioni abbia restituito anche uno degli ambiti di accesso specificati nella proprietà allowedScope. In questo caso, la proprietà "isAnonymousAccessAllowed" nel criterio authentication della specifica di distribuzione API non ha alcun effetto.
        • "ANONYMOUS": concede l'accesso a tutti gli utenti finali, anche se non sono stati autenticati correttamente. In questo caso, è necessario impostare in modo esplicito la proprietà "isAnonymousAccessAllowed" su true nel criterio authentication della specifica di distribuzione API.
      • "allowedScope": [ "<scope>" ] è una lista delimitata da virgole di una o più stringhe che corrispondono agli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni. In questo caso, è necessario impostare la proprietà type su "ANY_OF" (la proprietà "allowedScope" viene ignorata se la proprietà type è impostata su "AUTHENTICATION_ONLY" o "ANONYMOUS"). Si noti inoltre che se si specificano più ambiti, l'accesso all'instradamento viene concesso se uno qualsiasi degli ambiti specificati viene restituito dalla funzione del responsabile autorizzazioni.

      Ad esempio, il seguente criterio di richiesta definisce un instradamento /hello che consente solo agli utenti finali autenticati con l'ambito read:hello di accedervi:

      {
        "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. Aggiungere un criterio di richiesta authorization per tutti gli instradamenti rimanenti nella specifica di distribuzione API.
   Nota
   
   

   Se non si include un criterio authorization per un instradamento particolare, viene concesso l'accesso come se tale criterio esistesse e la proprietà type fosse impostata su "AUTHENTICATION_ONLY". In altre parole, indipendentemente dall'impostazione della proprietà isAnonymousAccessAllowed nel criterio authentication della specifica di distribuzione API:

   • solo gli utenti finali autenticati possono accedere al percorso
   • tutti gli utenti finali autenticati possono accedere all'instradamento indipendentemente dagli ambiti di accesso restituiti dalla funzione del responsabile autorizzazioni
   • gli utenti finali anonimi non possono accedere al percorso
4. Salvare il file JSON contenente la specifica di distribuzione API.

5. Utilizzare la specifica di distribuzione API quando si crea o si aggiorna una distribuzione API nei modi riportati di seguito.

   • specificando il file JSON nella console quando si seleziona l'opzione Carica un'interfaccia API esistente
   • specificando il file JSON in una richiesta all'API REST del gateway API

   Per ulteriori informazioni, vedere Distribuzione di un'interfaccia API in un gateway API mediante la creazione di una distribuzione API e Aggiornamento di un gateway API o di una distribuzione API.

6. (Facoltativo) Confermare che l'interfaccia API sia stata distribuita correttamente chiamandola (vedere Chiamata di un'interfaccia API distribuita in un gateway API).