Use identidades SAML para acesso programático ao Amazon OpenSearch Service

Use identidades SAML para acesso programático ao Amazon OpenSearch Service

Nó Fonte: 2088598

Clientes de Serviço Amazon OpenSearch já pode usar Linguagem de marcação de declaração de segurança (SAML) para Acesso Painéis OpenSearch.

Esta postagem descreve dois métodos pelos quais os usuários programáticos agora podem acessar o OpenSearch usando identidades SAML. Isso se aplica a todos os provedores de identidade (IdPs) que oferecem suporte a SAML 2.0, incluindo os predominantes, como Active Directory Federation Service (ADFS), Okta, Centro de identidade do AWS IAM (Sucessor do AWS Single Sign-On), KeyCloak e outros. Embora descrevamos os métodos no que se refere ao Serviço OpenSearch e Gerenciamento de acesso e identidade da AWS (IAM), o acesso programático a cada um desses provedores individuais está fora do escopo desta postagem. A maioria desses provedores fornecem tal facilidade.

Métodos de logon único

Quando você usa o logon único (SSO), há dois métodos de autenticação diferentes:

  • Provedor de identidade iniciado – É quando um usuário ou agente de usuário se autentica pela primeira vez com um IdP e obtém uma asserção SAML que estabelece a identidade do usuário. Essa asserção é então passada para um provedor de serviços (SP) que fornece acesso a um recurso protegido.
  • Provedor de serviços iniciado – Embora a troca iniciada pelo IdP seja direta, uma experiência de conexão mais típica é quando o recurso protegido é acessado diretamente. O SP redireciona o usuário ao IdP para autenticação junto com uma solicitação de autenticação SAML. O IdP responde com uma declaração de autenticação dentro de uma resposta SAML. Depois disso, a experiência de SSO é a mesma de um fluxo iniciado por IdP.

Para acesso programático ao OpenSearch Service, um IdP externo é o IdP, e o OpenSearch Service e o IAM servem como SPs. Para configurar seu IdP de escolha como SAML IdP para IAM, consulte Criando provedores de identidade IAM SAML. Para configurar o serviço OpenSearch, consulte Autenticação SAML para Painéis OpenSearch.

Nas seções a seguir, descrevemos dois métodos para acessar a API do serviço OpenSearch:

Método 1: Use o AWS STS

A figura a seguir mostra a sequência de chamadas para acessar a API do serviço OpenSearch usando o AWS STS.

Vamos explorar cada etapa com mais detalhes.

Passos 1 e 2

As etapas 1 e 2 variam dependendo do IdP escolhido. Em geral, eles normalmente fornecem uma API de autenticação ou API de sessão ou outra API semelhante para autenticar e recuperar a resposta de asserção de autenticação SAML. Usamos essa asserção SAML na próxima etapa.

Passos 3 e 4

Ligue para o AssumirRoleWithSAML API do AWS STS para trocar a declaração SAML por credenciais temporárias associadas à sua identidade SAML. Veja o seguinte código:

curl --location 'https://sts.amazonaws.com?
Version=2011-06-15&
Action=AssumeRoleWithSAML&
RoleArn=<ARN of the role being assumed>&
PrincipalArn=<ARN of the IdP integrated with IAM>&
SAMLAssertion=<Base-64 encoded SAML assertion>'

A resposta contém as credenciais temporárias do AWS STS com AccessKeyId, SecretAccessKeye um Token de Sessão.

Passo 5

Use as credenciais temporárias da última etapa para assinar todas as solicitações de API ao serviço OpenSearch. Assegure também o papel que assumiu junto ao AssumirRoleWithSAML call tem permissão suficiente para acessar os dados necessários no serviço OpenSearch. Referir-se Mapeamento de funções para usuários para obter mais informações sobre como mapear essa função como uma função de back-end. Como uma etapa adicional para garantir a consistência, esta função do AWS STS e qualquer grupo SAML do qual o usuário faz parte podem ser mapeados para a mesma função no OpenSearch Service. O código a seguir mostra um modelo para fazer essa chamada:

curl --location ‘<OpenSearch Service domain URL>/_search' --header 'X-Amz-Security-Token: Fwo...==(truncated)' --header 'X-Amz-Date: 20230327T134710Z' --header 'Authorization: AWS4-HMAC-SHA256 Credential=ASI..(truncated)/20230327/us-east-1/es/aws4_request, SignedHeaders=host;x-amz-date;x-amz-security-token, Signature=95eb…(truncated)'

