API Gateway:Configure custom authentication and authorization

Contexto

Os servidores geralmente dependem de credenciais (tokens) nas requisições do cliente para proteger as comunicações de APIs expostas externamente.

• Se os seus tokens forem JSON Web Tokens (JWTs), você pode validar suas assinaturas em qualquer lugar usando uma chave pública, sem acessar um service de autenticação centralizado.

• Se os seus tokens usarem um formato personalizado, o servidor deve chamar um service centralizado para realizar verificações de autenticação e autorização. Esse processo protege as comunicações da API. O Cloud-native API Gateway oferece suporte a esse método de autenticação e autorização personalizado.

O exemplo a seguir ilustra o fluxo de processamento de requisições após a integração do Cloud-native API Gateway com um service de autenticação personalizado.

1. Um cliente envia uma requisição de autenticação, como uma operação de login, para o gateway.

2. O gateway encaminha a requisição de autenticação diretamente para o service de autenticação.

3. O service de autenticação valida as credenciais na requisição, como nome de usuário e senha. Após a validação bem-sucedida, ele retorna um token para o gateway, que então repassa o token para o cliente.

4. O cliente envia uma requisição de negócio, como uma requisição para o caminho /order para fazer um pedido. A requisição inclui o token emitido após a autenticação bem-sucedida.

5. O gateway intercepta o caminho (incluindo parâmetros de consulta), o método HTTP (como GET ou POST) e o token da requisição de negócio original. Ele usa essas informações para construir uma nova requisição e a envia para o service de autenticação personalizado para autorização. No console do gateway, configure o cabeçalho HTTP onde o token está localizado. Você também pode permitir que o corpo da requisição original seja incluído.

   Se a API de autenticação do service de autenticação personalizado for /validateToken, o gateway forma o caminho real da requisição de autorização anexando o caminho da requisição de negócio original ao caminho da API de autenticação, resultando em /validateToken/order.

6. Quando o service de autenticação recebe a requisição de autorização, ele pode validar o token e verificar se o cliente está autorizado a acessar o caminho da requisição original.

   • Se o seu service de autenticação puder modificar o código de status HTTP em sua resposta, você poderá usar o código de status para indicar o resultado da autorização.

     • Um código de status HTTP 200 indica que o token é válido e está autorizado a acessar o recurso de backend. O gateway então encaminha a requisição de negócio original para o service de backend protegido. Após receber a resposta do backend, o gateway a encaminha para o cliente, concluindo a operação de realização do pedido.

     • Um código de status HTTP 401 ou 403 indica que o token é inválido ou não está autorizado a acessar o recurso de backend. O gateway retorna imediatamente a resposta do service de autenticação para o cliente, fazendo com que a operação de realização do pedido falhe.

   • Se o seu service de autenticação precisar sempre retornar um código de status HTTP 200 devido a restrições de negócio, você pode usar o cabeçalho HTTP integrado x-mse-external-authz-check-result.

     • Se o service de autenticação retornar uma resposta com o cabeçalho x-mse-external-authz-check-result definido como true, isso indica que o token é válido e tem permissão para acessar o recurso de backend. O gateway então encaminha a requisição original para o service de backend protegido e repassa a resposta de volta para o cliente, concluindo a operação de realização do pedido.

     • Se o service de autenticação retornar uma resposta com o cabeçalho x-mse-external-authz-check-result definido como false, isso indica que o token é inválido ou não tem permissão para acessar o recurso de backend. O gateway retorna a resposta do service de autenticação diretamente para o cliente, fazendo com que a operação de realização do pedido falhe.

Crie uma regra de autenticação personalizada

1. Faça login no console do API Gateway.

2. No painel de navegação à esquerda, clique em Cloud-native API Gateway > Instance. Na barra de navegação superior, selecione uma região.

3. Na página Instance, clique no nome da instância do gateway de destino.

4. No painel de navegação à esquerda, clique em Security Management > Global Authentication.

