| 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 pris en compte et les décisions basées sur un certain nombre de facteurs :
- Comment les utilisateurs vont-ils être validés - via un mécanisme externe d'authentification unique (SSO) (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 sur 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 disposent des mêmes autorisations dans les 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 dans le 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 sur 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 plutôt 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'ID utilisateur fourni pour déterminer quelles fonctionnalités sont 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. Toutefois, 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, toute autre requête liée à la sécurité utilise les informations enregistrées dans le référentiel actuel. L'avantage de cette configuration signifie 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 des utilisateurs de sécurité doivent être mises à jour manuellement dans chaque référentiel.
En utilisant les données de Référentiel partagées (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 en double en choisissant certains groupes Tableau à partager et le reste à stocker localement, la configuration exacte dépendra de l'environnement individuel .