Autenticazione SAML per dashboard OpenSearch

L'autenticazione SAML per OpenSearch Dashboards ti consente di utilizzare il tuo provider di identità esistente per offrire Single Sign-On (SSO) per le dashboard sui domini Amazon OpenSearch Service in esecuzione OpenSearch o Elasticsearch 6.7 o versioni successive. Per utilizzare l'autenticazione SAML, è necessario abilitare il controllo granulare degli accessi.

Anziché eseguire l'autenticazione tramite Amazon Cognito o il database utente interno, l'autenticazione SAML per OpenSearch Dashboards ti consente di utilizzare provider di identità di terze parti per accedere alle dashboard, gestire un controllo degli accessi granulare, cercare nei dati e creare visualizzazioni. OpenSearchIl servizio supporta i provider che utilizzano lo standard SAML 2.0, come Okta, Keycloak, Active Directory Federation Services (ADFS), Auth0 e. AWS IAM Identity Center (successor to AWS Single Sign-On)

L'autenticazione SAML per le dashboard consente solo di accedere ai OpenSearch dashboard tramite un browser Web. Le tue credenziali SAML non ti consentono di effettuare richieste HTTP dirette alle API OpenSearch o alle Dashboard.

Panoramica della configurazione SAML

Questa documentazione presuppone che si disponga di un fornitore di identità esistente e che si abbia una certa familiarità con esso. Non possiamo fornire passaggi di configurazione dettagliati per il tuo provider esatto, solo per il tuo dominio OpenSearch di servizio.

Il flusso di accesso OpenSearch alle dashboard può assumere una delle due forme seguenti:

