SAMLauthentification pour les OpenSearch tableaux de bord

SAMLL'authentification pour les OpenSearch tableaux de bord vous permet d'utiliser votre fournisseur d'identité existant pour proposer l'authentification unique (SSO) pour les tableaux de bord sur les domaines Amazon OpenSearch Service exécutant Elasticsearch 6.7 OpenSearch ou version ultérieure. Pour utiliser SAML l'authentification, vous devez activer le contrôle d'accès détaillé.

Plutôt que de vous authentifier via Amazon Cognito ou la base de données utilisateur interneSAML, l'authentification OpenSearch pour les tableaux de bord vous permet de faire appel à des fournisseurs d'identité tiers pour vous connecter aux tableaux de bord, gérer un contrôle d'accès précis, rechercher vos données et créer des visualisations. OpenSearch Le service prend en charge les fournisseurs qui utilisent la norme SAML 2.0, tels que Okta, Keycloak, Active Directory Federation Services (ADFS), Auth0 et. AWS IAM Identity Center

SAMLl'authentification pour les tableaux de bord permet uniquement d'accéder aux OpenSearch tableaux de bord via un navigateur Web. Vos SAML informations d'identification ne vous permettent pas de faire des HTTP demandes directes aux tableaux de bord OpenSearch ou aux tableaux de bordAPIs.

SAMLaperçu de la configuration

Cette documentation suppose que vous disposez d'un fournisseur d'identité existant avec lequel vous êtes familier. Nous ne pouvons pas fournir d'étapes de configuration détaillées pour votre fournisseur exact, uniquement pour votre domaine OpenSearch de service.

Le flux de connexion OpenSearch aux tableaux de bord peut prendre l'une des deux formes suivantes :

OpenSearch Le service fournit deux connexions uniquesURLs, initiées par le SP et initiées par l'IdP, mais vous n'avez besoin que de celle qui correspond au flux de connexion aux tableaux de bord que vous souhaitez. OpenSearch

Quel que soit le type d'authentification que vous utilisez, l'objectif est de vous connecter via votre fournisseur d'identité et de recevoir une SAML assertion contenant votre nom d'utilisateur (obligatoire) et tous les rôles de backend (facultatif, mais recommandé). Ces informations permettent un contrôle d'accès précis pour attribuer des autorisations aux SAML utilisateurs. Dans les fournisseurs d'identité externes, les rôles backend sont généralement appelés « rôles » ou « groupes ».

Considérations

Tenez compte des points suivants lorsque vous configurez SAML l'authentification :

SAMLauthentification pour les VPC domaines

SAMLne nécessite pas de communication directe entre votre fournisseur d'identité et votre fournisseur de services. Par conséquent, même si votre OpenSearch domaine est hébergé dans un espace privéVPC, vous pouvez toujours l'utiliser SAML tant que votre navigateur peut communiquer à la fois avec votre OpenSearch cluster et avec votre fournisseur d'identité. Votre navigateur joue essentiellement le rôle d'intermédiaire entre votre fournisseur d'identité et votre fournisseur de services. Pour un schéma utile expliquant le flux SAML d'authentification, consultez la documentation Okta.

Modification de la stratégie d'accès au domaine

Avant de configurer SAML l'authentification, vous devez mettre à jour la politique d'accès au domaine pour permettre aux SAML utilisateurs d'accéder au domaine. Sinon, vous recevrez des erreurs d'accès refusé.

Nous recommandons la stratégie d'accès au domaine suivante, qui fournit un accès complet aux sous-ressources (/*) du domaine :

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

