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 Gestion des identités et des accès AWS
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 Gestion des identités et des accès AWS (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.
**Topics**
+ [
## Étape 1 : configurer l'application du fournisseur d'identité (Okta)
](#SAML-identity-federation-step-1)
+ [
## Étape 2 : Configuration de AWS la configuration pour Okta
](#SAML-identity-federation-step-2)
+ [
## Étape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAM
](#SAML-identity-federation-step-3)
+ [
## Étape 4 : vérifier l'expérience d'authentification unique initiée par le fournisseur d'identité avec SAML
](#SAML-identity-federation-step-4)
+ [
## Étape 5 : Configuration du contrôle d'accès détaillé basé sur les attributs SAML
](#SAML-identity-federation-step-5)
## É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/](https://login.okta.com/)en tant qu'utilisateur doté de privilèges administratifs.
1. Sur la console d'administration, sous **Répertoire** dans le volet de navigation, sélectionnez **Personnes**.
1. Choisissez **Add person** (Ajouter une personne).
1. Dans **le champ Prénom**, entrez le prénom de l'utilisateur.
1. Dans **Nom de famille**, entrez le nom de famille de l'utilisateur.
1. Dans **Nom d'utilisateur**, entrez le nom d'utilisateur de l'utilisateur au format e-mail.
1. Choisissez **Je vais définir un mot de passe** et entrez un mot de passe
1. (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.
1. Choisissez **Enregistrer**.
**Tâche 2 : créer et attribuer des groupes**
1. Connectez-vous à votre organisation Okta à l'adresse [https://login.okta.com/](https://login.okta.com/)en tant qu'utilisateur doté de privilèges administratifs.
1. Sur la console d'administration, sous **Répertoire** dans le volet de navigation, choisissez **Groups**.
1. Choisissez **Add Group (Ajouter un groupe)**.
1. Entrez un nom de groupe et choisissez **Enregistrer**.
1. Choisissez le groupe nouvellement créé, puis choisissez **Affecter des personnes**.
1. Choisissez le signe plus (**\$1**), puis cliquez sur **OK**.
1. (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/](https://login.okta.com/)en tant qu'utilisateur doté de privilèges administratifs.
1. Sur la console d'administration, sous **Applications** dans le volet de navigation, sélectionnez **Applications**.
1. Choisissez **Create App Integration (Créer une intégration d'appli)**.
1. **Choisissez SAML 2.0 comme méthode de connexion, puis choisissez Next.**
1. Entrez un nom pour l'intégration de votre application (par exemple,**OpenSearch\$1UI**), puis choisissez **Next**.
1. 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.
1. 2. Pour l'**URI d'audience (ID d'entité SP)**, entrez**urn:amazon:webservices**.
1. 3. Pour le **format du nom et de l'identifiant**, entrez**EmailAddress**.
1. Choisissez **Suivant**.
1. 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**.
1. Choisissez **Finish** (Terminer).
1. Choisissez **Affectations**, puis **Attribuer**.
1. Choisissez **Affecter aux groupes**, puis sélectionnez **Attribuer** à côté des groupes que vous souhaitez ajouter.
1. 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/](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.**
1. Choisissez **Suivant**.
1. 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`
1. 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.
1. Définissez **user.login** pour. **RoleSessionName** Il est utilisé comme identifiant pour les informations d'identification temporaires émises lorsque le rôle est assumé.
Pour référence :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/application-enable-SAML-identity-federation.html)
1. 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.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/ui-saml-2.0-area-okta.png)
## É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/](https://login.okta.com/)en tant qu'utilisateur doté de privilèges administratifs.
1. Dans l'**onglet Connexion**, dans le coin inférieur droit de la page, choisissez **Afficher les instructions de configuration SAML**.
1. 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](https://www.sql-workbench.eu/).
1. 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/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation, sous **Gestion des accès**, sélectionnez **Fournisseurs d'identité**.
1. Choisissez **Ajouter un fournisseur**.
1. Pour le **type de fournisseur**, sélectionnez **SAML.**
1. Pour **Nom du fournisseur**, entrez un nom.
1. 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.
1. Choisissez **Ajouter un fournisseur**.
**Tâche 3 : créer un rôle IAM**
Pour créer votre Gestion des identités et des accès AWS rôle, procédez comme suit :
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le volet de navigation, sous **Gestion des accès**, sélectionnez **Rôles**.
1. Choisissez **Créer un rôle**.
1. Pour le **type d'entité fiable**, sélectionnez la **fédération SAML 2.0**.
1. Pour le **fournisseur basé sur SAML 2.0, choisissez le fournisseur** d'identité que vous avez créé précédemment.
1. Sélectionnez **Autoriser la programmation et l' AWS Management Console accès**.
1. Choisissez **Suivant**.
1. Dans la liste des **politiques d'autorisations**, cochez les cases correspondant aux politiques qui accordent des autorisations de OpenSearch service, par exemple, les politiques AWS gérées **AmazonOpenSearchServiceFullAccess**.
1. Choisissez **Suivant**.
1. Dans la zone **Révision**, pour **Nom du rôle**, entrez le nom de votre rôle ; par exemple,**oktarole**.
1. (Facultatif) Dans **Description**, entrez une brève description de l'objectif du rôle.
1. Choisissez **Créer un rôle**.
1. Accédez au rôle que vous venez de créer, choisissez l'onglet **Relations de confiance**, puis choisissez **Modifier la politique de confiance**.
1. Dans le volet **Modifier le relevé**, sous **Ajouter des actions pour STS**, cochez la case correspondant à **TagSession**.
1. Choisissez **Mettre à jour une politique**.
## Étape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAM
Découvrez comment configurer vos rôles IAM pour le contrôle OpenSearch d'accès. Avec les rôles IAM, vous pouvez mettre en œuvre un contrôle d'accès précis pour que vos groupes d'utilisateurs Okta puissent accéder aux ressources. OpenSearch Cette rubrique décrit la configuration basée sur les rôles IAM à l'aide de deux exemples de groupes.
------
#### [ 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.\]](http://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/ui-okta-user-icon.png)
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
}
```
------
## Étape 5 : Configuration du contrôle d'accès détaillé basé sur les attributs SAML
Avec Amazon OpenSearch Service, vous pouvez utiliser le contrôle d'accès détaillé avec SAML pour mapper de manière dynamique les utilisateurs et les groupes de votre fournisseur d'identité aux utilisateurs et rôles de contrôle OpenSearch d'accès précis. Vous pouvez étendre ces rôles à des OpenSearch domaines spécifiques et à des collections sans serveur, et définir des autorisations au niveau de l'index et une sécurité au niveau du document.
**Note**
Pour plus d'informations sur le contrôle d'accès détaillé, consultez. [Contrôle d'accès précis dans Amazon Service OpenSearch](fgac.md)
**Topics**
+ [
### Attributs SAML pour un contrôle d'accès précis
](#saml-fgac-key-attributes)
+ [
### Tâche 1 : configurer Okta pour un contrôle d'accès précis
](#configure-okta-fgac)
+ [
### Tâche 2 : configurer SAML dans le domaine OpenSearch
](#configure-opensearch-domain-fgac)
+ [
### Tâche 3 : configurer SAML dans les collections OpenSearch sans serveur
](#saml-configure-collections)
### Attributs SAML pour un contrôle d'accès précis
**Clé du sujet**
Correspond à un attribut utilisateur unique, tel qu'une adresse e-mail ou un nom d'utilisateur, qui identifie l'utilisateur à des fins d'authentification.
**Rôles Key**
Correspond aux attributs de groupe ou de rôle de votre IdP qui déterminent les rôles ou les autorisations d'autorisation.
### Tâche 1 : configurer Okta pour un contrôle d'accès précis
**Pour configurer Okta pour un contrôle d'accès précis**
1. Ajoutez un nouvel attribut pour l' OpenSearch utilisateur principal dans la section **Déclarations d'attribut** :
+ Nom : `UserName`
+ Valeur : `${user-email}`
Cet attribut est utilisé comme **clé d'objet** dans la configuration OpenSearch précise du contrôle d'accès pour l'authentification.
1. Ajoutez un attribut de groupe pour les rôles dans la section **Déclaration d'attribut de groupe** :
+ Nom : `groups`
+ Filtre : `OpenSearch_xxx`
Cet attribut est utilisé comme **clé de rôle** pour mapper des groupes à des rôles de contrôle d'accès OpenSearch précis à des fins d'autorisation.
### Tâche 2 : configurer SAML dans le domaine OpenSearch
**Pour configurer SAML dans le domaine OpenSearch**
1. Dans la console AWS de gestion, identifiez le domaine de OpenSearch service pour lequel vous souhaitez activer un contrôle d'accès précis pour les utilisateurs de l' OpenSearch interface utilisateur.
1. Accédez à la page de détails du domaine en question.
1. Sélectionnez l'onglet **Configuration de la sécurité** et cliquez sur **Modifier**.
1. Développez le **protocole SAML via IAM Federate**.
1. Entrez le `subjectKey` et `roleKey` que vous avez défini dans Okta.
1. Sélectionnez **Enregistrer les modifications**.
Vous pouvez également configurer un contrôle d'accès détaillé à l'aide du. AWS CLI
```
aws opensearch create-domain \
--domain-name testDomain \
--engine-version OpenSearch_1.3 \
--cluster-config InstanceType=r5.xlarge.search,InstanceCount=1,DedicatedMasterEnabled=false,ZoneAwarenessEnabled=false,WarmEnabled=false \
--access-policies '{"Version": "2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":"es:*","Resource":"arn:aws:es:us-east-1:12345678901:domain/neosaml10/*"}]}' \
--domain-endpoint-options '{"EnforceHTTPS":true,"TLSSecurityPolicy":"Policy-Min-TLS-1-2-2019-07"}' \
--node-to-node-encryption-options '{"Enabled":true}' \
--encryption-at-rest-options '{"Enabled":true}' \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"********","MasterUserPassword":"********"}, "IAMFederationOptions":{"Enabled": true,"SubjectKey":"TestSubjectKey","RolesKey":"TestRolesKey"}}' \
--ebs-options "EBSEnabled=true,VolumeType=gp2,VolumeSize=300" \
--no-verify-ssl \
--endpoint-url https://es.us-east-1.amazonaws.com \
--region us-east-1
```
Pour mettre à jour un domaine existant :
```
aws opensearch update-domain-config \
--domain-name testDomain \
--advanced-security-options '{"Enabled":true,"InternalUserDatabaseEnabled":true,"MasterUserOptions":{"MasterUserName":"********","MasterUserPassword":"********"}, "IAMFederationOptions":{"Enabled": true,"SubjectKey":"TestSubjectKey","RolesKey":"TestRolesKey"}}' \
--ebs-options "EBSEnabled=true,VolumeType=gp2,VolumeSize=300" \
--no-verify-ssl \
--endpoint-url https://es.us-east-1.amazonaws.com \
--region us-east-1
```
### Tâche 3 : configurer SAML dans les collections OpenSearch sans serveur
**Pour configurer le contrôle d'accès détaillé basé sur SAML dans Serverless OpenSearch**
1. Ouvrez le AWS Management Console et accédez à Amazon OpenSearch Service.
1. Dans le volet de navigation, sous **Serverless**, choisissez **Security**, puis **Authentication**.
1. Dans la section **Fédération IAM**, sélectionnez **Modifier**.
Vous pouvez contrôler le contrôle d'accès détaillé basé sur les attributs SAML à l'aide de cette configuration. La fédération IAM est désactivée par défaut.
1. Sélectionnez **Activer la fédération IAM**.
1. Entrez les `roleKey` valeurs `subjectKey` et que vous avez définies dans Okta.
Pour de plus amples informations, veuillez consulter [Attributs SAML pour un contrôle d'accès précis](#saml-fgac-key-attributes).
1. Cliquez sur **Enregistrer**.
1. Dans le volet de navigation, sous **Serverless**, choisissez **Data access policy**.
1. Mettez à jour une politique existante ou créez-en une nouvelle.
1. Développez une règle, choisissez **Ajouter des principes**, puis sélectionnez les **utilisateurs et les groupes de la fédération IAM**.
1. Ajoutez les principes requis et choisissez **Enregistrer**.
1. Choisissez **Accorder**.
1. Selon cette règle, procédez comme suit :
+ Sélectionnez les autorisations que vous souhaitez définir pour les principaux sélectionnés.
+ Spécifiez les collections auxquelles vous souhaitez appliquer les autorisations.
+ Définissez éventuellement des autorisations au niveau de l'index.
**Note**
Vous pouvez créer plusieurs règles pour attribuer différentes autorisations à différents groupes de directeurs.
1. Lorsque vous avez terminé, choisissez **Save (Sauvegarder)**.
1. Choisissez **Créer**.
Vous pouvez également utiliser la CLI pour créer les configurations de sécurité pour les collections, comme indiqué ci-dessous :
```
aws opensearchserverless create-security-config --region "region" --type iamfederation --name "configuration_name" --description "description" --iam-federation-options '{"groupAttribute":"GroupKey","userAttribute":"UserKey"}'
```