5. Na página Global Authentication, clique em Create Authentication. No painel Create Authentication, configure os parâmetros e clique em OK.

   Parâmetro	Nota: Custom Authentication Service
   Enable	Ative a autenticação e autorização para o Cloud-native API Gateway.
   Authentication Name	Um nome personalizado para a regra de autenticação e autorização.
   Authentication Type	Selecione Custom Authentication Service.
   Authentication Service	O service de backend usado para autenticação e autorização. Você pode adicionar services no gerenciamento de services. Para mais informações, consulte Add a service. Nota Apenas services que usam o protocolo HTTP são suportados. Services que usam outros protocolos, como Dubbo, não são suportados. Se um Kubernetes Service tiver várias portas, a primeira porta será usada por padrão. Se você quiser usar uma porta diferente, crie um Kubernetes Service adicional no Container Service for Kubernetes (ACK) que exponha apenas a porta de destino.
   Authentication API	O caminho da API fornecido pelo service de autenticação. O gateway usa esse caminho para correspondência de prefixo. Por exemplo, se o seu service de autenticação for construído em Spring MVC, expuser a API de autenticação /check e você quiser lidar com requisições para caminhos que começam com /check/, configure-o da seguinte forma: @RequestMapping("/check/") public ResponseEntity<RestResult<String>> check(){}
   Token Location	A localização do token no cabeçalho da requisição, geralmente Authorization ou Cookie. Use Select em uma lista ou Add Manually e defina a localização do token.
   Allowed Headers in Authentication Rrequest	Especifica quais cabeçalhos da requisição original do cliente devem ser encaminhados para o service de autenticação. Nota Os cabeçalhos Host, Method, Path e Content-Length são incluídos por padrão e não precisam ser adicionados manualmente.
   Allowed Headers in Authentication Response	Especifica quais cabeçalhos da resposta do service de autenticação devem ser adicionados à requisição enviada para o service de backend. Nota Se um cabeçalho especificado aqui já existir na requisição do cliente, o gateway substituirá seu valor.
   Allow Body in Authentication Request	Allow Body in Authentication Request: Inclui o corpo da requisição original do cliente na requisição enviada para o service de autenticação. Maximum Body Size: O tamanho máximo do corpo da requisição que pode ser encaminhado, em bytes.
   Timeout Period	O tempo máximo, em segundos, para aguardar uma resposta do service de autenticação. Padrão: 10.
   Mode	Especifica o comportamento quando o service de autenticação está indisponível. Há suporte para Loose Mode e Strict Mode. Recomendamos o uso do Loose Mode. Loose Mode: Se o service de autenticação estiver indisponível (por exemplo, a conexão falhar ou o service retornar um erro 5xx), o gateway permitirá que a requisição do cliente prossiga. Strict Mode: Se o service de autenticação estiver indisponível (por exemplo, a conexão falhar ou o service retornar um erro 5xx), o gateway rejeitará a requisição do cliente.
   Simple Conditions	Ao lado de Authorization, clique em Simple Conditions. Este modo oferece suporte a Whitelist Mode e Blacklist Mode. Whitelist Mode: As requisições que correspondem aos hosts e caminhos na lista de permissões podem ignorar a validação. Todos os outros hosts e caminhos exigem validação. Blacklist Mode: As requisições que correspondem aos hosts e caminhos na lista de bloqueios exigem validação. Todos os outros hosts e caminhos podem ser acessados diretamente. Clique em Rule Condition para definir condições com base no domínio, caminho e cabeçalhos da requisição. Domain Name: O domínio do host requisitado. Path: O caminho da API requisitado. Path Match Condition: O caminho pode ser correspondido usando correspondência exata, correspondência de prefixo ou correspondência de expressão regular. Exact Match: Insira um caminho completo, por exemplo, /app/v1/order. Prefix Match: Insira um prefixo de caminho terminando com um asterisco (). Por exemplo, para corresponder a todas as requisições que começam com /app, insira /app/. Regular Expression Match: A sintaxe segue o padrão Google RE2. Para mais informações, consulte RE2 Syntax. Case sensitive: Torna a correspondência de caminho sensível a maiúsculas e minúsculas. Header: O cabeçalho da requisição. Clique em Request Header e configure vários cabeçalhos. Uma operação lógica AND é executada nos cabeçalhos. HeaderKey: O nome do campo de cabeçalho. Condition: A condição de correspondência para o cabeçalho. Equals To: O valor do cabeçalho especificado é igual ao valor inserido. Does Not Equal To: O valor do cabeçalho especificado não é igual ao valor inserido. Exists: O cabeçalho especificado existe na requisição. Does Not Exist: O cabeçalho especificado não existe na requisição. Contains: O valor do cabeçalho especificado contém o valor inserido. Excludes: O valor do cabeçalho especificado não contém o valor inserido. Prefix: O valor do cabeçalho especificado começa com o valor inserido. Suffix: O valor do cabeçalho especificado termina com o valor inserido. Regular Expression Match: O valor do cabeçalho especificado corresponde à expressão regular inserida. A sintaxe segue o padrão Google RE2. Para mais informações, consulte RE2 Syntax. Value: O valor a ser correspondido com o campo de cabeçalho.
   Complex Conditions	Ao lado de Authorization, clique em Complex Conditions. Este modo permite definir regras de autorização usando uma configuração YAML da estrutura de dados permission do Envoy. Você pode criar regras com lógica combinada AND, OR e NOT. O gateway envia requisições que correspondem às condições configuradas para autenticação. Requisições não correspondentes podem acessar os recursos diretamente. Nota Para uma descrição completa dos campos da estrutura de dados permission, consulte a documentação oficial do Envoy. Para exemplos de configuração, consulte Complex condition authorization examples.

   Retorne à página Global Authentication. Se a nova regra aparecer na lista, ela foi criada com sucesso.

