Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cette section décrit les considérations à prendre en compte lorsque vous stockez des données de profil utilisateur dans l’annuaire utilisateur. Recherchez les considérations relatives à la conception pour les attributs à stocker dans l’ID Microsoft Entra. Découvrez comment gérer la résidence des données et les exigences de conformité.
Répertoire utilisateur
Un modèle utilisateur est un schéma logique pour un enregistrement utilisateur. Le modèle contient des attributs que les administrateurs d’annuaire et les propriétaires d’applications acceptent de stocker dans l’annuaire. Il s’agit de la source faisant autorité pour chacune d’elles : collectée à partir d’utilisateurs, et non interrogée à partir d’un système externe.
Les revendications nécessaires à l’authentification peuvent inclure des données confidentielles et sensibles stockées dans une source externe, comme une gestion des relations client (CRM) ou un système d’enregistrement d’intégrité électronique (EHR). Le stockage de ces données dans le répertoire pour l’authentification n’est pas obligatoire. Au lieu de cela, il est récupéré à l’aide d’un appel d’API RESTful avec les extensions d’authentification personnalisées Microsoft Entra ID. Dans le jeton, il est émis en tant que revendications.
Sélection des attributs
Le tableau suivant contient des attributs pour définir votre modèle utilisateur et dans quels scénarios les utiliser.
Catégorie | Scénarios |
---|---|
Attributs intégrés du répertoire | - Valeurs persistantes et stockées dans le répertoire - Nom et type explicites - Disponible dans la liste par défaut des attributs - Si ce n’est pas disponible, les valeurs d’attribut sont définies administrativement |
Attributs des utilisateurs clients | - Valeurs persistantes et stockées dans le répertoire - Aucun attribut intégré disponible - Les exigences de type de données sont suffisantes |
Extensions personnalisées | - Valeurs persistantes et stockées dans un magasin CRM ou externe : les valeurs sont extraites d’une source externe pendant l’authentification, à l’aide d’un gestionnaire d’événements - La valeur extraite est émise sur le jeton. |
Le diagramme suivant illustre la façon dont les options du tableau précédent s’intègrent dans un flux utilisateur.
Attributs dans le répertoire utilisateur
L’ID externe Microsoft Entra a des attributs par défaut pour les objets utilisateur. Lorsque le modèle utilisateur est requis, vous pouvez créer des attributs d’extension.
Pour utiliser les attributs d’extension d’ID externe Microsoft Entra, une extension de schéma est appliquée à votre répertoire. Les extensions sont associées à un objet d’application, puis peuvent être utilisées comme attribut pour tous les objets utilisateur d’annuaire et pour toutes les applications. L’objet d’application par défaut pour étendre le schéma est l’application b2c-extensions-app, qui est approvisionnée avec votre répertoire, par défaut.
Lorsque vous définissez l’attribut d’extension, le nom stocké dans le répertoire suit le format : extension_GUID_Name. Le GUID est l’ID d’application de l’objet d’application, sur lequel l’extension de schéma est inscrite. Cette valeur est spécifique au répertoire. La capture d’écran suivante montre l’application b2c-extensions-app, son ID d’application et le nom d’attribut retourné par l’API Microsoft Graph.
GET : Propriétés de l’extension
"value": [</br>
{</br>
"id": "b7271a2b-a03e-48f7-abf0-54d21427987a",</br>
"deletedDateTime": null,</br>
"appDisplayName": "",</br>
"dataType": "String",</br>
"isMultiValued": false,</br>
"isSyncedFromOnPremises": false,</br>
"name": "extension_8beb06b77e314e2393cc5453a6a56756_lastName",</br>
"targetObjects": [</br>
"User"</br>
]</br>
}
Les formats de données pris en charge sont les suivants :
- Chaîne (56 caractères maximum)
- Booléen
- Entier (valeur 32 bits)
Gérez les extensions d’annuaire via le Centre d’administration Microsoft Entra ou avec l’API Microsoft Graph.
Migration des données utilisateur
Lors de la migration vers l’ID externe Microsoft Entra, tenez compte des clés primaires, des clés étrangères (ou des clés de jointure) ou des attributs utilisés par les systèmes d’identité et les applications pour la compatibilité. Par exemple, les ID d’objet provenant de systèmes d’identité hérités, émis en tant qu’identificateurs de sujet ou de nom persistants dans les jetons. En outre, un exemple est d’autres attributs d’annuaire utilisés comme identificateurs uniques par les systèmes intégrés : adresses e-mail, noms d’ouverture de session courts, ID CRM et ID de système de gestion des commandes. Pour servir à deux fins, conservez ces valeurs :
- Historique d’audit : lors de l’examen des activités, reportez-vous aux journaux archivés du système hérité. Une clé de jointure entre les systèmes facilite ce scénario. Aidez à répondre aux exigences de conformité telles que :
- Fonction continue des systèmes intégrés : la migration peut impliquer la consolidation des systèmes d’identité qui utilisent différents identificateurs principaux. Conservez les identificateurs pour activer la configuration des formes de jeton spécifiques à l’application avec les identificateurs de sujet ou de nom appropriés. Les applications fonctionnent comme prévu. Exemple : un système de gestion des commandes affiche les achats passés pour l’utilisateur, après la migration.
Documentez les informations pour éviter les problèmes potentiels ultérieurement. Établissez un dictionnaire d’attributs pour les développeurs d’applications actuels et futurs. Dans le tableau suivant, il s’agit d’un exemple.
Nom de l’attribut | Catégorie | Type de données | Source de données ou propriétaire | Utiliser |
---|---|---|---|---|
Intégré ou personnalisé | Chaîne, int, etc. | À partir d’un utilisateur ou d’un ensemble d’administrateurs | Applications ou audit |
Incluez des informations sur la source d’autorité, également qui, quoi, quand et comment les attributs sont mis à jour.
Important
Toutes les données d’application ne appartiennent pas au répertoire. Pour une plus grande échelle, les mises à jour continues et la synchronisation des données présentent des défis et peuvent entraîner des résultats imprévisibles.
Conception
Dans cette section, découvrez les aspects de la conception : affectation de noms et conventions, architecture de référence, modèles d’intégration, etc.
Conventions d’affectation de noms
L’utilisation des normes et conventions d’annuaire rend la structure d’annuaire facilement comprise. Cette approche s’applique aux applications de nommage, aux utilisateurs, aux attributs, etc.
Architecture de référence et modèles d’intégration
Documenter les décisions et les modèles d’intégration afin que les équipes d’applications puissent être indépendantes et cohérentes. Incluez des détails organisationnels tels que des principes de conception, des architectures d’intégration, des diagrammes de séquence et de flux de données, des sources de données, des stratégies de rétention, des normes de sécurité, etc.
Si possible, reportez-vous à la documentation du produit plutôt que de dupliquer le contenu dans la documentation de référence. Les exemples d’applications sont prouvés comme des accélérateurs pour les développeurs et les intégrateurs.
Administration
Dans l’ID Microsoft Entra, si un autre administrateur ou non administrateur doit gérer les ressources Microsoft Entra, attribuez-leur un rôle Microsoft Entra avec les autorisations dont ils ont besoin.
En savoir plus sur les rôles intégrés Microsoft Entra.
Bien qu’il n’existe aucune restriction aux attributions de rôles d’utilisateur dans l’annuaire des identités externes, nous vous recommandons d’inviter des comptes d’administration à partir de l’annuaire des employés de l’entreprise.
Remarque
Il existe un objectif futur d’inclure une fonctionnalité de gestion des identités privilégiées dans Microsoft Entra External ID.
Opérations de données d’annuaire
Les données d’annuaire incluent les objets stockés dans l’annuaire, tels que les utilisateurs, les applications et les principaux de service.
Remarque
Microsoft sauvegarde régulièrement les données d’annuaire et est disponible pour la restauration de Microsoft.
Le répertoire crée des valeurs lors de la création d’objets, telles que des ID d’objet et d’application. Ils ne peuvent pas être dupliqués ou recréés avec les mêmes valeurs.
Vous pouvez restaurer ou supprimer définitivement les utilisateurs récemment supprimés.
Pour les objets pertinents pour les identités externes, telles que les utilisateurs, les groupes et les principaux de service, consultez récupérer des suppressions dans l’ID Microsoft Entra.
Nous recommandons tous les travaux de traitement par lots qui traitent les données d’annuaire, pour les tâches de maintenance ou de synchronisation, de générer des journaux d’activité en plus des journaux d’audit générés par le système. Inspectez-les après l’opération de traitement par lots.
Conformité
Rassemblez les exigences de conformité auxquelles le répertoire est soumis. Basez ces informations sur les marchés des opérations. Dans certaines industries ou dans la région des pays d’exploitation, ces détails peuvent changer.
Pour plus d’informations, consultez la documentation de conformité Azure.
Bien que la plateforme respecte certaines normes, l’opérateur est responsable de l’entretien des données d’annuaire et de la conformité des clients. Par exemple, les produits Microsoft Entra sont conformes au Règlement général sur la protection des données (RGPD) et disposent d’API pour les opérations d’annuaire. Par conséquent, Microsoft est le processeur de données. Le propriétaire du répertoire dans le rôle Contrôleur fournit à l’utilisateur une option d’oubli. Le propriétaire exécute l’API pour supprimer l’utilisateur du répertoire.
Collecter les exigences de conformité et impliquer des équipes juridiques. Le tableau suivant est un outil d'aide au recueil des besoins.
Paramètre | Conformité et exigences |
---|---|
Pays ou région de l’opération 1 | |
Pays ou région de l’opération 2 | |
Industrie | |
Autorité réglementaire |
Utilisez ces informations pour vérifier les données stockées dans le répertoire et sa configuration. Les informations peuvent se rapporter aux attributs du répertoire. Reconnaissez que certaines combinaisons d’attributs, telles que le prénom, le nom de famille et la ville, peuvent se trouver dans les limites de conformité. De plus, ce scénario peut s’appliquer aux exigences de rétention et de chiffrement des journaux spécifiées dans la configuration. Documenter les exigences de configuration spécifiques pour aider à maintenir la configuration. Les exigences de conformité évoluent plus rapidement en réponse aux cybermenaces, aux changements politiques et sociaux. Utilisez l’aide de travail suivante.
Configuration du locataire | Informations de référence sur la conformité |
---|---|
Rétention des logs | |
Configuration de chiffrement | |
Stockage d’attributs | |
Séparation des tâches | |
Complexité du mot de passe | |
... |
Remarque
Lors de l’interprétation des exigences de conformité et de configuration, consultez les équipes juridiques et de conformité pour obtenir des conseils et un consensus.
Limites du service
Les points de terminaison de locataire de l’ID externe Microsoft Entra sont soumis à des limites de limitation, ce qui limite les appels simultanés et empêche l’utilisation excessive des ressources. Cela permet de protéger les produits et services Microsoft fournis à tous les clients.
Le tableau suivant répertorie les principaux scénarios et composants de service pour la conception de solutions avec l’ID externe Microsoft Entra.
Scénario | Composant | Conseils sur la limitation |
---|---|---|
Tâches d’administration effectuant des tâches de création, de lecture, de mise à jour et de suppression (CRUD) sur des locataires d’ID externe Microsoft Entra, telles que des flux d’utilisateurs ou des objets | Microsoft Graph API |
-
Conseils sur la limitation de Graph - Restrictions de service de Graph |
S’inscrire, se connecter et réinitialiser le mot de passe avec les flux utilisateur | ID externe Microsoft Entra | Limites du service d’ID externe Microsoft Entra |
L’API Microsoft Graph a différents types de limites et quotas associés. La priorité de mise en œuvre la plus élevée est l'application + le locataire, et la priorité la plus faible est le locataire. Étant donné que Microsoft Entra External ID ne prend pas en charge les applications mutualisées, la limite par application ne s’applique pas.
Par exemple, une application + locataire atteint sa limite de quota avant que le quota de locataire soit atteint. Cette action permet à d’autres applications de communiquer avec le locataire.
Avec des opérations de répertoire à grand volume telles que la migration utilisateur, augmentez le débit à l’aide des opérations par lots et de six enregistrements d’applications au maximum pour effectuer des opérations Microsoft Graph.
Cette approche peut dépasser les limites de restriction des locataires. Lorsque les applications atteignent des limites, elles ne peuvent pas interagir avec le répertoire, ce qui peut entraîner l’échec d’autres charges de travail. Faites attention quand plusieurs applications augmentent le débit d’une charge de travail.
Remarque
Certains types de ressources d’API Microsoft Graph peuvent avoir des limites de limitation plus strictes et différentes pour la sécurité. Ouvrez un ticket de support avec le support Microsoft pour planifier les atténuations au cas par cas.
Étapes suivantes
Utilisez les articles suivants pour vous aider à prendre en main un déploiement d’ID externe Microsoft Entra :