Pour rendre la politique plus restrictive, vous pouvez y ajouter une condition d'adresse IP. Cette condition limite l'accès uniquement à la plage d'adresses IP ou au sous-réseau spécifié. Par exemple, la politique suivante autorise l'accès uniquement depuis le sous-réseau 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/*"
    }
  ]
}

Configuration de l'authentification initiée par le fournisseur de services ou le fournisseur d'identité

Ces étapes expliquent comment activer l'SAMLauthentification avec l'authentification initiée par le SP ou l'IdP pour les tableaux de bord. OpenSearch Pour l'étape supplémentaire nécessaire pour activer les deux, consultez Activer l'authentification initiée par le SP et l'IdP.

Étape 1 : activer SAML l'authentification

Vous pouvez activer SAML l'authentification soit lors de la création du domaine, soit en choisissant Actions, Modifier la configuration de sécurité sur un domaine existant. Les étapes suivantes varient légèrement en fonction de celle que vous choisissez.

Dans la configuration du domaine, sous SAMLAuthentification pour les OpenSearch tableaux de bord/Kibana, sélectionnez Activer l'authentification. SAML

Étape 2 : configurer votre fournisseur d'identité

Procédez comme suit en fonction du moment où vous configurez SAML l'authentification.

En cas de création d'un nouveau domaine

Si vous êtes en train de créer un nouveau domaine, OpenSearch Service ne peut pas encore générer d'ID d'entité de fournisseur de services ou SSOURLs. Votre fournisseur d'identité a besoin de ces valeurs pour activer correctement SAML l'authentification, mais elles ne peuvent être générées qu'après la création du domaine. Pour contourner cette interdépendance lors de la création du domaine, vous pouvez fournir des valeurs temporaires dans votre configuration IdP afin de générer les métadonnées requises, puis les mettre à jour une fois que votre domaine est actif.

Si vous utilisez un point de terminaison personnalisé, vous pouvez en déduire ce qu'il URLs sera. Par exemple, si votre point de terminaison personnalisé l'estwww.custom-endpoint.com, l'identifiant de l'entité du fournisseur de services sera le caswww.custom-endpoint.com, l'identifiant initié par l'IDP le SSO URL sera www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs/idpinitiated et le SP SSO URL le sera. www.custom-endpoint.com/_dashboards/_opendistro/_security/saml/acs Vous pouvez utiliser ces valeurs pour configurer votre fournisseur d'identité avant la création du domaine. Consultez la section suivante pour examiner des exemples.

Si vous n'utilisez pas de point de terminaison personnalisé, vous pouvez saisir des valeurs temporaires dans votre IdP pour générer les métadonnées requises, puis les mettre à jour ultérieurement une fois le domaine actif.

Par exemple, dans Okta, vous pouvez https://temp-endpoint.amazonaws.com entrer dans les champs Single Sign on URL et Audience URI (SP Entity ID), ce qui vous permet de générer les métadonnées. Ensuite, une fois le domaine actif, vous pouvez récupérer les valeurs correctes auprès de OpenSearch Service et les mettre à jour dans Okta. Pour obtenir des instructions, consultez Étape 6 : mettez à jour votre IdP URLs.

En cas de modification d'un domaine existant

Si vous activez SAML l'authentification sur un domaine existant, copiez l'identifiant de l'entité du fournisseur de services et l'un des SSOURLs. Pour savoir lequel URL utiliser, voirSAMLaperçu de la configuration.

Utilisez les valeurs pour configurer votre fournisseur d'identité. Il s'agit-là de la partie la plus complexe du processus, et malheureusement, la terminologie de même que la procédure changent considérablement d'un fournisseur à l'autre. Consultez la documentation de votre fournisseur.

Dans Okta, par exemple, vous créez une application Web SAML 2.0. Pour l'authentification unique URL, spécifiez le SSOURL. Pour Audience URI (ID d'entité SP), spécifiez l'ID d'entité SP.

Plutôt que d'utilisateurs et de rôles backend, Okta parle d'utilisateurs et de groupes. Pour Group Attribute Statements (Instructions d'attributs de groupe), nous vous recommandons d'ajouter role au champ Name (Nom) et l'expression régulière .+ au champ Filter (Filtrer). Cette instruction indique au fournisseur d'identité Okta d'inclure tous les groupes d'utilisateurs dans le role champ de l'SAMLassertion une fois qu'un utilisateur s'est authentifié.

Dans IAM Identity Center, vous spécifiez l'ID de l'entité SP comme SAMLaudience de l'application. Vous devez également spécifier les mappages d'attributs suivants : Subject=${user:subject}:format=unspecified etRole=${user:groups}:format=uri.

Dans Auth0, vous créez une application Web normale et activez le module complémentaire SAML 2.0. Dans Keycloak, vous créez un client.

Étape 3 : importer les métadonnées IdP

Une fois votre fournisseur d'identité configuré, il génère un fichier de métadonnées de fournisseur d'identité. Ce XML fichier contient des informations sur le fournisseur, telles qu'un TLS certificat, des points de terminaison d'authentification unique et l'ID d'entité du fournisseur d'identité.

Copiez le contenu du fichier de métadonnées IdP et collez-le dans le champ Metadata from IdP de la console de service. OpenSearch Vous pouvez également choisir Importer depuis un XML fichier et charger le fichier. Le fichier de métadonnées doit se présenter comme suit :

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

Étape 4 : Configuration SAML des champs

Après avoir saisi les métadonnées de votre IdP, configurez les champs supplémentaires suivants dans la console de OpenSearch service :

De nombreux fournisseurs d'identité vous permettent de consulter un exemple d'assertion pendant le processus de configuration, et des outils tels que SAML-tracer peuvent vous aider à examiner et à résoudre les problèmes liés au contenu d'assertions réelles. Les assertions se présentent comme suit :

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

Étape 5 : (Facultatif) configurer des paramètres supplémentaires

Sous Additional settings (Paramètres supplémentaires), configurez les champs facultatifs suivants :

Une fois que la configuration vous convient, enregistrez le domaine.

Étape 6 : mettez à jour votre IdP URLs

Si vous avez activé SAML l'authentification lors de la création d'un domaine, vous deviez spécifier une URLs valeur temporaire dans votre IdP afin de générer le fichier de XML métadonnées. Une fois que le statut du domaine est Active passé à, vous pouvez obtenir le bon URLs identifiant et modifier votre IdP.

Pour les récupérerURLs, sélectionnez le domaine et choisissez Actions, Modifier la configuration de sécurité. Sous SAMLAuthentification pour OpenSearch Dashboards/Kibana, vous pouvez trouver l'ID d'entité du fournisseur de services correct et. SSO URLs Copiez les valeurs et utilisez-les pour configurer votre fournisseur d'identité, en remplaçant le temporaire URLs que vous avez fourni à l'étape 2.

Étape 7 : Associer SAML les utilisateurs aux rôles

Une fois que le statut de votre domaine est actif et que votre IdP est correctement configuré, accédez à OpenSearch Tableaux de bord.

Dans les deux cas, connectez-vous en tant qu'utilisateur SAML principal ou en tant qu'utilisateur appartenant au rôle SAML principal de backend. Pour continuer l'exemple de l'étape 7, connectez-vous en tant que jdoe ou un membre du groupe admins.

Une fois OpenSearch les tableaux de bord chargés, choisissez Sécurité, Rôles. Mappez ensuite les rôles pour permettre aux autres utilisateurs d'accéder aux OpenSearch tableaux de bord.

Par exemple, vous pouvez mapper un collègue de confiance jroe aux rôles all_access et security_manager. Vous pouvez également mapper le rôle backend analysts aux rôles readall et opensearch_dashboards_user.

Si vous préférez utiliser les tableaux de OpenSearch bord API plutôt que les tableaux de bord, consultez l'exemple de demande suivant :

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

Configuration de l'authentification initiée à la fois par le SP et l'IdP

Si vous souhaitez configurer l'authentification initiée par le fournisseur de services et le fournisseur d'identité, vous devez le faire via votre fournisseur d'identité. Par exemple, dans Okta, vous pouvez effectuer les étapes suivantes :

Configuration de SAML l'authentification (AWS CLI)

La AWS CLI commande suivante active SAML l'authentification pour les OpenSearch tableaux de bord sur un domaine existant :

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

Vous devez éviter les guillemets et les caractères de nouvelle ligne dans les métadonnéesXML. Par exemple, utilisez <KeyDescriptor use=\"signing\">\n plutôt que <KeyDescriptor use="signing"> et un saut de ligne. Pour obtenir des informations détaillées sur l'utilisation du AWS CLI, consultez le manuel de référence des AWS CLI commandes.

Configuration de SAML l'authentification (configurationAPI)

La demande suivante adressée à la configuration API active l'SAMLauthentification pour les OpenSearch tableaux de bord sur un domaine existant :

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

Vous devez éviter les guillemets et les caractères de nouvelle ligne dans les métadonnéesXML. Par exemple, utilisez <KeyDescriptor use=\"signing\">\n plutôt que <KeyDescriptor use="signing"> et un saut de ligne. Pour obtenir des informations détaillées sur l'utilisation de la configurationAPI, consultez la APIréférence du OpenSearch service.

SAMLrésolution des problèmes

GET _plugins/_security/api/rolesmapping

Désactivation SAML de l'authentification