Visualize e gerencie os services de autenticação

1. Faça login no console do API Gateway.

2. No painel de navegação à esquerda, clique em Cloud-native API Gateway > Instance. Na barra de navegação superior, selecione uma região.

3. Na página Instance, clique no nome da instância do gateway de destino.

4. No painel de navegação à esquerda, clique em Security Management > Global Authentication.

5. Na página Authentication, encontre a regra de autenticação de destino e clique em Description na coluna Actions. Visualize as Basic Information e a Authentication Configuration, e gerencie as Authorization Information.

   A seção Authentication Configuration inclui campos como Authentication Service, Authentication API, Token Location, Timeout Period, Mode (como Loose Mode), Allow Body in Authentication Request, Allowed Headers in Authentication Request e Allowed Headers in Authentication Response. A seção Authorization Information exibe o modo atual (como Whitelist Mode). Várias condições de regra têm uma relação lógica "OR" entre si. A lista de regras de autorização inclui colunas como Request Domain, Request Path Matchers, case-sensitive e Request Header Matchers.

   Na seção Authorization Information, clique em Create Authorization. Na caixa de diálogo exibida, insira o Request Domain Name e o Request Path, selecione um Match Mode e, em seguida, clique em OK para adicionar a regra de autorização.

Operações relacionadas

• Ative a autenticação e autorização: Na página Global Authentication, encontre a regra de destino e clique em Enable na coluna Actions para ativá-la.

• Desative a autenticação e autorização: Na página Global Authentication, encontre a regra de destino e clique em Close na coluna Actions para desativá-la.

• Edite a autenticação e autorização: Na página Global Authentication, encontre a regra de destino e clique em Edit na coluna Actions e modifique sua configuração.

• Exclua a autenticação e autorização: Na página Global Authentication, encontre a regra de destino e clique em Delete na coluna Actions para removê-la.

Exemplos de autorização com condições complexas

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

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