Adicionando Políticas de Solicitação de Autenticação e Autorização para Tokens de Acesso de Vários Argumentos e Funções de Autorizador (Recomendado)

Para adicionar políticas de solicitação de autenticação e autorização para tokens de acesso de vários argumentos a uma especificação da implantação da API usando a Console:

1. Crie ou atualize uma implantação de API usando a Console, selecione a opção Criar implantação e informe detalhes na página Informações Básicas.

   Para obter mais informações, consulte Implantando uma API em um Gateway da API Criando uma Implantação de API e Updating an API Gateway.

2. Selecione Próximo para exibir a página Autenticação.

3. Selecione Autenticação Única para especificar que você deseja usar um único servidor de autenticação para todas as solicitações.

   Estas instruções pressupõem que você deseja usar um único servidor de autenticação. Como alternativa, se quiser usar vários servidores de autenticação, selecione Multi-Authentication e siga as instruções em Usando a Console para Adicionar Vários Servidores de Autenticação à mesma Implantação de API.

4. Marque ou desmarque Ativar acesso anônimo para especificar se os usuários finais não autenticados (ou seja, anônimos) podem acessar rotas na implantação de API.

   Por padrão, essa opção não está selecionada. Se você nunca quiser que usuários anônimos possam acessar rotas, não selecione essa opção. Observe que, se você selecionar essa opção, também terá que especificar explicitamente cada rota para a qual o acesso anônimo é permitido, selecionando Anônimo como o tipo de Autorização em cada política da autorização.

5. Selecione Função do autorizador na lista de opções Tipo de autenticação.
6. Especifique a função de autorizador de vários argumentos a ser usada para autenticar o token de acesso de vários argumentos:
   • Aplicativo Oracle Functions: O nome do aplicativo no OCI Functions que contém a função de autorizador. Você pode selecionar um aplicativo de outro compartimento.
   • Oracle Function: O nome da função de autorizador no OCI Functions.
7. Selecione Função de autorizador de vários argumentos para especificar que você deseja transmitir um ou mais elementos de uma solicitação como um token de acesso a uma função de autorizador que possa aceitar tokens de acesso de vários argumentos.
8. No painel Argumentos de função, especifique uma ou mais variáveis de contexto que forneçam valores para passar à função de autorizador como argumentos com nomes de argumento informados:
   1. Especifique uma variável de contexto que forneça um valor para passar à função de autorizador como argumento:
      • Tabela de contexto: Selecione a tabela de contexto que contém a variável de contexto na lista:
        • Tabela de contexto request.query, contendo nomes e valores de parâmetros de consulta incluídos na solicitação
        • Tabela de contexto request.headers, contendo nomes e valores de cabeçalho incluídos na solicitação
        • Tabela de contexto request.cert, contendo uma versão codificada em Base64 do certificado apresentado por um cliente de API e validado com sucesso durante um handshake mTLS
        • Tabela de contexto request.host, contendo o nome do host para o qual a solicitação foi enviada (extraído do campo de cabeçalho Host na solicitação)
        • Tabela de contexto request.body, contendo o corpo da solicitação
      • Nome do cabeçalho ou Nome do parâmetro de consulta: Se você tiver selecionado a tabela de contexto request.headers ou request.params, informe o nome do cabeçalho ou do parâmetro de consulta que deseja passar para a função de autorizador. Por exemplo, X-Api-Key, state.
      • Nome do argumento: Informe o nome do argumento ao qual atribuir o valor da variável de contexto. O argumento é passado para a função de autorizador. O nome do argumento informado deve corresponder ao nome do argumento que a função de autorizador espera receber.
   2. Especifique variáveis de contexto e argumentos adicionais conforme necessário (selecione Outro argumento, se necessário).

9. Opcionalmente, personalize como armazenar em cache a resposta de uma função de autorizador de vários argumentos:

   1. Selecione Opções avançadas.

      O painel Armazenamento em cache dos resultados da função mostra quais argumentos estão presentes na chave do cache. A chave de cache identifica exclusivamente a resposta armazenada em cache retornada da função de autorizador, usando argumentos e valores de argumento informados na solicitação de autenticação original. Por padrão, todos os argumentos e valores de argumentos (exceto um argumento com um valor da tabela de contexto request.body) que você especificou para passar à função de autorizador são usados para criar a chave de cache.

   2. Para adicionar ou remover argumentos da chave de cache, selecione Editar.
   3. Marque ou desmarque os argumentos passados à função de autorizador para incluí-los ou excluí-los da chave de cache.

   Consulte Observações sobre o Armazenamento em Cache dos Resultados da Função de Autorizador de Vários Argumentos.

