Autenticazione SAML per dashboard OpenSearch

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

Invece di eseguire l'autenticazione tramite Amazon Cognito o il database utenti interno, l'autenticazione SAML OpenSearch per dashboard consente di utilizzare provider di identità di terze parti per accedere alle dashboard, gestire il controllo granulare degli accessi, cercare i dati e creare visualizzazioni. OpenSearch Il servizio supporta provider che utilizzano lo standard SAML 2.0, come Okta, Keycloak, Active Directory Federation Services (ADFS), Auth0 e. AWS IAM Identity Center

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

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, ma solo per il tuo OpenSearch dominio di servizio.

Il flusso di accesso a OpenSearch Dashboards 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.

• Provider di identità (IdP) avviato: accedi al tuo provider di identità, accedi e scegli OpenSearch Dashboard da una directory di applicazioni.

OpenSearch Il servizio fornisce due Single Sign-On URLs, avviato da SP e avviato da IdP, ma è necessario solo quello che corrisponde al flusso di accesso desiderato per Dashboards. 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:

• 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 dashboard, devi disabilitarla 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 Amazon Service OpenSearch .

• Le policy di controllo dei servizi (SCP) non saranno applicabili o valutate in caso di identità non IAM (come SAML in Amazon OpenSearch Serverless e SAML e l'autorizzazione utente interna di base per Amazon Service). OpenSearch

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 all'interno di 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/*"
    }
  ]
}

Per rendere la politica più restrittiva, puoi aggiungere una condizione relativa all'indirizzo IP. Questa condizione limita l'accesso solo all'intervallo di indirizzi IP o alla sottorete specificati. Ad esempio, la seguente politica consente l'accesso solo dalla sottorete 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

Una politica di accesso al dominio aperta richiede l'attivazione di un controllo granulare degli accessi sul dominio, altrimenti viene visualizzato il seguente errore:

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

Se hai un utente principale o un utente interno configurato con una password robusta, mantenere aperta la policy utilizzando un controllo granulare degli accessi potrebbe essere accettabile dal punto di vista della sicurezza. Per ulteriori informazioni, consulta Controllo granulare degli accessi in Amazon Service OpenSearch .

Configurazione dell'autenticazione avviata da SP o da IdP

Questi passaggi spiegano come abilitare l'autenticazione SAML con l'autenticazione avviata da SP o IdP per i 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 Dashboards/Kibana, seleziona Abilita l'autenticazione SAML. OpenSearch

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, Service non è ancora in grado di generare un ID di entità OpenSearch del fornitore di servizi o SSO. URLs 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 quale sarà. URLs 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.

Nota

Non puoi accedere con un endpoint dual stack perché il nome di dominio completo di una richiesta HTTP è diverso dal nome di dominio completo di una richiesta SAML. Un OpenSearch amministratore dovrà configurare un endpoint personalizzato e impostare il valore CNAME su un endpoint dual stack se desideri accedere utilizzando un endpoint dual stack.

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, consultare Passaggio 6: aggiorna il tuo IdP URLs.

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 SSO. URLs 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, si specifica l'ID dell'entità SP come audience SAML dell'applicazione. È inoltre necessario specificare le seguenti mappature degli attributi: e. Subject=${user:subject}:format=unspecified Role=${user:groups}:format=uri

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 della 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 principale SAML e ruolo di backend principale SAML: l'utente e/o il ruolo di backend specificato riceve le autorizzazioni complete per il cluster, equivalenti a quelle di un nuovo utente master, ma può 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 mancata corrispondenza. hard-to-diagnose 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.

Passaggio 6: aggiorna il tuo IdP URLs

Se hai abilitato l'autenticazione SAML durante la creazione di un dominio, dovevi specificare il valore temporaneo URLs all'interno del tuo IdP per generare il file di metadati XML. Dopo che lo stato del dominio è cambiato inActive, puoi ottenere il tuo URLs IdP corretto e modificarlo.

Per recuperarlo URLs, seleziona il dominio e scegli Azioni, Modifica configurazione di sicurezza. In Autenticazione SAML per OpenSearch Dashboards/Kibana, puoi trovare l'ID dell'entità del fornitore di servizi e l'SSO corretti. URLs Copia i valori e usali per configurare il tuo provider di identità, sostituendo il valore temporaneo fornito nel passaggio 2. URLs

Fase 7: Associazione degli utenti SAML ai ruoli

Una volta che lo stato del dominio è Attivo e il tuo IdP è configurato correttamente, accedi a OpenSearch Dashboards.

• 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 di OpenSearch Dashboards, 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 opensearch_dashboards_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": "/opensearch_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 Consenti a questa app di richiedere altri URLs SSO.

4. In Requestable SSO URLs, aggiungi uno o più SSO avviati dall'SP. URLs 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 OpenSearch i 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 all'API OpenSearch di servizio.

Risoluzione dei problemi SAML

Errore	Informazioni
La tua 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 politica di accesso al dominio consenta l'accesso alle 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. L'amministratore di sistema può verificare il contenuto dell'asserzione SAML utilizzando uno strumento come SAML-Tracer, quindi verificare la mappatura dei ruoli utilizzando la seguente richiesta: GET _plugins/_security/api/rolesmapping
Il browser reindirizza o riceve continuamente errori HTTP 500 quando tenta di accedere alle dashboard. OpenSearch	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 che tutte le richieste di disconnessione siano firmate, cosa che OpenSearch Service 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 dell'entità dell'IdP fornito nei metadati XML to OpenSearch Service è diverso da quello nella risposta SAML. Per risolvere questo problema, assicurati che corrispondano. Abilita i log degli errori dell'applicazione CW sul tuo dominio per trovare il messaggio di errore per il debug del problema di integrazione SAML.
Signature validation failed. SAML response rejected.	OpenSearch Il servizio non è in grado di verificare la firma nella risposta SAML utilizzando il certificato dell'IdP fornito nei metadati XML. Potrebbe trattarsi di un errore manuale o il certificato del tuo IdP potrebbe aver modificato 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 SP audience 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 registri degli errori dell'applicazione CW sul tuo dominio per trovare il messaggio di errore per eseguire il debug del problema di integrazione SAML.
Il tuo browser riceve un errore HTTP 400 nella risposta. Invalid Request Id	Questo errore si verifica in genere se hai configurato l'URL avviato dall'IdP con il formato. <DashboardsURL>/_opendistro/_security/saml/acs Configura invece l'URL con il formato. <DashboardsURL>/_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: <DashboardsURL>/_opendistro/_security/saml/acs <DashboardsURL>/_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 dei seguenti. OpenSearch URLs
La risposta ha un InResponseTo attributo, mentre non era previsto. InResponseTo	Stai utilizzando l'URL avviato dall'IdP per un flusso di accesso avviato da SP. Utilizza invece l'URL avviato da SP.

Disabilitazione dell'autenticazione SAML

Per disabilitare l'autenticazione SAML per OpenSearch Dashboards (console)

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

2. Deselezionare Abilita autenticazione SAML.

3. Scegli 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"
     ]
   }