Activation de la fédération SAML avec AWS Identity and Access Management - Amazon OpenSearch Service
Étape 1 : configurer l'application du fournisseur d'identité (Okta)Étape 2 : Configuration de AWS la configuration pour OktaÉtape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAMÉtape 4 : vérifier l'expérience d'authentification unique initiée par le fournisseur d'identité avec SAML

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Activation de la fédération SAML avec AWS Identity and Access Management

OpenSearch L'interface utilisateur prend en charge le langage SAML (Security Assertion Markup Language 2.0), un standard ouvert utilisé par de nombreux fournisseurs d'identité. Cela permet la fédération d'identité avec AWS Identity and Access Management (IAM). Grâce à cette assistance, les utilisateurs de votre compte ou de votre organisation peuvent accéder directement à l' OpenSearch interface utilisateur en assumant les rôles IAM. Vous pouvez créer une expérience d'authentification unique initiée par le fournisseur d'identité (IdP) pour vos utilisateurs finaux, dans le cadre de laquelle ils peuvent s'authentifier auprès du fournisseur d'identité externe et être redirigés directement vers la page que vous avez définie dans l'interface utilisateur. OpenSearch Vous pouvez également mettre en œuvre un contrôle d'accès précis en configurant vos utilisateurs finaux ou vos groupes pour qu'ils assument différents rôles IAM avec différentes autorisations d'accès à l' OpenSearch interface utilisateur et aux sources de données associées.

Cette rubrique présente des step-by-step instructions pour configurer l'utilisation de SAML avec l' OpenSearch interface utilisateur. Dans ces procédures, nous utilisons les étapes de configuration de l'application de gestion des identités et des accès Okta à titre d'exemple. Les étapes de configuration pour les autres fournisseurs d'identité, tels qu'Azure Active Directory et Ping, sont similaires.

Étape 1 : configurer l'application du fournisseur d'identité (Okta)

Pour utiliser SAML avec l' OpenSearch interface utilisateur, la première étape consiste à configurer votre fournisseur d'identité.

Tâche 1 : créer des utilisateurs Okta

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en tant qu'utilisateur doté de privilèges administratifs.

  2. Sur la console d'administration, sous Répertoire dans le volet de navigation, sélectionnez Personnes.

  3. Choisissez Add person (Ajouter une personne).

  4. Dans le champ Prénom, entrez le prénom de l'utilisateur.

  5. Dans Nom de famille, entrez le nom de famille de l'utilisateur.

  6. Dans Nom d'utilisateur, entrez le nom d'utilisateur de l'utilisateur au format e-mail.

  7. Choisissez Je vais définir un mot de passe et entrez un mot de passe

  8. (Facultatif) Décochez la case L'utilisateur doit changer de mot de passe lors de sa première connexion si vous ne souhaitez pas que l'utilisateur change le mot de passe lors de sa première connexion.

  9. Choisissez Enregistrer.

Tâche 2 : créer et attribuer des groupes

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en tant qu'utilisateur doté de privilèges administratifs.

  2. Sur la console d'administration, sous Répertoire dans le volet de navigation, choisissez Groups.

  3. Choisissez Add Group (Ajouter un groupe).

  4. Entrez un nom de groupe et choisissez Enregistrer.

  5. Choisissez le groupe nouvellement créé, puis choisissez Affecter des personnes.

  6. Choisissez le signe plus (+), puis cliquez sur OK.

  7. (Facultatif) Répétez les étapes 1 à 6 pour ajouter d'autres groupes.