10. Opcionalmente, personalize como tratar uma resposta de autenticação com falha de uma função de autorizador de vários argumentos configurando uma política de falha de validação:

    1. Selecione Opções avançadas.

       O painel Resposta personalizada para autenticação com falha. mostra o código de status HTTP e o corpo da mensagem a serem retornados ao cliente da API se a função de autorizador não puder autenticar a solicitação. Por padrão, o gateway de API envia um código de status HTTP 401 e o cabeçalho WWW-Authenticate na resposta. Consulte Observações sobre Políticas de Falha de Validação e o Tratamento de Respostas de Autenticação com Falha nas Funções do Autorizador de Vários Argumentos.

    2. Especifique um código de status (e um corpo de mensagem opcional) para retornar ao cliente da API se a função de autorizador não puder autenticar a solicitação:
       • Código de status HTTP: Informe um código de status HTTP alternativo (por exemplo, 500). Como alternativa, você pode incluir uma variável de contexto para retornar o código retornado pela função de autorizador. Por exemplo, se a função de autorizador retornar um código de resposta no parâmetro responseCode, especifique request.auth[responseCode].
       • Corpo da mensagem: Informe um corpo da mensagem. Por exemplo, Unfortunately, authentication failed.O corpo da mensagem pode incluir qualquer variável de contexto (exceto request.body). Por exemplo, Unfortunately, authentication failed ${request.auth[my-auth-variable]}.

    3. Opcionalmente, modifique os cabeçalhos da resposta que o gateway de API retorna ao cliente de API selecionando Opções avançadas e especificando uma política de resposta de transformação de cabeçalho:

       • Para limitar os cabeçalhos incluídos em uma resposta, especifique:

         • Ação: Filtrar.
         • Tipo: Bloquear para remover da resposta os cabeçalhos listados explicitamente ou Permitir para permitir na resposta apenas os cabeçalhos listados explicitamente (quaisquer outros cabeçalhos são removidos da resposta).
         • Nomes de cabeçalhos: A lista de cabeçalhos a serem removidas da resposta ou a permitir a resposta (dependendo da definição de Tipo). Os nomes especificados não diferenciam maiúsculas de minúsculas e não devem ser incluídos em nenhuma outra política de resposta de transformação para a rota (com exceção dos itens filtrados conforme permitido). Por exemplo, User-Agent.

       • Para alterar o nome de um cabeçalho incluído em uma resposta (mantendo seu valor original), especifique:

         • Ação: Renomear.
         • Nome do cabeçalho: O nome original do cabeçalho que está sendo renomeado. O nome especificado não faz distinção entre maiúsculas e minúsculas e não deve ser incluído em nenhuma outra política de resposta de transformação para a rota. Por exemplo, X-Username.
         • Nome do novo cabeçalho: O novo nome do cabeçalho que você estiver renomeando. O nome especificado não faz distinção entre maiúsculas e minúsculas (a capitalização pode ser ignorada) e não deve ser incluído em nenhuma outra política de resposta de transformação para a rota (com exceção dos itens nas listas ALLOW). Por exemplo, X-User-ID.

       • Para adicionar um novo cabeçalho a uma resposta (ou para alterar ou manter os valores de um cabeçalho existente já incluído em uma resposta), especifique:

         • Ação: Definir.

         • Comportamento: Se o cabeçalho já existir, especifique o que fazer com o valor existente do cabeçalho:

           • Substituir, para substituir o valor existente do cabeçalho pelo valor especificado.
           • Anexar, para anexar o valor especificado ao valor existente do cabeçalho.
           • Ignorar, para manter o valor existente do cabeçalho.
         • Nome do cabeçalho: O nome do cabeçalho a ser incluído na resposta (ou para alterar o valor do). O nome especificado não faz distinção entre maiúsculas e minúsculas e não deve ser incluído em nenhuma outra política de resposta de transformação para a rota (com exceção dos itens filtrados conforme permitido). Por exemplo, X-Api-Key.
         • Valores: O valor do novo cabeçalho (ou o valor a ser substituído ou acrescentado ao valor de um cabeçalho existente, dependendo da definição de Comportamento). Você pode especificar vários valores. O valor especificado pode ser uma string simples ou pode incluir variáveis de contexto (exceto request.body) entre delimitadores ${...}. Por exemplo, "value": "zyx987wvu654tsu321".

       Para obter mais informações sobre políticas de resposta da transformação de cabeçalho, consulte Adicionando Políticas da Resposta da Transformação de Cabeçalho