Método 2: Use o proxy do console do OpenSearch Dashboards

O OpenSearch Dashboards tem um componente chamado proxy do console que podem fazer solicitações de proxy para o OpenSearch. Isso permite que os clientes OpenSearch façam as mesmas chamadas de API em Domain Specific Language (DSL) para este proxy de console, em vez de chamar diretamente o OpenSearch. O proxy do console encaminha essas chamadas para o OpenSearch e responde de volta aos clientes no mesmo formato do OpenSearch.

A figura a seguir mostra a sequência de chamadas que você pode fazer ao proxy do console para obter acesso programático ao OpenSearch Service.

Passos 1 e 2

As duas primeiras etapas são semelhantes ao método 1 e variam de acordo com o IdP escolhido. Essencialmente, você precisa obter uma resposta de asserção de autenticação SAML do IdP.

Passos 3 e 4

Use a asserção SAML das etapas anteriores e POSTE-a na URL do Assertion Consumer Service (ACS), _opendistro/_security/saml/acs/idpinitiated, para trocar a afirmação pela security_authentication símbolo. O código a seguir mostra a linha de comando para essas etapas:

curl --location ‘<dashboards URL>/_opendistro/_security/saml/acs/idpinitiated' --header 'content-type: application/x-www-form-urlencoded' --data-urlencode ‘SAMLResponse=Base-64 encoded SAML assertion' --data-urlencode 'RelayState=’

Se estiver usando o mecanismo OpenSearch, o URL do painel é <domain URL>/_dashboards. Se você estiver usando o mecanismo Elasticsearch, a URL do painel é <domain URL>/_plugin/kibana. O OpenSearch Dashboards processa isso e responde com uma resposta de redirecionamento com o código 302 e um corpo vazio. Os cabeçalhos de resposta agora também contêm um cookie chamado security_authentication, que é o token que você deve usar em todas as chamadas subsequentes.

Etapas 5–8

Use o security_authentication cookie nas chamadas de API para o proxy do console para executar chamadas de API programáticas. O código a seguir mostra uma linha de comando para essas etapas:

curl --location ‘<dashboardsURL>/api/console/proxy?path=_search&method=GET' --header 'content-type: application/json' --header 'cookie: security_authentication=Fe26.2**1...(truncated)' --header 'osd-xsrf: true' --data '{ "query": { "match_all": {} }
}’

Certifique-se de incluir um cabeçalho chamado osd-xsrf : true para acesso programático a painéis. O caminho do proxy do console é /api/console/proxy para Elasticsearch engines versão 6.xe 7.xe OpenSearch engine versão 1.xe 2.x.

Semelhante ao método 1, certifique-se de mapear funções e grupos associados a uma identidade SAML específica como a função de back-end correta com as permissões necessárias.

Comparando esses métodos

Você pode usar o método 1 em qualquer domínio, independentemente do mecanismo, desde que o controle de acesso refinado esteja habilitado. O método 2 funciona apenas para domínios com versões do mecanismo Elasticsearch superiores a 6.7 e todas as versões do mecanismo OpenSearch.

O processo OpenSearch Dashboards geralmente é destinado a interações humanas, que têm uma taxa e volume de chamadas de API mais baixos do que as chamadas programáticas. O OpenSearch pode lidar com taxas e volumes de chamadas de API consideravelmente mais altos, portanto, tome cuidado para não enviar chamadas de API de alto volume usando o método 2. Como prática recomendada para acesso programático com identidades SAML, recomendamos o método 1 sempre que possível para evitar gargalos de desempenho.

Conclusão

Ambos os métodos descritos nesta postagem fornecem um fluxo semelhante para acessar o serviço OpenSearch programaticamente usando identidades SAML (trocando uma declaração SAML por um token de autenticação). AssumeRoleWithSAML é uma API chave e bastante simples de usar que permite esse acesso e é nosso método recomendado. Tente um de Laboratórios do serviço OpenSearch e inicie um domínio do OpenSearch Service para experimentar esses métodos. Boa sorte!


Sobre o autor

Muthu Pitchaimani é um especialista em pesquisa do Amazon OpenSearch Service. Ele cria aplicativos e soluções de pesquisa em larga escala. Muthu está interessado nos tópicos de rede e segurança e mora em Austin, Texas.

Carimbo de hora:

Mais de Grandes dados da AWS