Uma parte importante do gerenciamento de APIs em todo o seu ciclo de vida é o controle refinado sobre o acesso à API e o roteamento de tráfego. Os tokens de acesso surgiram como o padrão de fato para gerenciar o acesso às APIs. Uma das vantagens dos esquemas de autenticação baseados em JSON Web Tokens (JWTs) é poder aproveitar as declarações no JWT para implementar esse nível fino de controle de acesso. As permissões podem ser codificadas como declarações personalizadas, que os proprietários de APIs podem usar para controlar o acesso às suas APIs. Depois que o proxy da API valida o JWT, ele tem acesso a todos os campos no token como variáveis e pode basear decisões de acesso neles.
Em uma postagem anterior , discutimos como o API Connectivity Manager pode ajudar operadores e desenvolvedores a trabalhar melhor juntos. As equipes de diferentes linhas de negócios que possuem e operam APIs precisam de controle total à medida que desenvolvem e aprimoram a experiência de suas APIs e serviços.
O API Connectivity Manager fornece políticas que permitem que os proprietários de API configurem configurações de nível de serviço, como autenticação de API, autorização e requisitos de segurança adicionais. Nesta postagem, mostramos como os proprietários de API podem usar a política de roteamento de controle de acesso para impor um controle refinado para rotas específicas e ajustá-lo ainda mais para aplicar por método HTTP e por rota com base em declarações específicas no token.
Você deve ter uma assinatura de avaliação ou paga do F5 NGINX Management Suite , que inclui o Instance Manager e o API Connectivity Manager, juntamente com o NGINX Plus como um gateway de API e o NGINX App Protect para proteger suas APIs. Para começar, solicite uma avaliação gratuita de 30 dias do NGINX Management Suite .
Para obter instruções sobre como instalar o NGINX Management Suite e o API Connectivity Manager, consulte o Guia de instalação .
Digamos que publicamos um proxy de API de depósito com vários endpoints, como inventário , pedidos e assim por diante. Agora queremos introduzir um novo serviço chamado precificação , mas torná-lo acessível apenas a alguns clientes que se inscreveram para um teste beta. Esses clientes são identificados por uma reivindicação chamada betatester
. Neste token de acesso de exemplo, essa afirmação é verdadeira
para o usuário identificado na sub-
reivindicação, user1@abc.com
.
Cabeçalho
{
"criança": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
"alg": "RS256"
}
Carga útil
{
"ver": 1,
"jti": "AT.xxxxxxxxxxxx",
"iss": "https://oauthserver/oauth2/",
"aud": "inventoryAPI",
"iat": 1670290877,
"exp": 1670294477,
"cid": "AcvfDzzzzzzzzz",
"uid": "aaaaWPXulqE4x6",
"scp": [
"apigw"
],
"auth_time": 1670286138,
"sub": "user1@abc.com",
"betatester": verdadeiro,
"domínio": "abc"
}
Para user2@abc.com
, que não foi escolhido para o programa beta, a reivindicação do betatester
é definida como
falso:
"sub": "user2@abc.com","betatester": falso,
Agora configuramos a política de roteamento de controle de acesso ( access-control-routing ) para conceder acesso ao serviço de preços para usuários cujo JWT contém a declaração betatester
com valor true
.
Por questões de brevidade, mostramos apenas a carga útil da política. Esta política funciona apenas com políticas baseadas em tokens no API Connectivity Manager, como JWT Assertion e OAuth2 Introspection.
"políticas": { "acesso-controle-roteamento": [
{
"ação": {
"condições": [
{
"allowAccess": {
"uri": "/pricing"
},
"quando": [
{
"chave": "token.betatester",
"matchOneOf": {
"valores": [
"verdadeiro"
]
}
}
]
}
],
"returnCode": 403
}
}
]
}
Depois que aplicamos a política, o proxy da API valida as declarações no JWT para usuários autenticados, executando um controle de acesso detalhado para rotear solicitações de user1@abc.com
e rejeitar solicitações de user2@abc.com
.
Podemos ajustar ainda mais a política de roteamento de controle de acesso para controlar quais usuários podem usar métodos HTTP específicos. Neste exemplo, o proxy da API permite que apenas administradores (usuários cujo token inclui o valor Admin
) usem o método DELETE
.
"políticas":{ "acesso-controle-roteamento":[
"ação":{
"condições":[
{
"quando":[
{
"chave":"token.{reivindicações}",
"matchOneOf":{
"valores":[
"Administrador"
]
}
}
],
"allowAccess":{
"uri":"/v1/cliente",
"httpMethods":[
"EXCLUIR"
]
},
"routeTo" : {
"targetBackendLabel" : ""
}
}
]
}
]
}
Outro uso da política de roteamento de controle de acesso é tomar decisões de roteamento com base em valores de cabeçalho em solicitações recebidas. Os proprietários da API podem configurar regras ou condições que especificam os valores no cabeçalho que devem ser correspondidos para que a solicitação seja roteada. As solicitações serão encaminhadas se contiverem o cabeçalho e descartadas se não contiverem.
Neste exemplo, uma solicitação é roteada para o endpoint /seasons somente quando o cabeçalho da solicitação de versão
tem o valor v1
. O valor returnCode
especifica o código de erro a ser retornado quando a versão
não for v1
– neste caso, é403
(Proibido)
.
"access-control-routing": [ {
"ação": {
"condições": [
{
"allowAccess": {
"uri": "/seasons"
},
"quando": [
{
"chave": "header.version",
"matchOneOf": {
"valores": [
"v1"
]
}
}
]
}
],
"returnCode": 403
}
}
]
Nesta solicitação curl
de exemplo, enviamos uma solicitação ao serviço seasons com o cabeçalho de versão
definido como v2
:
curl -H "versão: v2" http://example.com/seasons
Como o valor do cabeçalho da versão
não é v1,
conforme exigido pela política, o serviço retorna o código de status403
.
Você pode incluir várias regras em uma política de roteamento de controle de acesso para controlar o roteamento com base em um, dois ou todos os três critérios discutidos nesta postagem: Declarações JWT, métodos válidos e valores de cabeçalho de solicitação. Uma solicitação deve corresponder às condições de todas as regras para ser roteada; caso contrário, ela será bloqueada.
O API Connectivity Manager permite que os proprietários de API controlem e aprimorem a experiência de suas APIs e serviços com políticas em nível de API que aplicam controle de acesso detalhado e tomam decisões de roteamento dinâmicas.
Para começar a usar o API Connectivity Manager, solicite uma avaliação gratuita de 30 dias do NGINX Management Suite .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."