11. Selecione Próximo para informar detalhes de rotas individuais na implantação de API na página Routes.

12. Selecione Adicionar rota e especifique a primeira rota na implantação de API que mapeie um caminho e um ou mais métodos para um serviço de back-end:

    • Caminho: Um caminho para chamadas de API usando os métodos listados para o serviço de back-end. Observe que o caminho da rota que você especificar:

      • é relativo ao prefixo do caminho de implantação
      • deve ser precedido por uma barra ( / ) e pode ser apenas uma barra
      • pode conter várias barras (desde que elas não sejam adjacentes) e pode terminar com uma barra
      • pode incluir caracteres alfanuméricos maiúsculos e minúsculos
      • pode incluir os caracteres especiais $ - _ . + ! * ' ( ) , % ; : @ & =
      • pode incluir parâmetros e curingas (consulte Adicionando Parâmetros de Caminho e Curingas a Caminhos de Rota)
    • Métodos: Um ou mais métodos aceitos pelo serviço de back-end, separados por vírgulas. Por exemplo, GET, PUT.

    • Adicionar um único backend ou Adicionar vários backends: Se todas as solicitações devem ser roteadas para o mesmo back end ou para rotear solicitações para backends diferentes de acordo com a variável de contexto e as regras informadas.

      Estas instruções supõem que você deseja usar um único back-end; portanto, selecione Adicionar um único backend. Como alternativa, se você quiser usar back-ends diferentes, selecione Adicionar vários back-ends e siga as instruções em Usando a Console para Adicionar a Seleção de Back-End Dinâmico a uma Especificação de Implantação de API.

    • Tipo de backend: O tipo do serviço de back-end, como um dos seguintes:
      • HTTP: Para um back-end de HTTP, você também precisa especificar um URL, detalhes de timeout e se deve desativar a verificação SSL (consulte Adicionando um URL HTTP ou HTTPS como um Back-End do Serviço API Gateway).
      • Oracle Functions: Para um back-end do OCI Functions, você também precisa especificar a aplicação e função (consulte Adicionando uma Função nas Funções do OCI como um Back-end do API Gateway).
      • Resposta de estoque: Para um back-end de resposta de estoque, você também precisa especificar o código de status HTTP, o conteúdo no corpo da resposta e um ou vários campos do cabeçalho HTTP (consulte Adicionando Respostas de Estoque como um Back-end do API Gateway).
      • Log-out: Para um back-end de log-out, você também precisa especificar uma lista de URLs permitidos para os quais uma solicitação pode ser redirecionada para revogar tokens e, opcionalmente, dados para passar para o URL de log-out (consulte Adicionando Log-out como um Back-End do Serviço API Gateway).

