Autenticação SAML para OpenSearch painel - Amazon OpenSearch Service

Autenticação SAML para OpenSearch painel

A autenticação SAML para OpenSearch Dashboards permite que você use seu provedor de identidade existente para autenticação única (SSO) para Dashboards em domínios do Amazon OpenSearch Service que executam o OpenSearch ou o Elasticsearch 6.7 ou posterior. Para usar autenticação do SAML, é necessário habilitar o controle de acesso refinado.

Em vez de autenticar via Amazon Cognito ou banco de dados interno de usuários, a autenticação SAML para OpenSearch Dashboards permite que você use provedores de identidade de terceiros para fazer login no Dashboards, gerenciar o controle de acesso refinado, pesquisar seus dados e criar visualizações. O OpenSearch Service oferece suporte a provedores que usam o padrão SAML 2.0, como Okta, Keycloak, Serviços de Federação do Active Directory (ADFS) e Auth0.

nota

As solicitações do OpenSearch Service para provedores de terceiros não são explicitamente criptografadas com um certificado de provedor de serviços.

A autenticação SAML para Dashboards permite apenas acessar o OpenSearch Dashboards por meio de um navegador da Web. Suas credenciais SAML não permitem que você faça solicitações HTTP diretas para as APIs do OpenSearch ou Dashboards.

Visão geral da configuração do SAML

Esta documentação pressupõe que você tenha um provedor de identidade existente e alguma familiaridade com ele. Não podemos fornecer etapas detalhadas de configuração para o seu provedor exato, apenas para o domínio do OpenSearch Service.