• Avviato da provider di servizi (SP): si passa a Dashboards (ad esempio https://my-domain.us-east-1.es.amazonaws.com/_dashboards), che reindirizza alla schermata di accesso. Dopo aver effettuato l'accesso, il provider di identità reindirizza l'utente da Dashboards.

• Avvio del provider di identità (IdP): accedi al tuo provider di identità, accedi e scegli OpenSearch Dashboard da una directory dell'applicazione.

OpenSearchIl servizio fornisce due URL Single Sign-on, avviati da SP e da IDP, ma è necessario solo quello che corrisponde al flusso di accesso desiderato alle Dashboard. OpenSearch

Indipendentemente dal tipo di autenticazione utilizzato, l'obiettivo è quello di accedere tramite il provider di identità e ricevere un'asserzione SAML contenente il nome utente (obbligatorio) e qualsiasi ruolo di back-end (facoltativo, ma consigliato). Queste informazioni consentono il controllo granulare degli accessi per assegnare le autorizzazioni agli utenti SAML. Nei provider di identità esterni, i ruoli back-end sono in genere denominati "ruoli" o "gruppi".

Considerazioni

Durante la configurazione dell'autenticazione SAML tieni presente quanto segue:

• Non è possibile modificare l'URL SSO dal valore fornito dal servizio, pertanto l'autenticazione SAML non supporta i server proxy.

• A causa delle dimensioni del file di metadati IdP, per configurare l'autenticazione SAML si consiglia vivamente di utilizzare la console AWS.

• I domini supportano solo un metodo di autenticazione Dashboards alla volta. Se hai abilitato l'autenticazione Amazon Cognito per OpenSearch le dashboard, devi disattivarla prima di poter abilitare l'autenticazione SAML.

• Se utilizzi un sistema di bilanciamento del carico di rete con SAML, devi prima creare un endpoint personalizzato. Per ulteriori informazioni, consulta Creazione di un endpoint personalizzato per il servizio OpenSearch di Amazon.

Autenticazione SAML per domini VPC

SAML non richiede una comunicazione diretta tra il fornitore di identità e il provider di servizi. Pertanto, anche se il tuo OpenSearch dominio è ospitato in un VPC privato, puoi comunque utilizzare SAML purché il tuo browser sia in grado di comunicare sia con il tuo OpenSearch cluster che con il tuo provider di identità. Il browser agisce essenzialmente come intermediario tra il provider di identità e il provider di servizi. Per un diagramma utile che spiega il flusso di autenticazione SAML, consulta la Documentazione Okta.

Modifica della policy di accesso al dominio

Prima di configurare l'autenticazione SAML è necessario aggiornare la policy di accesso al dominio per consentire agli utenti SAML di accedervi. Altrimenti, saranno restituiti errori di accesso negato.

Consigliamo la seguente policy di accesso al dominio, che fornisce l'accesso completo alle risorse secondarie (/*) del dominio:

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

Configurazione dell'autenticazione avviata da SP o da IdP

Questi passaggi spiegano come abilitare l'autenticazione SAML con l'autenticazione avviata da SP o da IDP per le dashboard. OpenSearch Per il passaggio aggiuntivo richiesto per abilitare entrambi, consulta Configurazione dell'autenticazione avviata da SP e avviata da IdP.

Fase 1: Abilitazione dell'autenticazione SAML

Puoi abilitare l'autenticazione SAML durante la creazione del dominio o scegliendo Actions (Operazioni), Edit security configuration (Modifica configurazione di sicurezza) su un dominio esistente. I seguenti passaggi variano leggermente a seconda della scelta effettuata.

All'interno della configurazione del dominio, in Autenticazione SAML per OpenSearch Dashboard/Kibana, seleziona Abilita l'autenticazione SAML.

Fase 2: Configurazione del fornitore di identità

Esegui i seguenti passaggi a seconda di quando viene configurata l'autenticazione SAML.

Se stai creando un nuovo dominio

Se stai creando un nuovo dominio, OpenSearch Service non può ancora generare un ID di entità del fornitore di servizi o gli URL SSO. Il tuo fornitore di identità richiede questi valori per abilitare correttamente l'autenticazione SAML, ma possono essere generati solo dopo la creazione del dominio. Per ovviare a questa interdipendenza durante la creazione del dominio, puoi fornire valori temporanei nella configurazione dell'IdP per generare i metadati richiesti e quindi aggiornarli una volta che il dominio è attivo.

Se utilizzi un endpoint personalizzato, puoi dedurre quali saranno gli URL. Ad esempio, se l'endpoint personalizzato è www.custom-endpoint.com, l'ID dell'entità del fornitore di servizi sarà www.custom-endpoint.com, l'URL SSO avviato dall'IDP sarà www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated e l'URL SSO avviato da SP sarà www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs. Puoi utilizzare i valori per configurare il tuo fornitore di identità prima della creazione del dominio. Per gli esempi consultare la prossima sezione.

Se non utilizzi un endpoint personalizzato, puoi inserire valori temporanei nel tuo IdP per generare i metadati richiesti e quindi aggiornarli in un secondo momento dopo l'attivazione del dominio.

Ad esempio, all'interno di Okta, puoi inserire https://temp-endpoint.amazonaws.com nei campi Single sign on URL (URL Single Sign On) e Audience URI (SP Entity ID) (URI del pubblico [ID entità SP]), che consentono di generare i metadati. Quindi, dopo che il dominio è attivo, puoi recuperare i valori corretti da OpenSearch Service e aggiornarli in Okta. Per istruzioni, consulta Fase 6: Aggiornamento degli URL dell'IdP.

Se stai modificando un dominio esistente

Se stai abilitando l'autenticazione SAML su un dominio esistente, copia l'ID dell'entità del fornitore di servizi e uno degli URL SSO. Per indicazioni sull'URL da utilizzare, consulta Panoramica della configurazione SAML.

Utilizzare questi valori per configurare il fornitore di identità. Questa è la parte più complessa del processo e, sfortunatamente, la terminologia e i passaggi variano notevolmente a seconda del provider. Consultare la documentazione del provider.

In Okta, ad esempio, crei un'applicazione web SAML 2.0. Per Single sign on URL (URL Single Sign-On), specifica l'URL SSO. Per URI di destinazione (ID entità SP), specificare l'ID entità SP.

Piuttosto che utenti e ruoli di back-end, Okta utilizza utenti e gruppi. Per Group Attribute Statements (Istruzioni degli attributi di gruppo), consigliamo di aggiungere role al campo Name (Nome) e l'espressione regolare .+ al campo Filter (Filtro). Questa istruzione indica al provider di identità Okta di includere tutti i gruppi di utenti sotto il campo role dell'asserzione SAML dopo l'autenticazione di un utente.

In IAM Identity Center, specifichi l'ID dell'entità SP come pubblico SAML dell'applicazione. È inoltre necessario specificare le seguenti mappature degli attributi: e. Subject=${user:name} Role=${user:groups}

In Auth0, crei una normale applicazione web e abiliti il componente aggiuntivo SAML 2.0. In Keycloak, crei un client.

Fase 3: Importazione dei metadati dell'IdP

Dopo aver configurato il provider di identità, viene generato un file di metadati IdP. Questo file XML contiene informazioni sul provider, ad esempio un certificato TLS, endpoint Single Sign-On e l'ID entità del provider di identità.

Copia il contenuto del file di metadati IdP e incollalo nel campo Metadati da IdP nella Console di servizio. OpenSearch In alternativa, scegliere Importa da file XML e caricare il file. Il file dei metadati dovrebbe avere un aspetto simile al seguente:

<?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>

Fase 4: Configurazione dei campi SAML

Dopo aver inserito i metadati IdP, configura i seguenti campi aggiuntivi nella OpenSearch console di servizio:

• IdP entity ID (ID entità IdP): copiare il valore della proprietà entityID dal file di metadati e incollarlo in questo campo. Molti provider di identità visualizzano questo valore anche come parte di un riepilogo successivo alla configurazione. Alcuni fornitori lo chiamano "emittente".

• Nome utente master SAML e ruolo backend principale SAML: l'utente e/o il ruolo backend specificato ricevono le autorizzazioni complete per il cluster, equivalenti a un nuovo utente master, ma possono utilizzare tali autorizzazioni solo all'interno delle dashboard. OpenSearch

  Ad esempio, in Okta è possibile avere un utente jdoe che appartiene al gruppo admins. Se si aggiunge jdoe al campo Nome utente master SAML, solo quell'utente riceverà le autorizzazioni complete. Se si aggiunge admins al campo SAML master backend role (Ruolo back-end master SAML), qualsiasi utente che appartiene al gruppo admins riceverà le autorizzazioni complete.

  Nota

  Il contenuto dell'asserzione SAML deve corrispondere esattamente alle stringhe utilizzate per il nome utente master SAML e/o il ruolo di master SAML. Alcuni provider di identità aggiungono un prefisso prima dei nomi utente, il che può causare una hard-to-diagnose mancata corrispondenza. Nell'interfaccia utente del provider di identità, è possibile che venga visualizzato jdoe, ma l'asserzione SAML potrebbe contenere auth0|jdoe. Utilizzare sempre la stringa dall'asserzione SAML.

Molti provider di identità consentono di visualizzare un'asserzione di esempio durante il processo di configurazione e strumenti come Tracer SAML possono aiutare a esaminare e risolvere i problemi del contenuto di asserzioni reali. Le asserzioni hanno il seguente aspetto:

<?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>

Fase 5: (facoltativo) configurazione delle impostazioni aggiuntive

In Additional settings (Impostazioni aggiuntive), configura i seguenti campi facoltativi:

• Subject key (Chiave oggetto): è possibile lasciare questo campo vuoto in modo da utilizzare l'elemento NameID dell'asserzione SAML per il nome utente. Se l'asserzione non utilizza questo elemento standard e include invece il nome utente come attributo personalizzato, specificare tale attributo qui.

• Roles key )Chiave ruoli): Se si desidera utilizzare i ruoli back-end (scelta consigliata), specificare un attributo dall'asserzione in questo campo, ad esempio role o group. Questa è un'altra situazione in cui strumenti come i tracer SAML possono aiutare.