13. Para especificar uma política de autorização que se aplique a uma rota individual, selecione Mostrar políticas de solicitação de rota, selecione o botão Adicionar ao lado da Autorização e especifique:

    • Tipo de autorização: Como conceder acesso à rota. Especifique:

      • Qualquer: Só concede acesso a usuários finais que foram autenticados com sucesso, contanto que a função do autorizador também tenha retornado um dos escopos do acesso que você especificar no campo Adicionar escopo permitido. Nesse caso, a opção Ativar acesso anônimo da política da autenticação não tem efeito.
      • Anônimo: Concede acesso a todos os usuários finais, mesmo que eles não tenham sido autenticados com sucesso pela função de autorizador. Nesse caso, você deve ter selecionado a opção Ativar acesso anônimo da política.
      • Somente autenticação: Só concede acesso a usuários finais que foram autenticados com sucesso pela função de autorizador. Nesse caso, a opção Ativar acesso anônimo da política da autenticação não tem efeito.
    • Adicionar escopo permitido: Se você selecionou Qualquer como o tipo de Autorização, informe uma lista delimitada pela vírgula de um ou mais strings que correspondem aos escopos do acesso retornados pela função do autorizador. O acesso só será concedido aos usuários finais que foram autenticados com sucesso se a função de autorizador retornar um dos escopos de acesso especificados. Por exemplo, read:hello
    Observação
    
    

    Se você não incluir uma política de autorização para uma rota específica, o acesso será concedido como se tal política existisse e o tipo de autorização será definido comoSomente autenticação. Em outras palavras, independentemente da definição da opção Ativar acesso anônimo da diretiva de autenticação:

    • somente usuários finais autenticados podem acessar a rota
    • todos os usuários finais autenticados podem acessar a rota, independentemente dos escopos de acesso retornados pela função de autorizador
    • usuários finais anônimos não podem acessar a rota
