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), une norme ouverte utilisée 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 prise en charge, les utilisateurs de votre compte ou de votre organisation peuvent accéder directement à l' OpenSearch interface utilisateur en assumant des 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, leur permettant de s'authentifier auprès du fournisseur d'identité externe et d'ê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 des autorisations différentes pour accéder à l' OpenSearch interface utilisateur et aux sources de données associées. Cette rubrique présente des instructions détaillées 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. **Note** Si vous utilisez AWS IAM Identity Center, il n'est pas nécessaire de configurer la fédération SAML comme décrit dans cette rubrique. OpenSearch L'interface utilisateur prend en charge IAM Identity Center de manière native, ce qui fournit un accès SSO sans configuration SAML supplémentaire. IAM Identity Center prend également en charge la gestion des utilisateurs et des groupes au niveau de l'organisation. L'intégration SAML décrite ici est destinée aux fournisseurs d'identité tiers (tels qu'Okta, Azure Active Directory et Ping) qui ne sont pas IAM Identity Center. **Topics** + [Étape 1 : configurer l'application du fournisseur d'identité (Okta)](#SAML-identity-federation-step-1) + [Étape 2 : Configuration AWS 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érification de l' Sign-On expérience unique initiée par le fournisseur d'identité avec SAML](#SAML-identity-federation-step-4) + [Étape 5 : Configuration du contrôle d'accès affiné basé sur les attributs SAML](#SAML-identity-federation-step-5) ## Étape 1 : configurer l'application du fournisseur d'identité (Okta) Pour utiliser SAML avec OpenSearch interface utilisateur, la première étape consiste à configurer votre fournisseur d'identité. **Tâche 1 : Création d'utilisateurs Okta** 1. Connectez-vous à votre organisation Okta en [ https://login.okta.com/ ](https://login.okta.com/) tant qu'utilisateur doté de privilèges administratifs. 1. Sur la console d'administration, sous ** Répertoire ** dans le volet de navigation, choisissez ** Personnes**. 1. Choisissez **Add person** (Ajouter une personne). 1. Dans ** le champ Prénom**, saisissez le prénom de l'utilisateur. 1. Pour ** Nom de famille**, entrez le nom de famille de l'utilisateur. 1. Dans le ** champ Nom d'utilisateur**, entrez le nom d'utilisateur de l'utilisateur au format e-mail. 1. Choisissez ** Je vais définir le mot de passe ** et entrez un mot de passe 1. (Facultatif) Décochez la ** case L'**utilisateur doit changer le mot de passe lors de la 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éation et attribution de groupes** 1. Connectez-vous à votre organisation Okta en [ https://login.okta.com/ ](https://login.okta.com/) tant qu'utilisateur doté de privilèges administratifs. 1. Sur la console d'administration, sous ** Répertoire ** dans le volet de navigation, choisissez ** Groupes**. 1. Choisissez **Add Group (Ajouter un groupe)**. 1. Entrez un nom de groupe et choisissez ** Enregistrer**. 1. Choisissez le groupe que vous venez de créer, puis choisissez ** Attribuer des personnes**. 1. Choisissez le signe plus (**\+**), puis choisissez ** OK**. 1. (Facultatif) Répétez les étapes 1 à 6 pour ajouter d'autres groupes. **Tâche 3 : Création d'applications Okta** 1. Connectez-vous à votre organisation Okta en [ https://login.okta.com/ ](https://login.okta.com/) 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\_UI**), puis choisissez ** Suivant**. 1. Entrez les valeurs suivantes dans l'application ; vous n'avez pas besoin 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 de l'**audience (ID d'entité SP)**, entrez**urn:amazon:webservices**. 1. 3. Dans le ** champ Format d'identification du nom**, 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 ** Assignations**, puis choisissez ** Attribuer**. 1. Choisissez ** Attribuer 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 en [ https://login.okta.com/ ](https://login.okta.com/) 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'attributs (facultatif)**, ajoutez les propriétés suivantes : 1. Fournissez le rôle IAM et le fournisseur d'identité dans un format séparé par des virgules à l'aide de l'**attribut Role. ** Vous utiliserez ce même rôle IAM et ce même fournisseur d'identité ultérieurement lors de la AWS configuration. 1. Définissez ** user.login ** pour. ** RoleSessionName ** Il est utilisé comme identifiant pour les informations d'identification temporaires qui sont émises lorsque le rôle est assumé. Pour référence :
NomFormat du nomFormatExemple
https://aws.amazon.com/SAML/Attributes/RoleNon spécifiéarn:aws:iam::aws-account-id:role/role-name,arn:aws:iam::aws-account-id:saml-provider/provider-namearn:aws:iam::111222333444:role/oktarole,arn:aws:iam::111222333444:saml-provider/oktaidp
https://aws.amazon.com/SAML/Attributes/RoleSessionNameNon spécifiéuser.loginuser.login
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 de l'image suivante. La ** valeur ** Default Relay State 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 la définir sur n'importe quelle page de l' OpenSearch interface utilisateur, puis fournir cette URL aux utilisateurs finaux auxquels elle est destinée. ![La zone « SAML 2.0 » indique l'URL d'état du relais par défaut et l'URL des métadonnées pour une application.](https://docs.aws.amazon.com/fr_fr/opensearch-service/latest/developerguide/images/ui-saml-2.0-area-okta.png) ## Étape 2 : Configuration AWS configuration pour Okta Effectuez les tâches suivantes pour configurer votre AWS configuration pour Okta. **Tâche 1 : Collecter les informations d'Okta** Pour cette étape, vous devrez collecter vos informations Okta afin de pouvoir les configurer ultérieurement. AWS 1. Connectez-vous à votre organisation Okta en [ https://login.okta.com/ ](https://login.okta.com/) 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' Sign-onURL 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 au Console de gestion AWS et ouvrez la console IAM à [ 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 ** Identity providers**. 1. Choisissez **Ajouter un fournisseur**. 1. Pour 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éation d'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 au Console de gestion AWS et ouvrez la console IAM à [ 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**, choisissez ** Rôles**. 1. Choisissez **Créer un rôle**. 1. Pour Type d'entité ** sécurisée**, sélectionnez 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' Console de gestion AWS accès**. 1. **Note** Sous ** Sign-in Points de terminaison**, sélectionnez ** sans identifiant ** unique. Si vous sélectionnez ** avec des identifiants uniques**, la `SAML:aud` condition de la politique de confiance ne correspondra pas à l'audience d'assertion SAML, ce qui entraînera une `AccessDenied` erreur lorsque les utilisateurs tenteront de se connecter. 1. Choisissez **Suivant**. 1. Dans la ** liste Politiques d'**autorisations, cochez les cases correspondant aux politiques qui accordent des autorisations de OpenSearch service, par exemple une politique AWS gérée ** 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 la déclaration, sous ** Ajouter des actions pour STS**, cochez la case pour ** TagSession**. 1. Choisissez **Mettre à jour une politique**. ## Étape 3 : Création de la politique d'accès à Amazon OpenSearch Service dans IAM Apprenez à configurer vos rôles IAM pour le contrôle OpenSearch d'accès. Grâce aux rôles IAM, vous pouvez mettre en œuvre un contrôle d'accès précis pour permettre à vos groupes d'utilisateurs Okta d'accéder aux ressources. OpenSearch Cette rubrique présente 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érification de l' Sign-On expérience unique initiée par le fournisseur d'identité avec SAML Ouvrez l'URL de ** Default Relay State ** 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 choisissant 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.](https://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 affinées de 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. Voici 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 affiné basé sur les attributs SAML Avec Amazon OpenSearch Service, vous pouvez utiliser un contrôle d'accès précis avec SAML pour mapper les utilisateurs et les groupes de votre fournisseur d'identité à des utilisateurs et à des rôles de contrôle d'accès OpenSearch précis de manière dynamique. 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 précis, consultez. [Fine-grained contrôle d'accès dans Amazon OpenSearch Service](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. **Clé des rôles ** Cartes vers les 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'attributs : + Nom : `UserName` + Valeur : `${user-email}` Cet attribut est utilisé comme clé d'**objet ** dans la configuration de contrôle d'accès OpenSearch affinée pour l'authentification. 1. Ajoutez un attribut de groupe pour les rôles dans la ** section Déclaration des attributs de ** groupe : + Nom : `groups` + Filtre : `OpenSearch_xxx` Cet attribut est utilisé comme clé de ** rôle ** pour mapper les 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 un 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 ** sécurité et cliquez sur ** Modifier**. 1. Développez ** 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 précis à 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 un contrôle SAML-based d'accès précis dans Serverless OpenSearch** 1. Ouvrez le Console de gestion AWS et accédez à Amazon OpenSearch Service. 1. Dans le volet de navigation, sous ** Serverless**, choisissez ** Security**, puis ** Authentication**. 1. Dans la ** section ** IAM Federation, sélectionnez ** Modifier**. Vous pouvez contrôler le contrôle d'accès affiné 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 Politique ** d'accès aux ** données. 1. Mettez à jour une politique existante ou créez-en une nouvelle. 1. Développez une règle, choisissez ** Ajouter des principaux**, puis sélectionnez Utilisateurs et ** groupes IAM Federation. ** 1. Ajoutez les principaux 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. + Vous pouvez éventuellement définir 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 l'interface de ligne de commande 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"}' ```