O fluxo de login do Dashboards pode assumir uma de duas formas:

  • Provedor de serviço (SP) iniciado: você navega até Dashboards (por exemplo, https://my-domain.us-east-1.es.amazonaws.com/_dashboards), a qual redireciona você para a tela de login. Após você fazer login, o provedor de identidade redirecionará você para o Dashboards.

  • Provedor de identidades (IdP) iniciado: navegue até seu provedor de identidades, faça login e escolha OpenSearch Dashboards em um diretório de aplicações.

O OpenSearch Service fornece dois URLs de autenticação única, iniciados por SP e IdP, mas você só precisa daquele que corresponda ao fluxo de login do OpenSearch Dashboards desejado.

Independentemente do tipo de autenticação que você usa, o objetivo é fazer login utilizando seu provedor de identidades e receber uma declaração SAML que contém seu nome de usuário (obrigatório) e quaisquer funções de back-end (opcional, mas recomendado). Esta informação permite que o controle de acesso refinado atribua permissões a usuários do SAML. Em provedores de identidade externos, as funções de backend são normalmente chamadas de "funções" ou "grupos"

nota

Você não pode alterar o valor fornecido pelo serviço do URL de SSO. Portanto, a autenticação SAML para OpenSearch Dashboards não oferece suporte a servidores proxy.

Autenticação SAML para domínios em execução em uma VPC

O SAML não requer comunicação direta entre o seu provedor de identidade e seu provedor de serviços. Assim, mesmo que o seu domínio do OpenSearch esteja hospedado em uma VPC privada, você ainda poderá usar o SAML, desde que o seu navegador possa se comunicar com o cluster do OpenSearch e com o provedor de identidade. O seu navegador atua essencialmente como intermediário entre o seu provedor de identidade e seu provedor de serviços. Para um diagrama útil que explica o fluxo de autenticação SAML, consulte a Documentação do Okta.

Habilitação da autenticação SAML

Você só pode habilitar a autenticação SAML para o OpenSearch Dashboards em domínios existentes, e não durante a criação de novos domínios. Devido ao tamanho do arquivo de metadados IdP, é altamente recomendável usar o console da AWS.

Os domínios oferecem suporte a apenas um método de autenticação do Dashboards por vez. Se a opção Amazon Cognito authentication for OpenSearch Dashboards (Autenticação do Amazon Cognito para OpenSearch Dashboards) estiver habilitada, você deverá desabilitá-la antes de habilitar o SAML.

Habilite a autenticação iniciada por SP ou IdP

Estas etapas explicam como habilitar a autenticação SAML com autenticação iniciada por SP ou IdP para o OpenSearch Dashboards. Para visualizar a etapa extra necessária para habilitar ambos, consulte Habilite a autenticação iniciada tanto por SP quanto por IdP.

Para habilitar a autenticação SAML para Dashboards

  1. No console do OpenSearch Service, selecione o domínio e, em seguida, escolha Actions (Ações) e Edit security configuration (Editar configuração de segurança).

  2. Selecione Enable SAML authentication (Habilitar autenticação SAML).

  3. Anote o ID da entidade do provedor de serviços e os dois URLs de SSO. Você só precisará de um dos URLs de SSO. Para obter orientações, consulte Visão geral da configuração do SAML.

    dica

    Esses URLs serão alterados se você habilitar mais tarde um endpoint personalizado para o seu domínio. Nessa situação, você deverá atualizar seu IdP.

  4. Use esses valores para configurar seu provedor de identidade. Essa é a parte mais complexa do processo e, infelizmente, a terminologia e as etapas variam muito de acordo com o provedor. Consulte a documentação do seu provedor.

    No Okta, por exemplo, você deve criar uma "aplicação Web SAML 2.0". Para Single sign on URL (URL de acesso único), especifique o URL de SSO que você escolheu na Etapa 3. Para Audience URI (SP Entity ID) (URI do público (ID da entidade do SP)), especifique o ID da entidade do provedor de serviços.

    Em vez de usuários e funções de backend, o Okta tem usuários e grupos. Em Group Attribute Statements (Instruções de atributo de grupo), recomendamos adicionar role ao campo Name (Nome), e a expressão regular .+ ao campo Filter (Filtro). Esta instrução diz ao provedor de identidade do Okta para incluir todos os grupos de usuários sob o campo role da asserção SAML após a autenticação de um usuário.

    No Auth0, você cria uma "aplicação Web regular" e, em seguida, habilita o complemento SAML 2.0. No Keycloak, você cria um "cliente".

  5. Aopis você configurar o provedor de identidade, ele gera um arquivo de metadados IdP. Esse arquivo XML contém informações sobre o provedor, como um certificado TLS, endpoints de acesso único e o ID de entidade do provedor de identidade.

    Copie o conteúdo do arquivo de metadados IdP e cole-o no campo Metadata from IdP (Metadados do IdP) no console do OpenSearch Service. Alternativamente, escolha Import from XML file (Importar de arquivo XML) e faça upload do arquivo. O arquivo de metadados deve ser semelhante ao seguinte:

    <?xml version="1.0" encoding="UTF-8"?> <md:EntityDescriptor entityID="entity-id" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"> <md:IDPSSODescriptor WantAuthnRequestsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"> <md:KeyDescriptor use="signing"> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate>tls-certificate</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </md:KeyDescriptor> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat> <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="idp-sso-url"/> <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="idp-sso-url"/> </md:IDPSSODescriptor> </md:EntityDescriptor>
  6. Copie o valor da propriedade entityID do seu arquivo de metadados e cole-o no campo IdP entity ID (ID da entidade do IdP) no console do OpenSearch Service. Muitos provedores de identidade também exibem esse valor como parte de um resumo pós-configuração. Alguns provedores chamam isso de “emissor”.

  7. Forneça um nome de usuário primário do SAML e/ou uma função de backend primária do SAML. Esse nome de usuário e/ou função de backend recebe permissões completas para o cluster, equivalentes a um novo usuário primário, mas só pode usar essas permissões dentro do Dashboards.

    No Okta, por exemplo, você pode ter um usuário jdoe que pertence ao grupo admins. Se você adicionar jdoe ao nome de usuário primário do SAML, somente esse usuário receberá permissões completas. Se você adicionar admins ao campo SAML master backend role (Função de backend primária do SAML), qualquer usuário que pertença ao grupo admins receberá permissões completas.

    O conteúdo da asserção SAML deve corresponder exatamente às strings que você usa para o nome de usuário primário do SAML e/ou a função primária do SAML. Alguns provedores de identidade adicionam um prefixo antes de seus nomes de usuário, o que pode causar uma incompatibilidade difícil de diagnosticar. Na interface do usuário do provedor de identidade, talvez você veja jdoe, mas a asserção SAML poderá conter auth0|jdoe. Use sempre a string da asserção SAML.

    Muitos provedores de identidade permitem que você visualize uma declaração de exemplo durante o processo de configuração, e ferramentas como o SAML-tracer podem ajudar a examinar e solucionar problemas de conteúdo de asserções reais. As asserções são semelhantes a:

    <?xml version="1.0" encoding="UTF-8"?> <saml2:Assertion ID="id67229299299259351343340162" IssueInstant="2020-09-22T22:03:08.633Z" Version="2.0" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"> <saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">idp-issuer</saml2:Issuer> <saml2:Subject> <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml2:NameID> <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml2:SubjectConfirmationData NotOnOrAfter="2020-09-22T22:08:08.816Z" Recipient="domain-endpoint/_dashboards/_plugins/_security/saml/acs"/> </saml2:SubjectConfirmation> </saml2:Subject> <saml2:Conditions NotBefore="2020-09-22T21:58:08.816Z" NotOnOrAfter="2020-09-22T22:08:08.816Z"> <saml2:AudienceRestriction> <saml2:Audience>domain-endpoint</saml2:Audience> </saml2:AudienceRestriction> </saml2:Conditions> <saml2:AuthnStatement AuthnInstant="2020-09-22T19:54:37.274Z"> <saml2:AuthnContext> <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef> </saml2:AuthnContext> </saml2:AuthnStatement> <saml2:AttributeStatement> <saml2:Attribute Name="role" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified"> <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">GroupName Match Matches regex ".+" (case-sensitive) </saml2:AttributeValue> </saml2:Attribute> </saml2:AttributeStatement> </saml2:Assertion>
  8. (Opcional) Expanda Additional settings (Configurações adicionais).

  9. Deixe o campo Subject key (Chave de assunto) vazio para usar o elemento NameID da asserção SAML para o nome de usuário. Se sua asserção não usar este elemento padrão e, em vez disso, incluir o nome de usuário como um atributo personalizado, especifique esse atributo aqui.

    Se desejar usar funções de backend (recomendado), especifique um atributo da asserção no campo Role key (Chave de função), como role ou group. Esta é outra situação em que ferramentas como o SAML tracer podem ajudar.

  10. Por padrão, o OpenSearch Dashboards desconecta os usuários da conta após 24 horas. Você pode configurar esse valor para qualquer número entre 60 e 1.440 (24 horas) especificando a vida útil da sessão.

  11. Selecione Save changes. O domínio entra em um estado de processamento por aproximadamente um minuto, período durante o qual Dashboards não está disponível.

  12. Após o processamento do domínio terminar, abra o Dashboards.

    • Se você escolheu o URL iniciado pelo SP, navegue até domain-endpoint/_dashboards/.

    • Se você escolheu o URL iniciado pelo IsP, navegue até o diretório de aplicações do provedor de identidade.

    Em ambos os casos, faça login como usuário primário do SAML ou um usuário que pertence à função de backend primário do SAML. Para continuar o exemplo da etapa 7, faça login como jdoe ou como um membro do grupo admins.

  13. Depois que o Dashboards carregar, escolha Security (Segurança) e Roles (Funções).

  14. Escolha Map functions (Mapear funções) para permitir que outros usuários acessem o Dashboards.

    Por exemplo, você pode mapear o seu colega confiável jroe nas funções all_access e security_manager. Você também pode mapear a função de backend analysts nas funções readall e kibana_user.

    Se preferir usar a API em vez do Dashboards, consulte a seguinte solicitação de exemplo:

    PATCH _plugins/_security/api/rolesmapping [ { "op": "add", "path": "/security_manager", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/all_access", "value": { "users": ["master-user", "jdoe", "jroe"], "backend_roles": ["admins"] } }, { "op": "add", "path": "/readall", "value": { "backend_roles": ["analysts"] } }, { "op": "add", "path": "/kibana_user", "value": { "backend_roles": ["analysts"] } } ]

Habilite a autenticação iniciada tanto por SP quanto por IdP

Caso pretenda configurar a autenticação iniciada pelo SP e pelo IdP, você deverá fazê-lo via provedor de identidade. Por exemplo, no Okta, você pode executar as seguintes etapas:

  1. Em sua aplicação SAML, vá para General (Geral), SAML settings (Configurações SAML).

  2. Para o Single sign on URL (URL de autenticação única), forneça o URL de SSO iniciado por IdP. Por exemplo, https://search-domain-hash/_dashboards/_opendistro/_security/saml/idpinitiated.

  3. Habilite Allow this app to request other SSO URLs (Permitir que este aplicativo solicite outros URLs de SSO).

  4. Em Requestable SSO URLs (URLs de SSO que podem ser requeridas), adicione um ou mais URLs de SSO iniciados por SP. Por exemplo, https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs.

Habilite a autenticação SAML (AWS CLI)

O seguinte comando AWS CLI habilita a autenticação SAML para OpenSearch Dashboards em um domínio existente:

aws opensearch update-domain-config \ --domain-name my-domain \ --advanced-security-options '{"SAMLOptions":{"Enabled":true,"MasterUserName":"my-idp-user","MasterBackendRole":"my-idp-group-or-role","Idp":{"EntityId":"entity-id","MetadataContent":"metadata-content-with-quotes-escaped"},"RolesKey":"optional-roles-key","SessionTimeoutMinutes":180,"SubjectKey":"optional-subject-key"}}'

Você deve “escapar” todas as aspas e caracteres de nova linha no XML de metadados. Por exemplo, use <KeyDescriptor use=\"signing\">\n em vez de <KeyDescriptor use="signing"> e uma quebra de linha. Para obter informações detalhadas sobre como usar a AWS CLI, consulte a Referência de comandos da AWS CLI.

Habilite a autenticação SAML (API de configuração)

A seguinte solicitação para a API de configuração habilita a autenticação SAML para o OpenSearch Dashboards em um domínio existente:

POST https://es.us-east-1.amazonaws.com/2021-01-01/opensearch/domain/my-domain/config { "AdvancedSecurityOptions": { "SAMLOptions": { "Enabled": true, "MasterUserName": "my-idp-user", "MasterBackendRole": "my-idp-group-or-role", "Idp": { "EntityId": "entity-id", "MetadataContent": "metadata-content-with-quotes-escaped" }, "RolesKey": "optional-roles-key", "SessionTimeoutMinutes": 180, "SubjectKey": "optional-subject-key" } } }

Você deve “escapar” todas as aspas e caracteres de nova linha no XML de metadados. Por exemplo, use <KeyDescriptor use=\"signing\">\n em vez de <KeyDescriptor use="signing"> e uma quebra de linha. Para obter informações detalhadas sobre como usar a API de configuração, consulte Referência da API de configuração para o Amazon OpenSearch Service.

Solução de problemas de SAML

Erro Detalhes

Sua solicitação: “/algum/caminho” não é permitida.

Verifique se você forneceu o URL de SSO correto (etapa 3) ao seu provedor de identidade.

Please provide valid identity provider metadata document to enable SAML (Forneça um documento de metadados do provedor de identidades válido para habilitar o SAML).

O arquivo de metadados do IdP não atende ao padrão SAML 2.0. Verifique se há erros usando uma ferramenta de validação.

As opções de configuração do SAML não estão visíveis no console.

Atualize para o software de serviço mais recente.

SAML configuration error: Something went wrong while retrieving the SAML configuration, please check your settings (Erro de configuração do SAML: algo errado ocorreu ao tentar recuperar a configuração do SAML. Verifique suas configurações.).

Esse erro genérico pode ocorrer por vários motivos.

  • Verifique se você forneceu ao provedor de identidade o ID de entidade do provedor de serviços e o URL de SSO corretos.

  • Gere novamente o arquivo de metadados do IdP e verifique o ID de entidade do IdP. Adicione quaisquer metadados atualizados no console do AWS.

  • Verifique se a política de acesso do domínio permite o acesso ao OpenSearch Dashboards e a _plugins/_security/*. Em geral, recomendamos uma política de acesso aberto para domínios que usam controle de acesso refinado.

  • Consulte a documentação do provedor de identidade para obter as etapas de configuração do SAML.

Missing role: No roles available for this user, please contact your system administrator (Função ausente: nenhuma função disponível para este usuário, entre em contato com o administrador do sistema).

Você autenticou com êxito, mas o nome de usuário e quaisquer funções de backend da asserção SAML não são mapeados em nenhuma função e, portanto, não têm permissões. Esses mapeamentos diferenciam maiúsculas de minúsculas.

Verifique o conteúdo da sua asserção SAML usando uma ferramenta como o SAML-tracere seu mapeamento de função usando a seguinte chamada:

GET _plugins/_security/api/rolesmapping

Seu navegador redireciona continuamente ou recebe erros HTTP 500 ao tentar acessar o OpenSearch Dashboards.

Esses erros podem ocorrer se sua asserção SAML contiver um grande número de funções totalizando aproximadamente 1.500 caracteres. Por exemplo, se você passar 80 funções com tamanho médio de 20 caracteres, o limite de tamanho para cookies em seu navegador da Web poderá ser excedido.

Não é possível sair do ADFS.

O ADFS requer que todas as solicitações de logout sejam assinadas, algo a que o OpenSearch Service não oferece suporte. Remova <SingleLogoutService /> do arquivo de metadados de IdP para forçar o OpenSearch Service a usar seu próprio mecanismo de logout interno.

Desabilitação da autenticação SAML

Para desabilitar a autenticação SAML para o OpenSearch Dashboards (console)

  1. Escolha o domínio, Actions (Ações), e Edit security configuration (Editar configuração de segurança).

  2. Desmarque Enable SAML authentication (Habilitar autenticação SAML).

  3. Selecione Save changes.

  4. Após o processamento do domínio, verifique o mapeamento de função de controle de acesso refinado com a seguinte solicitação:

    GET _plugins/_security/api/rolesmapping

    Desabilitar a autenticação SAML para o Dashboards não remove os mapeamentos para o nome de usuário primário do SAML e/ou a função de backend primária do SAML. Se você quiser remover esses mapeamentos, faça login no Dashboards usando o banco de dados interno de usuários (se habilitado) ou use a API para removê-los:

    PUT _plugins/_security/api/rolesmapping/all_access { "users": [ "master-user" ] }