14. Selecione Criar e Próximo para revisar os detalhes inseridos para a implantação de API.
15. Selecione Criar ou Atualizar para criar ou atualizar a implantação de API.
16. (Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

Para adicionar políticas de solicitação de autenticação e autorização para tokens de acesso de vários argumentos a uma especificação da implantação da API em um arquivo JSON:

1. Usando seu editor de JSON preferido, edite a especificação de implantação de API existente à qual você deseja adicionar a funcionalidade de autenticação e autorização ou crie uma nova especificação de implantação de API (consulte Criando uma Especificação de Implantação de API).

   No mínimo, a especificação de implantação de API incluirá uma seção routes contendo:

   • Um caminho. Por exemplo, /hello
   • Um ou mais métodos. Por exemplo, GET
   • Uma definição de um back-end. Por exemplo, uma URL ou o OCID de uma função no OCI Functions.

   Por exemplo, a seguinte especificação de implantação básica da API define uma função simples sem servidor do Hello World nas Funções do OCI como um back-end único:

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

2. Adicione uma política de solicitação authentication que se aplique a todas as rotas na especificação de implantação de API:

   1. Insira uma seção requestPolicies antes da seção routes, se ainda não existir uma. Por exemplo:

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

   2. Adicione a seguinte política authentication à nova seção 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"
            }
          }
        ]
      }

      em que:

      • <type-value> é o tipo de autenticação. Para usar uma função de autorizador para autenticação, especifique CUSTOM_AUTHENTICATION.
      • "isAnonymousAccessAllowed": <true|false> indica opcionalmente se usuários finais não autenticados (ou seja, anônimos) podem acessar rotas na especificação de implantação de API. Se você nunca quiser que usuários finais anônimos possam acessar rotas, defina essa propriedade como false. Se você não incluir essa propriedade na política authentication, o padrão false será usado. Observe que, se você não incluir essa propriedade e defini-la como true, também precisará especificar explicitamente cada rota para a qual o acesso anônimo é permitido, definindo a propriedade type como "ANONYMOUS" na política authorization de cada rota.
      • <function-ocid> é o OCID da função de autorizador implantada para o OCI Functions.
      • <argument-n> é o nome do argumento ao qual atribuir o valor de uma variável de contexto, e apenas uma. O argumento é passado para a função de autorizador. O nome do argumento informado deve corresponder ao nome do argumento que a função de autorizador espera receber. É possível incluir vários pares de variáveis de contexto de argumento.
      • <context-variable> é uma variável de contexto cujo valor você deseja atribuir ao argumento correspondente. <context-variable> deve estar no formato <context-table-name> ou <context-table-name>[<key>], em que <context-table-name> é uma das seguintes:
        • request.query, uma tabela de contexto que contém nomes e valores de parâmetros de consulta incluídos na solicitação. Se quiser especificar um parâmetro de consulta, você deverá especificar a tabela de contexto request.query e o nome do parâmetro de consulta como chave, no formato request.query[<query-parameter-name>]. Por exemplo, request.query[state]
        • request.headers, uma tabela de contexto que contém nomes e valores de cabeçalho incluídos na solicitação. Se quiser especificar um cabeçalho, você deverá especificar a tabela de contexto request.headers e o nome do cabeçalho como chave, no formato request.headers[<header-name>]. Por exemplo, request.headers[X-Api-Key]
        • Tabela de contexto request.cert, contendo uma versão codificada em Base64 do certificado apresentado por um cliente de API e validado com sucesso durante um handshake mTLS
        • request.host, uma tabela de contexto que contém o nome do host para o qual a solicitação foi enviada (extraída do campo de cabeçalho Host na solicitação)
        • request.body, uma tabela de contexto que contém o corpo da solicitação.
      • "cacheKey": ["<cache-key-argument-n>", "<cache-key-argument-n>"] opcionalmente restringe a chave de cache ao uso apenas dos argumentos especificados. A chave de cache identifica exclusivamente a resposta armazenada em cache retornada da função de autorizador, usando argumentos e valores de argumento informados na solicitação de autenticação original. Por padrão, todos os argumentos e valores de argumentos (exceto um argumento com um valor da tabela de contexto request.body) na lista parameters: {…} são usados para criar a chave de cache. Um argumento que você especifica para <cache-key-argument-n> deve ser um dos argumentos na lista parameters: {…}. Consulte Observações sobre o Armazenamento em Cache dos Resultados da Função de Autorizador de Vários Argumentos.
   3. Opcionalmente, adicione uma validationFailurePolicy à seção de política 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"
            }
          }
        ]
      }

      em que:

      • "validationFailurePolicy": {…} opcionalmente permite que você altere o código de status HTTP, o corpo da mensagem e os cabeçalhos na resposta ao cliente da API se a função de autorizador não puder autenticar uma solicitação. Por padrão, o gateway de API envia um código de status HTTP 401 e o cabeçalho WWW-Authenticate na resposta. Consulte Observações sobre Políticas de Falha de Validação e o Tratamento de Respostas de Autenticação com Falha nas Funções do Autorizador de Vários Argumentos.
      • <policy-type> é o tipo de política de falha de validação. Para modificar a resposta, especifique MODIFY_RESPONSE.
      • "responseCode": "<alternative-response-code>" especifica um código de status HTTP alternativo. Por exemplo, "responseCode": "500". Como alternativa, você pode incluir uma variável de contexto para retornar o código retornado pela função de autorizador. Por exemplo, se a função de autorizador retornar um código de resposta no parâmetro responseCode, especifique "request.auth[responseCode]".
      • "responseMessage": "<custom-message-body>" especifica o conteúdo a ser incluído no corpo da mensagem. Por exemplo, "responseMessage": "Unfortunately, authentication failed.". O corpo da mensagem pode incluir qualquer variável de contexto (exceto request.body). Por exemplo, "responseMessage": "Unfortunately, authentication failed ${request.auth[my-auth-variable]}".
      • "headerTransformations": {<valid-header-transformation-response-policy>} é uma política de resposta de transformação de cabeçalho válida. Consulte Adicionando Políticas da Resposta à Transformação de Cabeçalho.

