Pré. | Proc. |
Données de référence de sécurité partagées
Lors du choix des groupes Tableau du référentiel centralisé que chaque référentiel individuel doit partager, les tableaux liés à la sécurité doivent être soigneusement étudiés et les décisions doivent être basées sur un certain nombre de facteurs :
- Comment les utilisateurs seront-ils validés - via un mécanisme d'authentification unique (SSO) externe (comme OpenID ou Windows NTLM) ou via un simple ID utilisateur et un mot de passe stockés dans le référentiel Enterprise Architect ?
- Tous les référentiels doivent-ils partager la même liste d’utilisateurs ?
- Les mots de passe des utilisateurs doivent-ils être synchronisés dans tous les référentiels ?
- Tous les utilisateurs disposent-ils des mêmes autorisations dans tous les référentiels ?
Scénario 1. Tous les référentiels ont les mêmes utilisateurs et tous les utilisateurs ont les mêmes autorisations au sein des référentiels. Le référentiel individuel doit partager les deux groupes Tableau : « Utilisateurs et groupes de sécurité » et « Autorisations de sécurité » du référentiel centralisé. La liste des utilisateurs et les autorisations devront être gérées au sein du référentiel centralisé.
Scénario 2. Tous les référentiels ont les mêmes utilisateurs, mais les utilisateurs ont des autorisations différentes selon les référentiels. Le référentiel individuel doit partager les groupes Tableau : « Utilisateurs et groupes de sécurité » du référentiel centralisé. La liste des utilisateurs devra être gérée dans le référentiel centralisé, tandis que les autorisations des utilisateurs devront être gérées dans les référentiels individuels.
Avec chacun des scénarios ci-dessus, il est toujours nécessaire que les mots de passe des utilisateurs soient conservés dans les référentiels individuels ; la seule façon d'éviter cela est d'implémenter l'authentification SSO ou d'utiliser l'authentification globale de Pro Cloud Server .
Authentification via SSO
Lors de l'utilisation d'un mécanisme d'authentification SSO, Enterprise Architect n'est plus responsable de déterminer si les informations d'identification de l'utilisateur saisies sont valides. C'est OpenID ou Windows NTLM qui valide les informations d'identification de l'utilisateur et informe Enterprise Architect que l'utilisateur donné est valide. Enterprise Architect utilise ensuite l'identifiant utilisateur fourni pour déterminer les fonctionnalités disponibles dans le référentiel actuel. Cela nécessite que la liste complète des utilisateurs soit définie dans le référentiel. Cependant, si chaque référentiel individuel est configuré pour partager les données de référence liées à la sécurité, la liste des utilisateurs (et leurs autorisations) peut être définie et gérée dans le référentiel centralisé.
Authentification via l'authentification globale
Il est possible de configurer les ports du Pro Cloud Server pour utiliser un référentiel « global » à des fins d'authentification. Lorsque cette option est définie, le processus de log initial utilise le référentiel « global » pour valider les informations d'identification de l'utilisateur fournies. Une fois ces informations d'identification confirmées, toutes les requêtes ultérieures liées à la sécurité utilisent les informations enregistrées dans le référentiel actuel. L'avantage de cette configuration est que chaque référentiel a la possibilité pour le même utilisateur d'avoir des autorisations différentes dans chaque référentiel. Cependant, l'inconvénient est que les définitions d'utilisateur de sécurité doivent être mises à jour manuellement dans chaque référentiel.
En utilisant les données Référentiel partagé (comme décrit dans la rubrique Lier les données de référence à un Référentiel partagé), il est possible de supprimer les données dupliquées en choisissant certains groupes Tableau à partager et le reste à stocker localement, la configuration exacte dépendra de l'environnement individuel.