SAMLautenticazione per i OpenSearch pannelli di controllo

SAMLl'autenticazione per OpenSearch Dashboards ti consente di utilizzare il tuo provider di identità esistente per offrire single sign-on (SSO) per dashboard su domini OpenSearch Amazon Service che OpenSearch eseguono o Elasticsearch 6.7 o versione successiva. Per utilizzare l'SAMLautenticazione, devi abilitare il controllo granulare degli accessi.

Anziché eseguire l'autenticazione tramite Amazon Cognito o il database utenti internoSAML, l'autenticazione OpenSearch per Dashboards 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 (), Auth0 e. ADFS AWS IAM Identity Center

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

SAMLpanoramica della configurazione

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 dominio OpenSearch di servizio.

Il flusso di accesso a OpenSearch Dashboards può assumere una delle due forme seguenti:

OpenSearch Il servizio fornisce due Single Sign-OnURLs, 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 è accedere tramite il provider di identità e ricevere un'SAMLasserzione contenente il nome utente (obbligatorio) e gli eventuali ruoli di backend (facoltativo, ma consigliato). Queste informazioni consentono un 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

Quando configuri l'autenticazione, considera quanto segue: SAML

SAMLautenticazione per i domini VPC

SAMLnon richiede una comunicazione diretta tra il provider di identità e il fornitore di servizi. Pertanto, anche se il OpenSearch dominio è ospitato in un ambiente privatoVPC, è comunque possibile utilizzarlo SAML purché il browser sia in grado di comunicare sia con il OpenSearch cluster che con il provider di identità. Il browser agisce essenzialmente come intermediario tra il provider di identità e il provider di servizi. Per un utile diagramma che spiega il flusso di SAML autenticazione, consulta la documentazione di Okta.

Modifica della policy di accesso al dominio

Prima di configurare SAML l'autenticazione, è necessario aggiornare la politica di accesso al dominio per consentire agli SAML utenti di accedere al dominio. 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 alla politica. 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/*"
    }
  ]
}

Configurazione dell'autenticazione avviata da SP o da IdP

Questi passaggi spiegano come abilitare SAML l'autenticazione 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.

Passaggio 1: abilitare l'autenticazione SAML

È possibile abilitare SAML l'autenticazione durante la creazione del dominio o scegliendo Azioni, 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 SAMLAutenticazione per OpenSearch Dashboards/Kibana, seleziona Abilita autenticazione. SAML

Fase 2: Configurazione del fornitore di identità

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

Se stai creando un nuovo dominio

Se stai creando un nuovo dominio, OpenSearch Service non è ancora in grado di generare un ID di entità del fornitore di servizi o SSOURLs. Il tuo provider di identità richiede questi valori per abilitare correttamente SAML l'autenticazione, 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 URLs sarà. Ad esempio, se l'endpoint personalizzato èwww.custom-endpoint.com, l'ID dell'entità del fornitore di servizi saràwww.custom-endpoint.com, l'IdP avviato SSO URL sarà e l'www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiatedSP-avviato sarà. SSO URL 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 https://temp-endpoint.amazonaws.com inserire i campi Single sign-on URL e Audience URI (SP Entity ID), che ti 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 Passaggio 6: aggiorna il tuo IdP URLs.

Se stai modificando un dominio esistente

Se stai abilitando SAML l'autenticazione su un dominio esistente, copia l'ID dell'entità del fornitore di servizi e uno dei. SSO URLs Per indicazioni su quale URL usare, consultaSAMLpanoramica della configurazione.

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, si crea un'applicazione web SAML 2.0. Per Single Sign-On URL, specificare. SSO URL Per Audience URI (SP Entity ID), specificare l'ID dell'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 role nel campo dell'SAMLasserzione dopo l'autenticazione di un utente.

In IAM Identity Center, si specifica l'ID dell'entità SP come destinatario dell'applicazione. SAML È inoltre necessario specificare le seguenti mappature degli attributi: Subject=${user:subject}:format=unspecified e. Role=${user:groups}:format=uri

In Auth0, crei una normale applicazione web e abiliti il SAML componente aggiuntivo 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 XML file contiene informazioni sul provider, come un TLS certificato, gli endpoint Single Sign-on e l'ID dell'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, scegli Importa da XML file e carica 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>

Passaggio 4: Configurare i campi SAML

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

Molti provider di identità consentono di visualizzare un'asserzione di esempio durante il processo di configurazione e strumenti come SAML-tracer possono aiutarti a esaminare e risolvere i problemi relativi al contenuto delle 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:

Se la configurazione ti soddisfa, salva il dominio.

Passaggio 6: aggiorna il tuo IdP URLs

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

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

Passaggio 7: mappare SAML gli utenti ai ruoli

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

In entrambi i casi, accedi come utente SAML principale o come utente che appartiene al ruolo di backend SAML principale. 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 le OpenSearch dashboard API anziché le 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:

Configurazione dell'autenticazione SAML ()AWS CLI

Il AWS CLI comando seguente abilita SAML l'autenticazione per i 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 evitare tutte le virgolette e i caratteri di nuova riga nei metadati. XML Ad esempio, utilizzare <KeyDescriptor use=\"signing\">\n invece di <KeyDescriptor use="signing"> e un'interruzione di riga. Per informazioni dettagliate sull'utilizzo di AWS CLI, consultate il AWS CLI Command Reference.

Configurazione dell'SAMLautenticazione (configurazioneAPI)

La seguente richiesta alla configurazione API abilita SAML l'autenticazione 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 evitare tutte le virgolette e i caratteri di nuova riga nei metadati. XML Ad esempio, utilizzare <KeyDescriptor use=\"signing\">\n invece di <KeyDescriptor use="signing"> e un'interruzione di riga. Per informazioni dettagliate sull'utilizzo della configurazioneAPI, consulta il riferimento al OpenSearch servizio API.

SAMLrisoluzione dei problemi

GET _plugins/_security/api/rolesmapping

SAMLDisabilitazione dell'autenticazione