3. Adicione uma política de solicitação authorization para cada rota na especificação de implantação de API:

   1. Insira uma seção requestPolicies após a primeira seção backend da rota, se ainda não existir. Por exemplo:

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

   2. Adicione a seguinte política authorization à seção 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>" ]
              }
            }
          }
        ]
      }

      em que:

      • "type": <"AUTHENTICATION_ONLY"|"ANY_OF"|"ANONYMOUS"> indica como conceder acesso à rota:

        • "AUTHENTICATION_ONLY": Só concede acesso a usuários finais que foram autenticados com sucesso. Nesse caso, a propriedade "isAnonymousAccessAllowed" na política authentication da especificação de implantação de API não tem efeito.
        • "ANY_OF": Só concede acesso a usuários finais que foram autenticados com sucesso, desde que a função de autorizador também tenha retornado um dos escopos de acesso especificados na propriedade allowedScope. Nesse caso, a propriedade "isAnonymousAccessAllowed" na política authentication da especificação de implantação de API não tem efeito.
        • "ANONYMOUS":  Concede acesso a todos os usuários finais, mesmo que eles não tenham sido autenticados com sucesso. Nesse caso, você deve definir explicitamente a propriedade "isAnonymousAccessAllowed" como true na política authentication da especificação de implantação de API.
      • "allowedScope": [ "<scope>" ] é uma lista delimitada por vírgulas de uma ou mais strings que correspondem aos escopos de acesso retornados pela função de autorizador. Nesse caso, você deve definir a propriedade type como "ANY_OF" (a propriedade "allowedScope" será ignorada se a propriedade type estiver definida como "AUTHENTICATION_ONLY" ou "ANONYMOUS"). Observe também que, se você especificar mais de um escopo, o acesso à rota será concedido se qualquer um dos escopos especificados for retornado pela função de autorizador.

      Por exemplo, a política de solicitação a seguir define uma rota /hello que só permite que usuários finais autenticados com o escopo read:hello a acessem:

      {
        "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. Adicione uma política de solicitação authorization para todas as rotas restantes na especificação de implantação de API.
   Observação
   
   

   Se você não incluir uma política authorization para uma rota específica, o acesso será concedido como se tal política não existisse e a propriedade type estivesse definida como "AUTHENTICATION_ONLY". Em outras palavras, independentemente da definição da propriedade isAnonymousAccessAllowed na política authentication da especificação de implantação de API:

   • somente usuários finais autenticados podem acessar a rota
   • todos os usuários finais autenticados podem acessar a rota, independentemente dos escopos de acesso retornados pela função de autorizador
   • usuários finais anônimos não podem acessar a rota
4. Salve o arquivo JSON que contém a especificação de implantação de API.

5. Use a especificação de implantação de API ao criar ou atualizar uma implantação de API das seguintes formas:

   • especificando o arquivo JSON na Console quando você seleciona a opção Fazer Upload de uma API de implantação existente
   • especificando o arquivo JSON em uma solicitação à API REST do serviço API Gateway

   Para obter mais informações, consulte Implantando uma API em um Gateway da API Criando uma Implantação de API e Updating an API Gateway.

6. (Opcional) Confirme se a API foi implantada com êxito, chamando-a (consulte Chamando uma API Implantada em um Gateway de API).

A seguinte especificação de implantação de API define:

• Uma política de solicitação de autenticação que chama uma função de autorizador de vários argumentos para executar a autenticação.
• Uma política de solicitação de autorização que especifica o que os usuários finais autenticados podem fazer.

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

A política de solicitação de autenticação nesta especificação de implantação de API:

• Especifica a função de autorizador de vários argumentos a ser chamada para executar a autenticação e define os argumentos xapikey, referer, state, city, cert, body e host para passar para a função de autorizador. Os valores destes argumentos são obtidos a partir de variáveis de contexto que têm valores da solicitação original.
• Define uma chave de cache personalizada para identificar exclusivamente a resposta em cache retornada da função de autorizador. Em vez de usar a chave de cache padrão (que inclui todos os argumentos enviados à função de autorizador e é recomendada), essa política de solicitação de autenticação especifica que a chave de cache deve compreender apenas os valores dos argumentos xapikey e referrer passados para a função de autorizador.
• Inclui uma política de falha de validação que modifica a resposta de falha de validação padrão para substituir o código de status HTTP 401 padrão pelo valor da variável de contexto request.auth[responseCode]. A variável de contexto request.auth[responseCode] tem o valor de um parâmetro de autenticação (nesse caso, chamado responseCode) retornado pela função de autorizador. Da mesma forma, a mensagem de falha de validação padrão é substituída por uma string de mensagem personalizada ("Unfortunately, authentication failed.").
• Inclui uma política de solicitação de transformação de cabeçalho na política de falha de validação que adiciona o cabeçalho location à resposta de falha de validação. O cabeçalho location recebe o valor da variável de contexto request.auth[location], que tem o valor de um parâmetro de autenticação (nesse caso, chamado location) retornado pela função de autorizador. A política de solicitação de transformação de cabeçalho também remove cabeçalhos chamados topSecret da resposta.

A política de solicitação de autorização nesta especificação de implantação de API só permite que os usuários finais autenticados pela função de autorizador e com o escopo read:hello acessem a rota /hello.