• Durata della sessione: per impostazione predefinita, OpenSearch Dashboards disconnette gli utenti dopo 24 ore. È possibile configurare questo valore su qualsiasi numero compreso tra 60 e 1.440 (24 ore) specificando un nuovo valore.

Se la configurazione ti soddisfa, salva il dominio.

Fase 6: Aggiornamento degli URL dell'IdP

Se hai abilitato l'autenticazione SAML durante la creazione di un dominio, hai specificato URL temporanei all'interno dell'IdP per generare il file di metadati XML. Dopo il passaggio del dominio allo stato Active, potrai ottenere gli URL corretti e modificare l'IdP.

Per richiamare gli URL, seleziona il dominio e scegli Actions (Operazioni) quindi Edit security configuration (Modifica configurazione di sicurezza). Nella sezione Autenticazione SAML per OpenSearch Dashboard/Kibana, puoi trovare l'ID dell'entità del fornitore di servizi e gli URL SSO corretti. Copia i valori e usali per configurare il tuo fornitore di identità, sostituendo gli URL temporanei che hai fornito nella fase 2.

Fase 7: Associazione degli utenti SAML ai ruoli

Una volta che lo stato del dominio è attivo e il tuo IdP è configurato correttamente, vai OpenSearch su Dashboard.

• Se è stato scelto l'URL avviato da SP, passare a domain-endpoint/_dashboards. Per accedere direttamente a un tenant specifico, aggiungere ?security_tenant=tenant-name all'URL.