Tâche 3 : créer des applications Okta

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en tant qu'utilisateur doté de privilèges administratifs.

  2. Sur la console d'administration, sous Applications dans le volet de navigation, sélectionnez Applications.

  3. Choisissez Create App Integration (Créer une intégration d'appli).

  4. Choisissez SAML 2.0 comme méthode de connexion, puis choisissez Next.

  5. Entrez un nom pour l'intégration de votre application (par exemple,OpenSearch_UI), puis choisissez Next.

  6. Entrez les valeurs suivantes dans l'application ; il n'est pas nécessaire de modifier les autres valeurs :

    1. 1. Pour l'URL d'authentification unique, entrez https://signin.aws.amazon.com/saml pour les AWS régions commerciales ou l'URL spécifique à votre région.

    2. 2. Pour l'URI d'audience (ID d'entité SP), entrezurn:amazon:webservices.

    3. 3. Pour le format Name ID, entrezEmailAddress.

  7. Choisissez Suivant.

  8. Choisissez Je suis un client Okta qui ajoute une application interne, puis choisissez Il s'agit d'une application interne que nous avons créée.

  9. Choisissez Finish (Terminer).

  10. Choisissez Affectations, puis Attribuer.

  11. Choisissez Affecter aux groupes, puis sélectionnez Attribuer à côté des groupes que vous souhaitez ajouter.

  12. Sélectionnez Exécuté.

Tâche 4 : configurer la configuration avancée d'Okta

Après avoir créé l'application SAML personnalisée, procédez comme suit :

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en tant qu'utilisateur doté de privilèges administratifs.

    Sur la console de l'administrateur, dans la zone Général, choisissez Modifier dans les paramètres SAML.

  2. Choisissez Suivant.

  3. Définissez l'état du relais par défaut sur le point de terminaison de l' OpenSearch interface utilisateur, en utilisant le format suivant :

    https://region.console.aws.amazon.com/aos/home?region=region#opensearch/applications/application-id/redirectToDashboardURL.

    Voici un exemple :

    https://us-east-2.console.aws.amazon.com/aos/home?region=us-east-2#opensearch/applications/abc123def4567EXAMPLE/redirectToDashboardURL

  4. Sous Déclarations d'attribut (facultatif), ajoutez les propriétés suivantes :

    1. Indiquez le rôle IAM et le fournisseur d'identité séparés par des virgules à l'aide de l'attribut Role. Vous utiliserez ce même rôle IAM et ce même fournisseur d'identité lors d'une étape ultérieure lors de la configuration de AWS la configuration.

    2. Définissez user.login pour. RoleSessionName Il est utilisé comme identifiant pour les informations d'identification temporaires émises lorsque le rôle est assumé.

    À titre de référence :

    Nom Format du nom Format exemple

    https://aws.amazon.com/SAML/Attributes/Role

    Non précisé

    arn:aws:iam::aws-account-id:role/role-name,arn:aws:iam::aws-account-id:saml-provider/provider-name

    arn:aws:iam::111222333444:role/oktarole,arn:aws:iam::111222333444:saml-provider/oktaidp

    https://aws.amazon.com/SAML/Attributes/RoleSessionName

    Non précisé

    user.login

    user.login

  5. Après avoir ajouté les propriétés de l'attribut, cliquez sur Suivant, puis sur Terminer.

Le format de vos attributs doit être similaire à celui illustré dans l'image suivante. La valeur de l'état du relais par défaut est l'URL permettant de définir la page de destination pour les utilisateurs finaux de votre compte ou de votre organisation une fois qu'ils ont terminé la validation de l'authentification unique auprès d'Okta. Vous pouvez le définir sur n'importe quelle page de l' OpenSearch interface utilisateur, puis fournir cette URL aux utilisateurs finaux auxquels il est destiné.

La zone « SAML 2.0 » indique l'URL de l'état du relais par défaut et l'URL des métadonnées d'une application.

Étape 2 : Configuration de AWS la configuration pour Okta

Effectuez les tâches suivantes pour configurer votre AWS configuration pour Okta.

Tâche 1 : recueillir des informations sur Okta

Pour cette étape, vous devez rassembler vos informations Okta afin de pouvoir les configurer ultérieurement. AWS

  1. Connectez-vous à votre organisation Okta à l'adresse https://login.okta.com/en tant qu'utilisateur doté de privilèges administratifs.

  2. Dans l'onglet Connexion, dans le coin inférieur droit de la page, choisissez Afficher les instructions de configuration SAML.

  3. Prenez note de la valeur de l'URL d'authentification unique du fournisseur d'identité. Vous pouvez utiliser cette URL lorsque vous vous connectez à un client SQL tiers tel que SQL Workbench/J.

  4. Utilisez les métadonnées du fournisseur d'identité dans le bloc 4, puis enregistrez le fichier de métadonnées au format .xml (par exemple,metadata.xml).

Tâche 2 : créer le fournisseur IAM

Pour créer votre fournisseur IAM, procédez comme suit :

  1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à https://console.aws.amazon.com/iam/l'adresse.

  2. Dans le volet de navigation, sous Gestion des accès, sélectionnez Fournisseurs d'identité.

  3. Choisissez Ajouter un fournisseur.

  4. Pour le type de fournisseur, sélectionnez SAML.

  5. Pour Nom du fournisseur, entrez un nom.

  6. Pour le document de métadonnées, choisissez Choisir un fichier et chargez le fichier de métadonnées (.xml) que vous avez téléchargé précédemment.

  7. Choisissez Ajouter un fournisseur.

Tâche 3 : créer un rôle IAM

Pour créer votre AWS Identity and Access Management rôle, procédez comme suit :

  1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à https://console.aws.amazon.com/iam/l'adresse.

  2. Dans le volet de navigation, sous Gestion des accès, sélectionnez Rôles.

  3. Choisissez Créer un rôle.

  4. Pour le type d'entité fiable, sélectionnez la fédération SAML 2.0.

  5. Pour le fournisseur basé sur SAML 2.0, choisissez le fournisseur d'identité que vous avez créé précédemment.

  6. Sélectionnez Autoriser la programmation et l' AWS Management Console accès.

  7. Choisissez Suivant.

  8. Dans la liste des politiques d'autorisation, cochez les cases correspondant à la politique que vous avez créée précédemment et pour laquelle OpenSearchFullAccess.

  9. Choisissez Suivant.

  10. Dans la zone Révision, pour Nom du rôle, entrez le nom de votre rôle ; par exemple,oktarole.

  11. (Facultatif) Dans Description, entrez une brève description de l'objectif du rôle.

  12. Choisissez Créer un rôle.

  13. Accédez au rôle que vous venez de créer, choisissez l'onglet Relations de confiance, puis choisissez Modifier la politique de confiance.

  14. Dans le volet Modifier le relevé, sous Ajouter des actions pour STS, cochez la case correspondant à TagSession.

  15. Choisissez Mettre à jour une politique.

Étape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAM

Cette rubrique fournit des informations pour configurer vos rôles IAM avec accès aux OpenSearch services. Nous fournissons des exemples pour deux groupes Alice et Bob pour montrer comment obtenir un contrôle d'accès précis pour vos groupes d'utilisateurs à partir d'Okta.

Sample group: Alice

Requête :

GET _plugins/_security/api/roles/alice-group

Résultat:

{
  "alice-group": {
    "reserved": false,
    "hidden": false,
    "cluster_permissions": [
      "unlimited"
    ],
    "index_permissions": [
      {
        "index_patterns": [
          "alice*"
        ],
        "dls": "",
        "fls": [],
        "masked_fields": [],
        "allowed_actions": [
          "indices_all"
        ]
      }
    ],
    "tenant_permissions": [
      {
        "tenant_patterns": [
          "global_tenant"
        ],
        "allowed_actions": [
          "kibana_all_write"
        ]
      }
    ],
    "static": false
  }
}
Sample group: Bob

Requête :

GET _plugins/_security/api/roles/bob-group

Résultat:

{
  "bob-group": {
    "reserved": false,
    "hidden": false,
    "cluster_permissions": [
      "unlimited"
    ],
    "index_permissions": [
      {
        "index_patterns": [
          "bob*"
        ],
        "dls": "",
        "fls": [],
        "masked_fields": [],
        "allowed_actions": [
          "indices_all"
        ]
      }
    ],
    "tenant_permissions": [
      {
        "tenant_patterns": [
          "global_tenant"
        ],
        "allowed_actions": [
          "kibana_all_write"
        ]
      }
    ],
    "static": false
  }
}

Vous pouvez mapper les rôles de domaine Amazon OpenSearch Service aux rôles IAM à l'aide du mappage des rôles principaux, comme illustré dans l'exemple suivant :

{
  "bob-group": {
    "hosts": [],
    "users": [],
    "reserved": false,
    "hidden": false,
    "backend_roles": [
      "arn:aws:iam::111222333444:role/bob-group"
    ],
    "and_backend_roles": []
  },
  "alice-group": {
    "hosts": [],
    "users": [],
    "reserved": false,
    "hidden": false,
    "backend_roles": [
      "arn:aws:iam::111222333444:role/alice-group"
    ],
    "and_backend_roles": []
  }
}

Étape 4 : vérifier l'expérience d'authentification unique initiée par le fournisseur d'identité avec SAML

Ouvrez l'URL de l'état du relais par défaut pour ouvrir la page d'authentification Okta. Entrez les informations d'identification d'un utilisateur final. Vous êtes automatiquement redirigé vers l' OpenSearch interface utilisateur.

Vous pouvez vérifier vos informations d'identification actuelles en cliquant sur l'icône utilisateur en bas du panneau de navigation, comme illustré dans l'image suivante :

Le choix de l'icône utilisateur sur la page « Paramètres et configuration » d'Okta affiche les informations d'identification de l'utilisateur actuel.

Vous pouvez également vérifier les autorisations de contrôle d'accès détaillées accordées à l'utilisateur en accédant aux outils de développement en bas du panneau de navigation et en exécutant des requêtes dans la console. Vous trouverez ci-dessous des exemples de requêtes.

Example 1: Displays information about the current user

Requête :

GET _plugins/_security/api/account

Résultat:

{
  "user_name": "arn:aws:iam::XXXXXXXXXXXX:role/bob-group",
  "is_reserved": false,
  "is_hidden": false,
  "is_internal_user": false,
  "user_requested_tenant": null,
  "backend_roles": [
    "arn:aws:iam::XXXXXXXXXXXX:role/bob-group"
  ],
  "custom_attribute_names": [],
  "tenants": {
    "global_tenant": true,
    "arn:aws:iam::XXXXXXXXXXXX:role/bob-group": true
  },
  "roles": [
    "bob-group"
  ]
}
Example 2: Displays actions permitted for a user

Requête :

GET bob-test/_search

Résultat:

{
  "took": 390,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "bob-test",
        "_id": "ui01N5UBCIHpjO8Jlvfy",
        "_score": 1,
        "_source": {
          "title": "Your Name",
          "year": "2016"
        }
      }
    ]
  }
}
Example 3: Displays actions not permitted for a user

Requête :

GET alice-test

Résultat:

{
  "error": {
    "root_cause": [
      {
        "type": "security_exception",
        "reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
      }
    ],
    "type": "security_exception",
    "reason": "no permissions for [indices:admin/get] and User [name=arn:aws:iam::111222333444:role/bob-group, backend_roles=[arn:aws:iam::111222333444:role/bob-group], requestedTenant=null]"
  },
  "status": 403
}