SAMLautenticação para OpenSearch painéis

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

Em vez de se autenticar por meio do Amazon Cognito ou do banco de dados interno de usuáriosSAML, a autenticação 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, Active Directory Federation Services (ADFS), Auth0 e AWS IAM Identity Center.

SAMLa autenticação para painéis serve apenas para acessar OpenSearch painéis por meio de um navegador da web. Suas SAML credenciais não permitem que você faça HTTP solicitações diretas aos painéis OpenSearch ou painéisAPIs.

SAMLvisão geral da configuração

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 logons únicosURLs, iniciados pelo SP e iniciados pelo IDP, mas você só precisa daquele que corresponda ao fluxo de login do Dashboards desejado. OpenSearch

Independentemente do tipo de autenticação que você usa, o objetivo é fazer login por meio do seu provedor de identidade e receber uma SAML declaração que contenha seu nome de usuário (obrigatório) e todas as funções de back-end (opcional, mas recomendado). Essas informações permitem um controle de acesso refinado para atribuir permissões aos usuários. 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 SAML autenticação:

SAMLautenticação para VPC domínios

SAMLnão exige comunicação direta entre seu provedor de identidade e seu provedor de serviços. Portanto, mesmo que seu OpenSearch domínio esteja hospedado em um ambiente privadoVPC, você ainda poderá usá-lo, 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 obter um diagrama útil que explica o fluxo de SAML autenticação, consulte a documentação do Okta.

Modificar a política de acesso ao domínio

Antes de configurar a SAML autenticação, você deve atualizar a política de acesso ao domínio para permitir que SAML os usuários 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:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "domain-arn/*"
    }
  ]
}

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

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "es:ESHttp*"
      ],
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "192.0.2.0/24"
          ]
        }
      },
      "Resource": "domain-arn/*"
    }
  ]
}

Configurar a autenticação iniciada por SP ou IdP

Essas etapas explicam como habilitar a SAML autenticação com autenticação iniciada por SP ou IdP para painéis. OpenSearch Para visualizar a etapa extra necessária para habilitar ambos, consulte Configurar a autenticação iniciada tanto por SP quanto por IdP.

Etapa 1: ativar a SAML autenticação

Você pode ativar a SAML autenticação 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 SAMLAutenticação para OpenSearch Dashboards/Kibana, selecione Habilitar autenticação. SAML

Etapa 2: Configurar seu provedor de identidade

Execute as etapas a seguir, dependendo de quando você estiver configurando a SAML autenticação.

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 SSOURLs. Seu provedor de identidade exige esses valores para habilitar adequadamente a SAML autenticação, mas eles só podem ser gerados após a 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 você estiver usando um endpoint personalizado, poderá inferir qual URLs será. 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 IdP SSO URL será www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated iniciado e o iniciado pelo SP SSO URL 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 https://temp-endpoint.amazonaws.com entrar nos campos Login único URL e Público URI (SP Entity ID), 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 obter instruções, consulte Etapa 6: atualize seu IdP URLs.

Se estiver editando um domínio existente

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

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ê cria um aplicativo web SAML 2.0. Para Login único URL, especifique SSO URL o. Para Audiência URI (ID da entidade SP), especifique a ID da entidade SP.

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. Essa declaração diz ao provedor de identidade Okta que inclua todos os grupos de usuários no role campo da SAML declaração após a autenticação do usuário.

No IAM Identity Center, você especifica o ID da entidade SP como o SAMLpúblico do aplicativo. 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 um aplicativo web normal e ativa 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 XML arquivo contém informações sobre o provedor, como um TLS certificado, endpoints de login único e o ID da 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 Como alternativa, escolha Importar do XML arquivo e faça o 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>

Etapa 4: configurar SAML campos

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 SAML-tracer podem 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: atualize seu IdP URLs

Se você ativou a SAML autenticação ao criar um domínio, precisará especificar o temporário URLs em seu IdP para gerar o arquivo de XML metadados. Depois que o status do domínio mudar paraActive, você poderá obter o IdP correto URLs e modificar seu IdP.

Para recuperar oURLs, selecione o domínio e escolha Ações, Editar configuração de segurança. Em SAMLautenticação para OpenSearch Dashboards/Kibana, você pode encontrar o ID correto da entidade do provedor de serviços e. SSO URLs Copie os valores e use-os para configurar seu provedor de identidade, substituindo o temporário URLs que você forneceu na etapa 2.

Etapa 7: mapear SAML usuários para funções

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 SAML principal ou como usuário que pertença à função SAML principal de back-end. 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 os painéis 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"] }
  }
]

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:

Configurando a SAML autenticação (AWS CLI)

Os seguintes exemplos de AWS CLI o comando permite a SAML autenticação 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 ignorar todas as aspas e caracteres de nova linha nos XML 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 o uso do AWS CLI, veja o AWS CLI Referência de comando.

Configurando a SAML autenticação (configuraçãoAPI)

A seguinte solicitação à configuração API permite a SAML autenticação 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 ignorar todas as aspas e caracteres de nova linha nos XML 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 configuraçãoAPI, consulte a APIreferência do OpenSearch serviço.

SAMLsolução de problemas

GET _plugins/_security/api/rolesmapping

Desativando a autenticação SAML