Visão geral da configuração do SAML Considerações Autenticação SAML para domínios de VPC Modificar a política de acesso ao domínio Configurar a autenticação iniciada por SP ou IdP Configurar a autenticação iniciada por SP ou IdP Configurar a autenticação SAML (AWS CLI)Configurar a autenticação SAML (API de configuração)Solução de problemas de SAML Desabilitação da autenticação SAML

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, Active Directory Federation Services (ADFS), Auth0 e. AWS IAM Identity Center

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:

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 identidade (IdP) iniciado: você navega até seu provedor de identidade, faz login e escolhe OpenSearch Painéis em um diretório de aplicativos.

OpenSearch O serviço fornece dois URLs de login único, 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 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:

Devido ao tamanho do arquivo de metadados IdP, é altamente recomendável usar o console da AWS para configurar a autenticação SAML.
Os domínios oferecem suporte a apenas um método de autenticação do Dashboards por vez. Se você tiver a autenticação do Amazon Cognito para OpenSearch painéis ativada, deverá desativá-la antes de habilitar a autenticação SAML.
Se você usa um network load balancer com SAML, primeiro deve criar um endpoint personalizado. Para ter mais informações, consulte Criação de um endpoint personalizado para o Amazon OpenSearch Service.

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:


{
  "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/*"
    }
  ]
}

nota

Uma política de acesso ao domínio aberto exige que um controle de acesso refinado seja ativado em seu domínio, caso contrário, você verá o seguinte erro:

To protect domains with public access, a restrictive policy or fine-grained access control is required.

Se você tiver um usuário principal ou interno configurado com uma senha robusta, manter a política aberta enquanto usa um controle de acesso refinado pode ser aceitável do ponto de vista da segurança. Para ter mais informações, consulte Controle de acesso refinado no Amazon Service OpenSearch .

Configurar a autenticação iniciada por SP ou IdP

Essas etapas explicam como habilitar a autenticação SAML 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: 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 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. 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: 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:name} e Role=${user:groups}.

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:

ID da entidade do IdP: copie o valor da propriedade entityID do seu arquivo de metadados e cole-o nesse campo. Muitos provedores de identidade também exibem esse valor como parte de um resumo pós-configuração. Alguns provedores chamam isso de “emissor”.
Nome de usuário principal do SAML e função de back-end principal do SAML — O usuário e/ou a função de back-end que você especifica recebe permissões completas para o cluster, equivalentes a um novo usuário mestre, mas só pode usar essas permissões nos painéis. OpenSearch

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 Perfil de backend primário SAML, qualquer usuário que pertença ao grupo admins receberá permissões completas.

nota
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 o perfil primário SAML. Alguns provedores de identidade adicionam um prefixo antes de seus nomes de usuário, o que pode causar uma hard-to-diagnose incompatibilidade. 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/_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:

Chave do requerente: você pode deixar esse campo vazio para usar o elemento NameID da asserção SAML como 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.
Chave de perfis: se quiser usar funções de backend (recomendadas), especifique um atributo da afirmação nesse campo, como role ou group. Esta é outra situação em que ferramentas como o SAML tracer podem ajudar.
Tempo de ativação da sessão — Por padrão, o OpenSearch Dashboards desconecta os usuários após 24 horas. Você pode configurar esse valor como qualquer número entre 60 e 1.440 (24 horas) especificando um novo valor.

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.

Se você escolheu o URL iniciado pelo SP, navegue até domain-endpoint/_dashboards. Para fazer login diretamente em um inquilino específico, você pode anexar ?security_tenant=tenant-name ao URL.
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.

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

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:

Em sua aplicação SAML, vá para Geral, Configurações SAML.
Para o URL de autenticação única, forneça o URL de SSO iniciado por IdP. Por exemplo, https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated.
Habilite Permitir que este aplicativo solicite outros URLs de SSO.
Em 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.

Configurar 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 o uso do AWS CLI, consulte a Referência de AWS CLI Comandos.

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

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.
`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.
`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 sua política de acesso ao domínio permite acesso aos OpenSearch painéis e. `_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.
`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. O administrador do sistema pode verificar o conteúdo da sua declaração de SAML usando uma ferramenta como o SAML-tracer e, em seguida, verificar seu mapeamento de funções usando a seguinte solicitação: `GET _plugins/_security/api/rolesmapping`
Seu navegador redireciona ou recebe continuamente erros HTTP 500 ao tentar acessar OpenSearch os painéis.	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. A partir da OpenSearch versão 2.7, a asserção SAML oferece suporte a funções de até 5.000 caracteres.
Não é possível sair do ADFS.	O ADFS exige que todas as solicitações de logout sejam assinadas, o que o OpenSearch Serviço não suporta. Remova `<SingleLogoutService />` do arquivo de metadados do IdP para forçar o OpenSearch Serviço a usar seu próprio mecanismo de logout interno.
`Could not find entity descriptor for __PATH__.`	O ID da entidade do IdP fornecido nos metadados XML to OpenSearch Service é diferente daquele na resposta SAML. Para corrigir isso, verifique se eles correspondem. Ative logs de erros do aplicativo CW no seu domínio para encontrar a mensagem de erro para depurar o problema de integração do SAML.
`Signature validation failed. SAML response rejected.`	OpenSearch O serviço não consegue verificar a assinatura na resposta SAML usando o certificado do IdP fornecido no XML de metadados. Você pode ter cometido um erro ou seu IdP alterou o certificado. Atualize o certificado mais recente do seu IdP no XML de metadados fornecido ao OpenSearch Serviço por meio do. AWS Management Console
`__PATH__ is not a valid audience for this response.`	O campo de público na resposta do SAML não corresponde ao endpoint do domínio. Para corrigir esse erro, atualize o campo “SP audience” para corresponder ao endpoint do seu domínio. Se você ativou endpoints personalizados, o campo de público deve corresponder ao seu endpoint personalizado. Ative logs de erros do aplicativo CW no seu domínio para encontrar a mensagem de erro para depurar o problema de integração do SAML.
Seu navegador recebe um erro HTTP 400 na resposta ao `Invalid Request Id`.	Esse erro geralmente ocorre se você configurou o URL iniciado pelo IdP com o formato `<DashboardsURL>/_opendistro/_security/saml/acs`. Em vez disso, configure o URL com o formato `<DashboardsURL>/_opendistro/_security/saml/acs/idpinitiated`.
A resposta foi recebida às `__PATH__` em vez de `__PATH__`.	O campo de destino na resposta do SAML não corresponde a um dos seguintes formatos de URL: `<DashboardsURL>/_opendistro/_security/saml/acs` `<DashboardsURL>/_opendistro/_security/saml/acs/idpinitiated`. Dependendo do fluxo de login que você usa (iniciado pelo SP ou iniciado pelo IDP), insira um campo de destino que corresponda a um dos URLs. OpenSearch
A resposta tem um `InResponseTo` atributo, enquanto `InResponseTo` não era esperado.	Você está usando o URL iniciado por IdP para um fluxo de login iniciado por SP. Em vez disso, use o URL iniciado por SP.

Desabilitação da autenticação SAML

Para desativar a autenticação SAML para OpenSearch painéis (console)

Escolha o domínio, Ações, e Editar configuração de segurança.
Desmarque Habilitar autenticação SAML.
Escolha Salvar alterações.
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"
  ]
}
```

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Trabalhando com OpenSearch VPC endpoints gerenciados por serviços

Autenticação do Amazon Cognito para OpenSearch Dashboards