• Se è stato scelto l'URL avviato dall'IdP, passare alla directory dell'applicazione del provider di identità.

In entrambi i casi, accedere come utente principale SAML o come utente appartenente al ruolo back-end principale SAML. Per continuare l'esempio dalla fase 7, accedere come jdoe o come membro del gruppo admins.

Dopo il caricamento OpenSearch delle dashboard, scegli Sicurezza, Ruoli. Quindi, mappa i ruoli per consentire ad altri utenti di accedere alle OpenSearch dashboard.

Ad esempio, è possibile mappare il collega fidato jroe ai ruoli all_access e security_manager. È inoltre possibile mappare il ruolo back-end analysts ai ruoli readall e kibana_user.

Se preferisci utilizzare l'API anziché le OpenSearch dashboard, consulta la seguente richiesta di esempio:

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": "/dashboards_user", "value": { "backend_roles": ["analysts"] }
  }
]

Configurazione dell'autenticazione avviata da SP e avviata da IdP

Se si desidera configurare sia l'autenticazione avviata da SP che quella avviata da IdP, è necessario farlo tramite il provider di identità. Ad esempio, in Okta, puoi eseguire le operazioni seguenti:

1. All'interno dell'applicazione SAML, vai su General (Generale), SAML settings (Impostazioni SAML).

2. Per Single sign on URL (URL Single Sign On), fornisci l'URL SSO avviato da IdP. Ad esempio, https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs/idpinitiated.

3. Abilita Allow this app to request other SSO URLs (Consenti a questa app di richiedere altri URL SSO).

4. In Requestable SSO URLs (URL SSO richiedibili), aggiungi uno o più URL SSO avviati da SP. Ad esempio, https://search-domain-hash/_dashboards/_opendistro/_security/saml/acs.

Configurazione dell'autenticazione SAML (AWS CLI)

Il AWS CLI comando seguente abilita l'autenticazione SAML per le OpenSearch dashboard su un dominio esistente:

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

È necessario eseguire l'escape di tutte le virgolette e i caratteri newline nel file XML dei metadati. Ad esempio, utilizzare <KeyDescriptor use=\"signing\">\n invece di <KeyDescriptor use="signing"> e un'interruzione di riga. Per informazioni dettagliate sull'utilizzo della AWS CLI, consultare Riferimento ai comandi AWS CLI.

Configurazione dell'autenticazione SAML (API di configurazione)

La seguente richiesta all'API di configurazione abilita l'autenticazione SAML per le OpenSearch dashboard su un dominio esistente:

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

È necessario eseguire l'escape di tutte le virgolette e i caratteri newline nel file XML dei metadati. Ad esempio, utilizzare <KeyDescriptor use=\"signing\">\n invece di <KeyDescriptor use="signing"> e un'interruzione di riga. Per informazioni dettagliate sull'utilizzo dell'API di configurazione, consulta il riferimento API del OpenSearch servizio.

Risoluzione dei problemi SAML

