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. # Bonnes pratiques pour les applications multilocataires Les groupes d'utilisateurs Amazon Cognito fonctionnent avec des applications multi-locataires qui génèrent un volume de demandes qui doit rester dans les limites des quotas Amazon Cognito. Pour augmenter cette capacité lorsque votre clientèle augmente, vous pouvez [acheter des capacités de quota supplémentaires](quotas.md#managing-request-rate-quotas.title). **Note** Les [quotas](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html) Amazon Cognito sont appliqués au fur et à mesure. Compte AWS Région AWS Ces quotas sont partagés entre tous les locataires au sein de votre application. Passez en revue les quotas du service Amazon Cognito et assurez-vous qu'ils correspondent au volume attendu et au nombre de locataires attendus dans votre application. Cette section décrit les méthodes que vous pouvez mettre en œuvre pour séparer les locataires entre les ressources Amazon Cognito au sein d'une même région et. Compte AWS Vous pouvez également répartir vos locataires sur plusieurs Compte AWS régions et attribuer à chacun son propre quota. Parmi les autres avantages de la mutualisation multirégionale, citons le niveau d'isolation le plus élevé possible, le temps de transit réseau le plus court pour les utilisateurs répartis dans le monde entier et le respect des modèles de distribution existants dans votre organisation. La mutualisation dans une seule région peut également présenter des avantages pour vos clients et vos administrateurs. La liste suivante présente certains des avantages de la mutualisation avec des ressources partagées.Avantages de la location multiple **Répertoire d'utilisateurs commun** La mutualisation prend en charge les modèles dans lesquels les clients ont des comptes dans plusieurs applications. Vous pouvez [lier les identités de fournisseurs tiers](cognito-user-pools-identity-federation.md#cognito-user-pools-identity-federation.title) dans un profil de groupe d'utilisateurs unique et cohérent. Dans les cas où les profils d'utilisateurs sont propres à leur locataire, toute stratégie de mutualisation avec un pool d'utilisateurs unique comporte un point d'entrée unique dans l'administration des utilisateurs. **Sécurité commune** Dans un groupe d'utilisateurs partagé, vous pouvez créer une norme de sécurité unique et appliquer la même [protection contre les menaces](cognito-user-pool-settings-threat-protection.md#cognito-user-pool-settings-threat-protection.title), l'[authentification multifactorielle](user-pool-settings-mfa.md#user-pool-settings-mfa.title) (MFA) [AWS WAF](user-pool-waf.md#user-pool-waf.title)et les mêmes normes à tous les locataires. Comme une ACL AWS WAF Web doit se trouver dans la même Région AWS zone que la ressource à laquelle vous l'associez, la mutualisation offre un accès partagé à une ressource complexe. Lorsque vous souhaitez conserver une configuration de sécurité cohérente dans les applications Amazon Cognito multirégionales, vous devez appliquer des normes opérationnelles qui répliquent votre configuration entre les ressources. **Personnalisation commune** Vous pouvez personnaliser les groupes d'utilisateurs et les groupes d'identités avec AWS Lambda. La configuration des [déclencheurs Lambda](cognito-user-pools-working-with-lambda-triggers.md#cognito-user-pools-working-with-lambda-triggers.title) dans les groupes d'utilisateurs et des événements [Amazon Cognito](cognito-events.md#cognito-events.title) dans les groupes d'identités peut devenir complexe. Les fonctions Lambda doivent être identiques à celles Région AWS de votre groupe d'utilisateurs ou de votre groupe d'identités. Les fonctions Lambda partagées peuvent appliquer les normes relatives aux flux d'authentification personnalisés, à la migration des utilisateurs, à la génération de jetons et à d'autres fonctions au sein d'une région. **Messagerie courante** Amazon Simple Notification Service (Amazon SNS) nécessite une configuration supplémentaire dans une région avant que vous puissiez [envoyer des SMS](user-pool-sms-settings.md#user-pool-sms-settings.title) à vos utilisateurs. Vous pouvez envoyer [des e-mails avec des](user-pool-email.md#user-pool-email.title) identités vérifiées par Amazon Simple Email Service (Amazon SES) et des domaines contenus dans une région. Avec le multitenant, vous pouvez partager cette configuration et les frais de maintenance entre tous vos locataires. Amazon SNS et Amazon SES ne étant pas tous disponibles Régions AWS, la répartition de vos ressources entre les régions nécessite une attention particulière. Lorsque vous utilisez [des fournisseurs de messagerie personnalisés](user-pool-lambda-custom-sender-triggers.md#user-pool-lambda-custom-sender-triggers.title), vous bénéficiez de la *personnalisation commune* d'une seule fonction Lambda pour gérer la livraison de vos messages. La [connexion gérée](cognito-user-pools-managed-login.md#cognito-user-pools-managed-login.title) définit un cookie de session dans le navigateur afin qu'il reconnaisse un utilisateur qui s'est déjà authentifié. Lorsque vous authentifiez *des utilisateurs locaux* dans un groupe d'utilisateurs, leur cookie de session les authentifie pour tous les clients d'applications du même groupe d'utilisateurs. Un utilisateur local existe exclusivement dans l’annuaire de votre groupe d’utilisateurs sans fédération via un fournisseur d’identité externe. Le cookie de session est valide pendant une heure. Vous ne pouvez pas modifier la durée du cookie de session. Il existe deux méthodes pour empêcher la connexion entre les clients de l'application à l'aide d'un cookie de session d'interface utilisateur hébergé. + Séparez vos utilisateurs en groupes d'utilisateurs par locataire. + Remplacez la connexion à l'interface utilisateur hébergée par la connexion à l'API des groupes d'utilisateurs Amazon Cognito. **Topics** + [Meilleures pratiques en matière de mutualisation des pools d'utilisateurs](bp_user-pool-based-multi-tenancy.md) + [Meilleures pratiques en matière de mutualisation entre applications et clients](application-client-based-multi-tenancy.md) + [Meilleures pratiques en matière de mutualisation des groupes d'utilisateurs](group-based-multi-tenancy.md) + [Bonnes pratiques en matière de mutualisation d'attributs personnalisés](custom-attribute-based-multi-tenancy.md) + [Meilleures pratiques en matière de mutualisation sur mesure](scope-based-multi-tenancy.md) + [Recommandations en matière de sécurité multilocataire](multi-tenancy-security-recommendations.md) # Meilleures pratiques en matière de mutualisation des pools d'utilisateurs Créez un groupe d'utilisateurs pour chaque locataire de votre application. Cette approche offre un isolement maximal pour chaque locataire. Vous pouvez implémenter différentes configurations pour chaque locataire. L'isolation des locataires par groupe d'utilisateurs vous donne de la flexibilité dans le user-to-tenant mappage. Vous pouvez créer plusieurs profils pour un même utilisateur. Cependant, chaque utilisateur doit s'inscrire individuellement pour chaque locataire auquel il a accès. Grâce à cette approche, vous pouvez configurer une interface utilisateur hébergée pour chaque locataire indépendamment et rediriger les utilisateurs vers l'instance de votre application spécifique au locataire. Vous pouvez également utiliser cette approche pour intégrer des services principaux tels qu'[Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html). Le schéma suivant montre chaque locataire avec un pool d'utilisateurs dédié. ![\[Schéma d'un modèle one-to-one multi-tenant dans lequel chaque locataire possède son propre groupe d'utilisateurs.\]](http://docs.aws.amazon.com/fr_fr/cognito/latest/developerguide/images/multi-tenancy-user-pool.png) **Quand mettre en œuvre la mutualisation du pool d'utilisateurs** Lorsque l'isolation et la personnalisation sont vos principales préoccupations. La relation entre les utilisateurs et les locataires peut être complexe dans une architecture comportant plusieurs groupes d'utilisateurs. Prenons un exemple où vous avez deux locataires éducatifs. Le même utilisateur peut être un étudiant à accès limité dans une application et un enseignant disposant d'un niveau élevé d'autorisations dans une autre. Il se peut que vous ayez besoin de l'authentification MFA dans une application mais pas dans une autre, ou que vous ayez une politique de mot de passe différente. Étant donné que les utilisateurs locaux peuvent se connecter à plusieurs clients d'applications dans des groupes d'utilisateurs avec une connexion gérée, la mutualisation des groupes d'utilisateurs est également idéale lorsque vous souhaitez que plusieurs de vos locataires se connectent avec une connexion gérée. **Niveau d'effort** L'effort de développement et d'exploitation lié à cette approche est élevé. Pour garantir des résultats cohérents et prévisibles pour votre famille d'applications, vous devez intégrer les ressources Amazon Cognito à vos outils d'automatisation et conserver vos bases de référence à mesure que votre architecture d'authentification devient de plus en plus complexe. Lorsque vous souhaitez créer un point de départ unique pour vos applications, vous devez créer les éléments de l'interface utilisateur (UI) afin de capturer la décision initiale qui oriente les utilisateurs vers la bonne ressource. # Meilleures pratiques en matière de mutualisation entre applications et clients Créez un [client d'application](user-pool-settings-client-apps.md#user-pool-settings-client-apps.title) pour chaque locataire de votre application. Grâce à la mutualisation entre applications et clients, vous pouvez affecter n'importe quel utilisateur à des clients d'applications liés à des locataires et conserver un profil utilisateur unique. Comme vous pouvez attribuer l'un ou l'ensemble des [fournisseurs d'identité (IdPs)](cognito-user-pools-identity-federation.md#cognito-user-pools-identity-federation.title) de votre groupe d'utilisateurs à un client d'application, celui-ci peut autoriser la connexion avec un IdP spécifique au locataire. Lorsque les utilisateurs existent dans plusieurs locataires, vous pouvez associer leurs profils à plusieurs IdPs pour une expérience utilisateur cohérente. Le schéma suivant montre chaque locataire disposant d'un client d'application dédié dans un pool d'utilisateurs partagé. ![\[Schéma d'un modèle one-to-one multi-tenant dans lequel chaque locataire possède son propre client d'application dans un groupe d'utilisateurs partagé.\]](http://docs.aws.amazon.com/fr_fr/cognito/latest/developerguide/images/multi-tenancy-app-client.png) **Quand mettre en œuvre la mutualisation client-application** Quand vous pouvez choisir une configuration universelle pour les paramètres au niveau du pool d'utilisateurs, tels que les déclencheurs Lambda, la politique de mot de passe, le contenu et les méthodes de livraison des e-mails et des SMS. Étant donné que les utilisateurs d'un groupe d'utilisateurs partagé peuvent se connecter à n'importe quel client d'application, la mutualisation entre clients d'applications est idéale pour se connecter avec ou via l'API des groupes d'utilisateurs app-client-specific IdPs Amazon Cognito. La mutualisation client-application convient également aux one-to-many environnements dans lesquels vous souhaitez permettre aux utilisateurs de passer d'une application à une autre. **Niveau d'effort** La mutualisation entre l'application et le client nécessite un effort modéré. L'un des principaux défis de la mutualisation entre applications et clients est la possibilité pour les locataires de présenter un cookie d'interface utilisateur hébergé et de passer d'une application à l'autre. Dans une architecture mutualisée client-application, évitez de vous connecter à l'interface utilisateur hébergée lorsque l'isolation est nécessaire. Vous pouvez distribuer votre application mobile ou des liens vers votre application Web avec la logique du client d'application intégrée, ou vous pouvez créer des éléments d'interface utilisateur initiaux qui déterminent la location des utilisateurs. Le niveau d'effort est moindre car vous n'avez pas besoin de standardiser et de maintenir la configuration entre plusieurs groupes d'utilisateurs et groupes d'identités. # Meilleures pratiques en matière de mutualisation des groupes d'utilisateurs La mutualisation basée sur les groupes fonctionne mieux lorsque votre architecture nécessite des groupes d'utilisateurs Amazon Cognito dotés de groupes d'identités. L'[ID du groupe d'utilisateurs et les jetons d'accès](amazon-cognito-user-pools-using-tokens-with-identity-providers.md#amazon-cognito-user-pools-using-tokens-with-identity-providers.title) contiennent une `cognito:groups` réclamation. De plus, les jetons d'identification contiennent `cognito:roles` et `cognito:preferred_role` revendiquent. Lorsque le principal résultat de l'authentification dans votre application est des AWS informations d'identification temporaires provenant d'un pool d'identités, les appartenances aux groupes de vos utilisateurs peuvent déterminer le [rôle IAM](iam-roles.md#iam-roles.title) et les autorisations qu'ils reçoivent. Prenons l'exemple de trois locataires qui stockent chacun les actifs de l'application dans leur propre compartiment Amazon S3. Affectez les utilisateurs de chaque locataire à un groupe associé, configurez un rôle préféré pour le groupe et accordez à ce rôle un accès en lecture à leur bucket. Le schéma suivant montre les locataires partageant un client d'application et un groupe d'utilisateurs, avec des groupes dédiés dans le groupe d'utilisateurs qui déterminent leur éligibilité à un rôle IAM. ![\[Schéma d'un modèle many-to-one multi-tenant dans lequel chaque locataire possède son propre groupe d'utilisateurs dans un pool d'utilisateurs partagé.\]](http://docs.aws.amazon.com/fr_fr/cognito/latest/developerguide/images/multi-tenancy-group.png) **Quand mettre en œuvre la mutualisation collective** Lorsque l'accès aux AWS ressources est votre principale préoccupation. Les groupes des groupes d'utilisateurs Amazon Cognito constituent un mécanisme de contrôle d'accès basé sur les rôles (RBAC). Vous pouvez configurer de nombreux groupes dans un groupe d'utilisateurs et prendre des décisions RBAC complexes avec une priorité de groupe. Les pools d'identités peuvent attribuer des informations d'identification au rôle ayant la priorité la plus élevée, à n'importe quel rôle revendiqué par le groupe ou à partir d'autres revendications contenues dans les jetons d'un utilisateur. **Niveau d'effort** Le niveau d'effort pour maintenir la multilocation avec la seule adhésion à un groupe est faible. Toutefois, pour étendre le rôle des groupes de groupes d'utilisateurs au-delà de la capacité intégrée de sélection des rôles IAM, vous devez créer une logique d'application qui traite l'appartenance aux groupes dans les jetons des utilisateurs et déterminer ce qu'il faut faire dans le client. Vous pouvez intégrer Amazon Verified Permissions à vos applications pour prendre des décisions d'autorisation côté client. Les identifiants de groupe ne sont actuellement pas traités dans les opérations de [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)l'API Verified Permissions, mais vous pouvez [développer un code personnalisé](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html#identity-providers_other-idp) qui analyse le contenu des jetons, y compris les demandes d'adhésion à un groupe. # Bonnes pratiques en matière de mutualisation d'attributs personnalisés Amazon Cognito prend en charge les [attributs personnalisés](user-pool-settings-attributes.md#user-pool-settings-custom-attributes.title) avec des noms que vous choisissez. L'un des scénarios dans lesquels les attributs personnalisés sont utiles est lorsqu'ils distinguent la location des utilisateurs dans un groupe d'utilisateurs partagé. Lorsque vous attribuez aux utilisateurs une valeur pour un attribut tel que`custom:tenantID`, votre application peut attribuer l'accès aux ressources spécifiques au locataire en conséquence. Un attribut personnalisé qui définit un ID de locataire doit être immuable ou en lecture seule pour le client de l'application. Le schéma suivant montre les locataires partageant un client d'application et un groupe d'utilisateurs, avec des attributs personnalisés dans le groupe d'utilisateurs qui indiquent le locataire auquel ils appartiennent. ![\[Schéma d'un modèle many-to-one multi-tenant dans lequel chaque utilisateur possède son propre attribut d'utilisateur locataire dans un groupe d'utilisateurs partagé.\]](http://docs.aws.amazon.com/fr_fr/cognito/latest/developerguide/images/multi-tenancy-custom-attribute.png) Lorsque des attributs personnalisés déterminent la location, vous pouvez distribuer une seule application ou une seule URL de connexion. Une fois que votre utilisateur s'est connecté, votre application peut traiter la `custom:tenantID` réclamation, déterminer les actifs à charger, l'image de marque à appliquer et les fonctionnalités à afficher. Pour prendre des décisions avancées en matière de contrôle d'accès à partir des attributs utilisateur, configurez votre groupe d'utilisateurs en tant que fournisseur d'identité dans Amazon Verified Permissions et générez des décisions d'accès à partir du contenu des identifiants ou des jetons d'accès. **Quand mettre en œuvre la mutualisation des attributs personnalisés** Lorsque la location se fait au niveau de la surface. Un attribut tenant peut contribuer aux résultats de marque et de mise en page. Lorsque vous souhaitez obtenir une isolation significative entre les locataires, les attributs personnalisés ne sont pas le meilleur choix. Toute différence entre les locataires qui doit être configurée au niveau du pool d'utilisateurs ou du client de l'application, comme le MFA ou l'image de marque de l'interface utilisateur hébergée, nécessite que vous créiez des distinctions entre les locataires d'une manière que les attributs personnalisés ne proposent pas. Avec les pools d'identités, vous pouvez même choisir le rôle IAM parmi vos utilisateurs à partir de l'attribut personnalisé indiqué dans leur jeton d'identification. **Niveau d'effort** Étant donné que la mutualisation des attributs personnalisés transfère le devoir de prendre les décisions d'autorisation basées sur les locataires sur votre application, le niveau d'effort a tendance à être élevé. Si vous êtes déjà familiarisé avec une configuration client qui analyse les demandes OIDC ou avec Amazon Verified Permissions, cette approche peut nécessiter le moins d'efforts possible. # Meilleures pratiques en matière de mutualisation sur mesure [Amazon Cognito prend en charge les étendues OAuth 2.0 personnalisées pour les serveurs de ressources.](cognito-user-pools-define-resource-servers.md) Vous pouvez implémenter la mutualisation des clients d'applications dans les groupes d'utilisateurs pour les modèles d'autorisation machine-to-machine (M2M) avec des étendues personnalisées. La mutualisation basée sur le périmètre réduit les efforts nécessaires à la mise en œuvre de la mutualisation M2M en définissant l'accès dans le client de votre application ou dans la configuration de l'application. Le schéma suivant illustre une option pour la mutualisation d'une portée personnalisée. Il montre à chaque locataire un client d'application dédié qui a accès aux étendues pertinentes d'un pool d'utilisateurs. ![\[Schéma illustrant le flux des étendues personnalisées dans une architecture à locataires multiples.\]](http://docs.aws.amazon.com/fr_fr/cognito/latest/developerguide/images/multi-tenancy-custom-scope.png) **Quand mettre en œuvre la mutualisation personnalisée** Lorsque vous utilisez une autorisation M2M avec les informations d'identification du client dans un client confidentiel. Il est recommandé de créer des serveurs de ressources exclusifs à un client d'application. *La mutualisation à périmètre personnalisé peut dépendre de la *demande ou du client.** **En fonction de la demande** Mettez en œuvre une logique d'application pour ne demander que les étendues correspondant aux exigences de votre locataire. Par exemple, un client d'application peut être en mesure de délivrer un accès en lecture et en écriture à l'API A et à l'API B, mais l'application cliente A demande uniquement l'étendue de lecture de l'API A et la portée indiquant la location. Ce modèle permet des combinaisons plus complexes d'étendues partagées entre les locataires. **Dépendant du client** Demandez toutes les étendues attribuées à un client d'application dans vos demandes d'autorisation. Pour ce faire, omettez le paramètre de `scope` requête dans votre demande adressée au[Point de terminaison de jeton](token-endpoint.md). Ce modèle permet aux clients de l'application de stocker les indicateurs d'accès que vous souhaitez ajouter à vos étendues personnalisées. Dans les deux cas, vos applications reçoivent des jetons d'accès dont les étendues indiquent leurs privilèges pour les sources de données dont elles dépendent. Les scopes peuvent également présenter d'autres informations à votre application : + Désigner le bail + Contribuer à l'enregistrement des demandes + Indiquez APIs que l'application est autorisée à interroger + Indiquez les vérifications initiales pour les clients actifs. **Niveau d'effort** La mutualisation sur mesure nécessite un niveau d'effort variable en fonction de l'échelle de votre application. Vous devez concevoir une logique d'application qui permette à vos applications d'analyser les jetons d'accès et de faire les demandes d'API appropriées. Par exemple, l'étendue d'un serveur de ressources est disponible au format`[resource server identifier]/[name]`. Il est peu probable que l'identifiant du serveur de ressources soit pertinent pour la décision d'autorisation prise par le locataire, ce qui nécessite que le nom de l'étendue soit analysé de manière cohérente. ## Exemple de ressource Le AWS CloudFormation modèle suivant crée un groupe d'utilisateurs pour une mutualisation personnalisée avec un serveur de ressources et un client d'application. ``` AWSTemplateFormatVersion: "2010-09-09" Description: A sample template illustrating scope-based multi-tenancy Resources: MyUserPool: Type: "AWS::Cognito::UserPool" MyUserPoolDomain: Type: AWS::Cognito::UserPoolDomain Properties: UserPoolId: !Ref MyUserPool # Note that the value for "Domain" must be unique across all of AWS. # In production, you may want to consider using a custom domain. # See: https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-add-custom-domain.html#cognito-user-pools-add-custom-domain-adding Domain: !Sub "example-userpool-domain-${AWS::AccountId}" MyUserPoolResourceServer: Type: "AWS::Cognito::UserPoolResourceServer" Properties: Identifier: resource1 Name: resource1 Scopes: - ScopeDescription: Read-only access ScopeName: readScope UserPoolId: !Ref MyUserPool MyUserPoolTenantBatch1ResourceServer: Type: "AWS::Cognito::UserPoolResourceServer" Properties: Identifier: TenantBatch1 Name: TenantBatch1 Scopes: - ScopeDescription: tenant1 identifier ScopeName: tenant1 - ScopeDescription: tenant2 identifier ScopeName: tenant2 UserPoolId: !Ref MyUserPool MyUserPoolClientTenant1: Type: "AWS::Cognito::UserPoolClient" Properties: AllowedOAuthFlows: - client_credentials AllowedOAuthFlowsUserPoolClient: true AllowedOAuthScopes: - !Sub "${MyUserPoolTenantBatch1ResourceServer}/tenant1" - !Sub "${MyUserPoolResourceServer}/readScope" GenerateSecret: true UserPoolId: !Ref MyUserPool Outputs: UserPoolClientId: Description: User pool client ID Value: !Ref MyUserPoolClientTenant1 UserPoolDomain: Description: User pool domain Value: !Sub "https://${MyUserPoolDomain}.auth.${AWS::Region}.amazoncognito.com" ``` # Recommandations en matière de sécurité multilocataire Pour vous aider à sécuriser votre application, nous vous recommandons ce qui suit : + Validez la location dans votre application avec les autorisations vérifiées par Amazon. Élaborez des politiques qui examinent les droits relatifs au groupe d'utilisateurs, aux clients d'applications, aux groupes ou aux attributs personnalisés avant d'autoriser la demande d'un utilisateur dans votre application. AWS a créé des [sources d'identité](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) Verified Permissions en pensant aux groupes d'utilisateurs Amazon Cognito. Verified Permissions propose [des instructions supplémentaires](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html) pour la gestion de l'hébergement mutualisé. + Utilisez uniquement une adresse e-mail vérifiée pour autoriser l'accès utilisateur à un locataire sur la base d'une correspondance de domaine. Ne faites pas confiance aux adresses e-mail et aux numéros de téléphone à moins que votre application ne les ait vérifiés ou que le fournisseur d'identité externe n'ait fourni une preuve de vérification. Pour plus d'informations sur la définition de ces autorisations, consultez [Attribuer des autorisations et des périmètres](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html#user-pool-settings-attribute- permissions-and-scopes.html). + Utilisez des attributs personnalisés *immuables* ou en lecture seule pour les attributs de profil utilisateur qui identifient les locataires. Vous ne pouvez définir la valeur des attributs immuables que lorsque vous créez un utilisateur ou lorsqu'un utilisateur s'inscrit dans votre groupe d'utilisateurs. De plus, accordez aux clients d'application un accès en lecture seule à ces attributs. + Utilisez un mappage 1:1 entre l'IdP externe d'un locataire et le client d'application pour empêcher tout accès non autorisé entre locataires. Un utilisateur authentifié par un fournisseur d'identité externe et doté d'un cookie de session Amazon Cognito valide peut accéder aux applications d'autres locataires qui font confiance au même fournisseur d'identité. + Quand vous implémentez la logique d'autorisation et de correspondance de locataire dans votre application, limitez les utilisateurs afin qu'ils ne puissent pas modifier les critères utilisés pour autoriser l'accès des utilisateurs aux locataires. De plus, si un fournisseur d'identité externe est utilisé pour la fédération, limitez les administrateurs du fournisseur d'identité du locataire afin qu'ils ne puissent pas modifier l'accès utilisateur.