Autenticazione SAML per OpenSearch Dashboards - Amazon OpenSearch Service

Autenticazione SAML per OpenSearch Dashboards

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

Piuttosto che autenticarsi tramite Amazon Cognito o con il database degli utenti interno, l'autenticazione SAML per i pannelli di controllo OpenSearch consente di utilizzare provider di identità di terze parti per accedere a Dashboards, gestire il controllo granulare degli accessi, cercare i dati e creare visualizzazioni. Il servizio OpenSearch supporta i provider che utilizzano lo standard SAML 2.0, ad esempio Okta, Keycloak, Active Directory Federation Services (ADFS) e Auth0.

Nota

Le richieste da OpenSearch Service a provider di terze parti non vengono crittografate esplicitamente con un certificato del provider di servizi.

L'autenticazione SAML per Dashboards serve solo per accedere a OpenSearch Dashboards tramite un browser Web. Le credenziali SAML non consentono di effettuare richieste HTTP dirette alle API OpenSearch o Dashboards.

Panoramica della configurazione SAML

Questa documentazione presuppone che si disponga di un provider di identità esistente e di una certa familiarità con esso. Non siamo in grado di fornire passaggi di configurazione dettagliati per ogni singolo provider, solo per il dominio di OpenSearch Service.

Il flusso di accesso a Dashboards può assumere uno dei due formati 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.

  • Avviato da provider di identità (IdP): è possibile passare al provider di identità, accedere e scegliere Dashboards da una directory dell'applicazione.

OpenSearch Service fornisce due URL Single Sign-On, avviato da SP e da IdP, ma è necessario solo quello che corrisponde al flusso di accesso a Dashboards desiderato. 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 è possibile abilitare l'opzione Consenti a questa app di richiedere altri URL SSO e aggiungere uno o più URL SSO avviati da IdP.

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

Nota

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

Autenticazione SAML per domini in esecuzione in un VPC

SAML non richiede una comunicazione diretta tra il provider di identità e il provider di servizi. Quindi, anche se il dominio OpenSearch è ospitato in un VPC privato, è comunque possibile utilizzare SAML purché il browser possa comunicare sia con il cluster OpenSearch che con il 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.

Abilitazione dell'autenticazione SAML

È possibile abilitare l'autenticazione SAML per OpenSearch Dashboards solo sui domini esistenti, non durante la creazione di nuovi domini. A causa delle dimensioni del file di metadati IdP, si consiglia vivamente di utilizzare la console AWS.

I domini supportano solo un metodo di autenticazione Dashboards alla volta. Se l'autenticazione Amazon Cognito per OpenSearch Dashboards è abilitata, sarà necessario disabilitarla prima di poter abilitare SAML.

Come abilitare l'autenticazione SAML per Dashboards (console)

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

  2. Selezionare Abilita autenticazione SAML.

  3. Prendere nota dell'ID entità del provider di servizi e dei due URL SSO. È necessario solo uno degli URL SSO. Per le linee guida, consulta Panoramica della configurazione SAML.

    Suggerimento

    Questi URL cambiano se in un secondo momento si abilita un endpoint personalizzato per il proprio dominio. In questo caso, è necessario aggiornare l'IdP.

  4. Utilizzare questi valori per configurare il provider 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, si crea una "applicazione web SAML 2.0". Per URL Single Sign-On (SSO) specificare l'URL SSO scelto nella fase 3. 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 Auth0, si crea una "applicazione Web normale” e quindi si attiva il componente aggiuntivo SAML 2.0. In Keycloak, viene creato un "client".

  5. 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à.

    Copiare il contenuto del file di metadati IdP e incollarlo nella cartella Metadati da IdP nella console di OpenSearch Service. 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>
  6. Copiare il valore della proprietà entityID dal file di metadati e incollarlo nel campo ID entità IdP nella console di OpenSearch Service. Molti provider di identità visualizzano questo valore anche come parte di un riepilogo successivo alla configurazione. Alcuni fornitori lo chiamano "emittente".

  7. Fornire un Nome utente master SAML e/o un Ruolo backend master SAML. Questo nome utente e/o il ruolo back-end riceve autorizzazioni complete per il cluster, equivalenti a unNuovo utente master, ma può utilizzare tali autorizzazioni solo all'interno di Dashboards.

    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 Ruolo backend master SAML, qualsiasi utente che appartiene al gruppo admins riceverà le autorizzazioni complete.

    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 loro nomi utente, il che può causare una mancata corrispondenza difficile da diagnosticare. 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/_plugins/_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>
  8. (Facoltativo) Espandere Additional settings (Impostazioni aggiuntive).

  9. Lasciare il campo Chiave oggetto vuoto in modo da utilizzare il campo 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.

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

  10. 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 la Durata (TTL) della sessione.

  11. Scegliere Save changes (Salva modifiche). Il dominio entra in uno stato di elaborazione per circa un minuto, durante il quale Dashboards non è disponibile.

  12. Al termine dell'elaborazione del dominio, aprire Dashboards.

    • Se è stato scelto l'URL avviato da SP, passare a domain-endpoint/_dashboards/.

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

  13. Dopo il caricamento di Dashboards, scegliere Sicurezza e Ruoli.

  14. Mappare i ruoli per consentire ad altri utenti di accedere a Dashboards.

    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 si preferisce utilizzare l'API anziché Dashboards, vedere 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": "/kibana_user", "value": { "backend_roles": ["analysts"] } } ]

Comando CLI di esempio

Il seguente comando AWS CLI abilita l'autenticazione SAML per OpenSearch pannello di controllo 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.

Richiesta dell'API di configurazione di esempio

La seguente richiesta all'API di configurazione abilita l'autenticazione SAML per OpenSearch Dashboards 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, consultare Riferimento dell'API di configurazione per Amazon OpenSearch Service.

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

Fornire 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, controllare 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.

  • Verificare che la policy di accesso al dominio consenta l'accesso a OpenSearch Dashboards 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, contattare 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 browser reindirizza continuamente o riceve errori HTTP 500 quando si prova ad accedere a OpenSearch Dashboards.

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.

Non è possibile disconnettersi da ADFS.

ADFS richiede la firma di tutte le richieste di disconnessione, che il servizio OpenSearch non supporta. Rimuovere <SingleLogoutService /> dal file di metadati IdP per forzare OpenSearch Service a utilizzare il proprio meccanismo di disconnessione interno.

Disabilitazione dell'autenticazione SAML

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

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

  2. Deselezionare Abilita autenticazione SAML.

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