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 en matière de mutualisation d'attributs personnalisés
Amazon Cognito prend en charge les attributs personnalisés 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 quecustom: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.
Lorsque des attributs personnalisés déterminent la location, vous pouvez distribuer une seule application ou vous connecterURL. 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 MFA 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 IAM rôle de 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 OIDC réclamations ou avec Amazon Verified Permissions, cette approche peut nécessiter le moins d'efforts.
