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 os painéis OpenSearch ou painéis. APIs

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 logons únicos URLs, 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 obter mais informações, consulte Criação de um endpoint personalizado para o Amazon Service OpenSearch .

• As Políticas de Controle de Serviços (SCP) não serão aplicáveis nem avaliadas no caso de identidades que não sejam do IAM (como SAML no OpenSearch Amazon Serverless e SAML e autorização básica de usuário interno para o Amazon Service). OpenSearch

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 obter 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 SSO URLs. 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 você estiver usando um endpoint personalizado, poderá inferir qual URLs será. 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.

nota

Você não pode entrar com um endpoint de pilha dupla porque o FQDN de uma solicitação HTTP é diferente do FQDN de uma solicitação SAML. Um OpenSearch administrador precisará configurar um endpoint personalizado e definir o valor CNAME como endpoint de pilha dupla se você quiser entrar usando um endpoint de pilha dupla.

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: atualize seu IdP URLs.

Se estiver editando um domínio existente

Se você 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 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:

• 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: atualize seu IdP URLs

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

Para recuperar o 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 o ID de entidade do provedor de serviços e o SSO corretos. 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 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:

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

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

3. Ative Permitir que este aplicativo solicite outro SSO URLs.

4. Em SSO solicitável URLs, adicione um ou mais SSO iniciados pelo SP. URLs 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: '/some/path' 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 suporta 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. OpenSearch URLs
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)

1. Escolha o domínio, Ações, e Editar configuração de segurança.

2. Desmarque Habilitar autenticação SAML.

3. Escolha Salvar alterações.

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