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), Auth0 e AWS IAM Identity Center.

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 Opensearch Dashboards pode assumir uma de duas formas:

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 utilizado, o objetivo é fazer login por meio do provedor de identidade e receber uma declaração SAML que contenha seu nome de usuário (obrigatório) e quaisquer funções de backend (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"

Considerações

Considere o seguinte ao configurar a autenticação SAML:

Autenticação SAML para domínios de 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.

Modificar a política de acesso ao domínio

Antes de configurar a autenticação SAML, é necessário atualizar a política de acesso ao domínio para permitir que os usuários de SAML acessem o domínio. Caso contrário, haverá erros de acesso negado.

Recomendamos a seguinte política de acesso ao domínio, que fornece acesso total aos sub-recursos (/*) no domínio:

Para tornar a política mais restritiva, você pode adicionar a ela uma condição de endereço IP. Essa condição limita o acesso somente ao intervalo de endereços IP ou à sub-rede especificada. Por exemplo, a política a seguir permite acesso apenas da sub-rede 192.0.2.0/24:

Configurar 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 Configurar a autenticação iniciada tanto por SP quanto por IdP.

Etapa 1: Habilitar a autenticação SAML

É possível habilitar a autenticação SAML durante a criação do domínio ou escolhendo Ações, Editar configuração de segurança em um domínio existente. As etapas a seguir variam um pouco, dependendo de qual delas você escolher.

Na configuração do domínio, em Autenticação SAML para OpenSearch Dashboards/Kibana, selecione Habilitar autenticação SAML.

Etapa 2: Configurar seu provedor de identidade

Conclua as etapas a seguir, dependendo de quando você está configurando a autenticação SAML.

Se estiver criando um novo domínio

Se você estiver criando um novo domínio, o OpenSearch Service ainda não poderá gerar um ID de entidade de provedor de serviços ou URLs de SSO. Seu provedor de identidade requer esses valores para habilitar adequadamente a autenticação SAML, mas eles apenas podem ser gerados depois da criação do domínio. Para solucionar essa interdependência durante a criação do domínio, forneça valores temporários na sua configuração de IdP para gerar os metadados necessários e depois atualizá-los quando o domínio estiver ativo.

Se estiver usando um endpoint personalizado, você poderá inferir quais serão os URLs. Por exemplo, se o endpoint personalizado for www.custom-endpoint.com, o ID de entidade do provedor de serviços será www.custom-endpoint.com, o URL de SSO iniciado pelo IdP será www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated e o URL de SSO iniciado pelo SP será www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs. É possível usar os valores para configurar seu provedor de identidade antes de criar o domínio. Consulte a próxima seção para ver exemplos.

Se você não estiver usando um endpoint personalizado, poderá inserir valores temporários no seu IdP para gerar os metadados necessários e atualizá-los posteriormente quando o domínio estiver ativo.

Por exemplo, no Okta, você pode inserir https://temp-endpoint.amazonaws.com nos campos URL de login único e URI do público - ID da entidade SP, o que permite gerar os metadados. Quando o domínio estiver ativo, você poderá recuperar os valores corretos do OpenSearch Service e atualizá-los no Okta. Para instruções, consulte Etapa 6: Atualizar seus URLs de IdP.

Se estiver editando um domínio existente

Se estiver habilitando a autenticação SAML em um domínio existente, copie o ID da entidade do provedor de serviços e um dos URLs de SSO. Para orientação sobre qual URL usar, consulte Visão geral da configuração do SAML.

Use os 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 URL de acesso único, especifique o URL de SSO. Para 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 Instruções de atributo de grupo, recomendamos adicionar role ao campo Nome e a expressão regular .+ ao campo 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 IAM Identity Center, você especifica o ID da entidade SP como o público do Application SAML. Você também precisa especificar o mapeamento dos seguintes atributos: Subject=${user:subject}:format=unspecified e Role=${user:groups}:format=uri.

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

Etapa 3: Importar metadados do IdP

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 Metadados do IdP no console do OpenSearch Service. Alternativamente, escolha Importar de arquivo XML e carregue o 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>

Etapa 4: Configurar campos SAML

Depois de inserir seus metadados de IdP, configure os seguintes campos adicionais no console do OpenSearch Service:

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/_opendistro/_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>

Etapa 5: (Opcional) Configurar definições adicionais

Em Configurações adicionais, defina os seguintes campos opcionais:

Quando estiver satisfeito com sua configuração, salve o domínio.

Etapa 6: Atualizar seus URLs de IdP

Se tiver habilitado a autenticação SAML ao criar um domínio, você precisará especificar URLs temporários no seu IdP para gerar o arquivo de metadados XML. Quando o status do domínio for alterado para Active, você poderá obter os URLs corretos e modificar seu IdP.

Para recuperar os URLs, selecione o domínio e escolha Ações, Editar configuração de segurança. Em Autenticação SAML para OpenSearch Dashboards/Kibana, é possível encontrar o ID da entidade do provedor de serviços e os URLs de SSO corretos. Copie esses valores e use-os para configurar seu provedor de identidade, substituindo os URLs temporários fornecidos na etapa 2.

Etapa 7: mapear usuários SAML para perfis

Quando o status do seu domínio estiver Active (Ativo) e seu IdP estiver configurado corretamente, navegue até o OpenSearch Dashboards.

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.

Depois que o OpenSearch Dashboards for carregado, escolha Segurança, Funções. Em seguida, mapeie perfis para permitir que outros usuários acessem o OpenSearch 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 opensearch_dashboards_user.

Se preferir usar a API em vez do OpenSearch 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": "/opensearch_dashboards_user", "value": { "backend_roles": ["analysts"] }
  }
]

Configurar a autenticação iniciada por SP ou 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:

Configurar 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.

Configurar 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 a Referência da API do OpenSearch Service.

Solução de problemas de SAML

GET _plugins/_security/api/rolesmapping

Desabilitação da autenticação SAML