Autenticação SAML para painéis OpenSearch

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

Em vez de se autenticar por meio do Amazon Cognito ou do banco de dados interno de usuários, a autenticação SAML OpenSearch para painéis permite que você use provedores de identidade terceirizados para fazer login nos painéis, gerenciar o controle de acesso refinado, pesquisar seus dados e criar visualizações. OpenSearch O serviço oferece suporte a provedores que usam o padrão SAML 2.0, como Okta, Keycloak, Microsoft Entra ID, Active Directory Federation Services (ADFS), Auth0 e. Centro de Identidade do AWS IAM

A autenticação SAML para painéis serve apenas para acessar OpenSearch painéis por meio de um navegador da web. Suas credenciais SAML não permitem que você faça solicitações HTTP diretas para as APIs 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 de configuração detalhadas para seu provedor exato, somente para seu domínio OpenSearch de serviço.

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

OpenSearch O serviço fornece dois URLs de login único IdP-initiated, SP-initiated 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. Portanto, mesmo que seu OpenSearch domínio esteja hospedado em uma VPC privada, você ainda poderá usar o SAML, desde que seu navegador possa se comunicar com seu OpenSearch cluster e seu 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 somente a partir do 192.0.2. 0/24sub-rede:

Configurando SP- ou autenticação IdP-initiated

Essas etapas explicam como habilitar a autenticação SAML com SP-initiated ou a IdP-initiated autenticação para OpenSearch painéis. Para obter a etapa adicional necessária para habilitar ambos, consulte Configurando o SP e a IdP-initiated autenticação.

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 do 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 seu endpoint personalizado forwww.custom-endpoint.com, o ID da entidade do provedor de serviços seráwww.custom-endpoint.com, o URL do IdP-initiated SSO será www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated e o URL do SP-initiated SSO 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. Depois que o domínio estiver ativo, você poderá recuperar os valores corretos do OpenSearch Serviço 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 do IdP e cole-o no campo Metadados do IdP no console de serviço. OpenSearch 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 do IdP, configure os seguintes campos adicionais no OpenSearch console de serviço:

Muitos provedores de identidade permitem que você visualize um exemplo de declaração durante o processo de configuração, e ferramentas como essas SAML-tracerpodem ajudá-lo a examinar e solucionar problemas com o conteúdo de afirmaçõ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, você pode encontrar a 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 Ativo e seu IdP estiver configurado corretamente, navegue até OpenSearch Painéis.

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 os OpenSearch painéis forem carregados, escolha Segurança, Funções. Em seguida, mapeie as funções para permitir que outros usuários acessem os OpenSearch painéis.

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 você preferir usar a API em vez de OpenSearch painéis, veja o seguinte exemplo de solicitação:

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"] }
  }
]

Configurando o SP e IdP-initiated a autenticação

Se você quiser configurar tanto o SP quanto a IdP-initiated autenticação, deverá fazer isso por meio do seu provedor de identidade. Por exemplo, no Okta, você pode executar as seguintes etapas:

Configurando a autenticação SAML (AWS CLI)

O AWS CLI comando a seguir ativa a autenticação SAML para OpenSearch painéis 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 solicitação a seguir para a API de configuração permite a autenticação SAML para OpenSearch painéis 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 de OpenSearch serviço.

Solução de problemas de SAML

GET _plugins/_security/api/rolesmapping

Desabilitação da autenticação SAML