Errore	Informazioni
La richiesta: '/some/path' non è consentita.	Verificare di aver fornito al provider di identità l'URL SSO corretto (fase 3).
Fornisci un documento valido per i metadati del provider di identità per abilitare SAML.	Il file di metadati IdP non è conforme allo standard SAML 2.0. Verificare la presenza di errori utilizzando uno strumento di convalida.
Le opzioni di configurazione SAML non sono visibili nella console.	Effettuare l'aggiornamento alla versione più recente del software di assistenza.
Errore di configurazione SAML: si è verificato un errore durante il recupero della configurazione SAML, controlla le impostazioni.	Questo errore generico può verificarsi per molti motivi. Verificare di aver fornito al provider di identità l'ID entità SP e l'URL SSO corretti. Rigenerare il file di metadati IdP e verificare l'ID entità IdP. Aggiungere tutti i metadati aggiornati nella console AWS. Verifica che la tua politica di accesso al dominio consenta l'accesso a OpenSearch Dashboard e_plugins/_security/*. In generale, per domini che utilizzano un controllo granulare degli accessi è preferibile utilizzare una policy di accesso aperta. Consultare la documentazione del provider di identità per le istruzioni sulla configurazione di SAML.
Ruolo mancante: nessun ruolo disponibile per questo utente, contatta l'amministratore di sistema.	L'autenticazione è stata eseguita correttamente, ma il nome utente e gli eventuali ruoli back-end dell'asserzione SAML non sono mappati ad alcun ruolo e quindi non dispongono di autorizzazioni. Queste mappature distinguono tra maiuscole e minuscole. Verificare il contenuto dell'asserzione SAML utilizzando uno strumento come Tracer SAML e la mappatura dei ruoli utilizzando la seguente chiamata: GET _plugins/_security/api/rolesmapping
Il tuo browser reindirizza o riceve continuamente errori HTTP 500 quando tenta di accedere OpenSearch alle dashboard.	Questi errori possono verificarsi se l'asserzione SAML contiene un numero elevato di ruoli per un totale di circa 1.500 caratteri. Ad esempio, se si superano 80 ruoli, la cui lunghezza media è di 20 caratteri, è possibile che il limite di dimensione per i cookie nel browser Web venga superato. A partire dalla OpenSearch versione 2.7, l'asserzione SAML supporta ruoli fino a 5000 caratteri.
Non è possibile disconnettersi da ADFS.	ADFS richiede la firma di tutte le richieste di disconnessione, cosa che il OpenSearch servizio non supporta. Rimuovi <SingleLogoutService /> dal file di metadati IdP per forzare il OpenSearch servizio a utilizzare il proprio meccanismo di disconnessione interno.
Could not find entity descriptor for __PATH__.	L'ID di entità dell'IdP fornito nei metadati XML to OpenSearch Service è diverso da quello nella risposta SAML. Per risolvere il problema, assicurati che corrispondano. Abilita i log degli errori delle applicazioni CW sul tuo dominio per trovare il messaggio di errore per il debug del problema di integrazione SAML.
Signature validation failed. SAML response rejected.	OpenSearchIl servizio non è in grado di verificare la firma nella risposta SAML utilizzando il certificato dell'IdP fornito nei metadati XML. Questo potrebbe essere un errore manuale o il tuo IdP ha ruotato il certificato. Aggiorna il certificato più recente del tuo IdP nei metadati XML forniti al OpenSearch Servizio tramite. AWS Management Console
__PATH__ is not a valid audience for this response.	Il campo audience nella risposta SAML non corrisponde all'endpoint del dominio. Per correggere questo errore, aggiorna il campo pubblico SP in modo che corrisponda all'endpoint del tuo dominio. Se hai abilitato gli endpoint personalizzati, il campo audience deve corrispondere al tuo endpoint personalizzato. Abilita i log degli errori delle applicazioni CW sul tuo dominio per trovare il messaggio di errore per il debug del problema di integrazione SAML.
Il tuo browser riceve un errore HTTP 400 Invalid Request Id nella risposta.	Questo errore si verifica in genere se hai configurato l'URL avviato da IDP con il formato. <Kibana/OSDURL>/_opendistro/_security/saml/acs Configura invece l'URL con il formato<Kibana/OSDURL>/_opendistro/_security/saml/acs/idpinitiated.
La risposta è stata ricevuta al __PATH__ posto di__PATH__.	Il campo di destinazione nella risposta SAML non corrisponde a uno dei seguenti formati URL: <Kibana/OSDURL>/_opendistro/_security/saml/acs <Kibana/OSDURL>/_opendistro/_security/saml/acs/idpinitiated. A seconda del flusso di accesso utilizzato (avviato da SP o avviato da IDP), inserisci un campo di destinazione che corrisponda a uno degli URL. OpenSearch
La risposta ha un InResponseTo attributo, mentre non InResponseTo era previsto.	Stai utilizzando l'URL avviato da IDP per un flusso di accesso avviato da SP. Utilizza invece l'URL avviato da SP.

Disabilitazione dell'autenticazione SAML

Per disattivare l'autenticazione SAML per le OpenSearch dashboard (console)

1. Scegli il dominio, Operazioni quindi Modifica configurazione di sicurezza.

2. Deselezionare Abilita autenticazione SAML.

3. Sceglie Save changes (Salva modifiche).

4. Al termine dell'elaborazione del dominio, verificare la mappatura dei ruoli del controllo granulare degli accessi con la seguente richiesta:

   GET _plugins/_security/api/rolesmapping

   La disabilitazione dell'autenticazione SAML per Dashboards non rimuove le mappature per il nome utente principale SAML e/o il ruolo backend principale SAML. Se si desidera rimuovere queste mappature, accedere a Dashboards utilizzando il database utente interno (se abilitato) oppure l'API:

   PUT _plugins/_security/api/rolesmapping/all_access
   {
     "users": [
       "master-user"
     ]
   }