Réserver une Démo
Pré. Proc.

Configurer OpenID

Cette fonctionnalité est disponible à partir de la version 14.1 d' Enterprise Architect .

Pour permettre aux utilisateurs de se log avec un compte OpenID, un serveur OpenID prenant en supporte la norme 'OpenID Connect' doit être disponible.

Ces paramètres seront utilisés par Enterprise Architect , Pro Cloud Server et WebEA .

Accéder

Ruban

Paramètres > Sécurité > Utilisateurs > Accepter l'authentification OpenID

Paramètres > Sécurité > Utilisateurs > Configurer OpenID

Réglages

Configuring OpenID in Sparx Systems Enterprise Architect.

Champ

Action

URL OpenID

Entrez le chemin complet vers l'URL de découverte du serveur OpenID, moins le standard " /.well-known/openid-configuration" (ceci sera ajouté automatiquement).

Incluez le protocole (http:// ou https://) et le port s'il s'exécute sur un port non standard (c'est-à-dire pas 80 ou 443).

Vous devriez pouvoir copier l'adresse avec le " /.well-known/openid-configuration" ajouté et l'ouvrir dans un navigateur et voir une réponse textuelle.

Appuyez maintenant sur le bouton Test et cliquez sur 'Connexion avec OpenID' pour ouvrir un navigateur à la bonne adresse. Si l'URL est incorrecte ou si OpenID renvoie une réponse de configuration mal formée, un message d'erreur s'affichera.

ID client

OpenID doit être configuré avec un client pour permettre à Enterprise Architect d'utiliser ses services. Entrez l' ID client ici.

Les fournisseurs OpenID vous permettront d'ajouter un nouveau client. Il est recommandé de le nommer ' Enterprise Architect ' ou ' WebEA ' ou similaire pour permettre une identification facile.

Après avoir créé un client, le fournisseur OpenID vous fournira l' ID client ou vous permettra d'en spécifier un.

Clé secrète du client - (facultatif)

Certains clients OpenID nécessitent un secret client pour sécuriser davantage les demandes. Si le client a besoin d'un secret, entrez-le ici. Il sera enregistré en tant que valeur cryptée.

Portée

Entrez les étendues OpenID requises pour renvoyer une réponse avec les informations requises. Une portée de 'openid' est obligatoire selon la norme. D'autres champs d'application courants incluent 'profil' ou 'e-mail'.

Demander à correspondre à l'utilisateur local

Entrez la demande qui sera renvoyée lors de la requête de l'OpenID « user_info » qui sera utilisé pour faire correspondre l'utilisateur OpenID à une connexion d'utilisateur modèle existante.

'Claims' sont des champs d'informations que le serveur OpenID prétend être vrais sur l'utilisateur authentifié. La plupart des serveurs OpenID permettent de personnaliser cela afin qu'il puisse être configuré pour renvoyer un champ de réclamation spécifiquement pour une utilisation avec Enterprise Architect , si vous le souhaitez.

Note : La seule revendication dont l'unicité est garantie pour un utilisateur est 'sub'. C'est le « sujet » de la réclamation. Pour les nouveaux modèles, ce serait un bon paramètre par défaut dans le champ de réclamation.

Pour les modèles existants où il y a déjà des utilisateurs dans le modèle qui doivent correspondre à OpenID, il est recommandé d'utiliser un champ 'nom d'utilisateur' quelconque. Soit le 'preferred_username', 'email' (si e-mail est utilisé, il est recommandé d'activer la validation par e-mail) ou un 'nom d'utilisateur EA' personnalisé aurait du sens dans cette situation.

Si vous utilisez une revendication autre que 'sub', il appartient au mainteneur du serveur OpenID de s'assurer que la revendication est unique et sécurisée, et de s'assurer que la revendication ne peut pas être modifiée par l'utilisateur.

Prétendre correspondre aux groupes locaux

Cette option est utilisée si le paramètre supplémentaire 'Créer ou modifier automatiquement les utilisateurs Windows ou OpenID' est activé. Il n'est pas utilisé autrement. Consultez la rubrique d'aide Options d'authentification unique (SSO) .

Entrez la demande qui sera renvoyée lors de l'interrogation de l'OpenID 'id_token' ou 'user_info' qui sera utilisé pour faire correspondre les groupes d'utilisateurs OpenID aux groupes de modèles existants.

'Claims' sont des champs d'informations que le serveur OpenID prétend être vrais sur l'utilisateur authentifié. La plupart des serveurs OpenID permettent de personnaliser cela afin qu'il puisse être configuré pour renvoyer un champ de réclamation spécifiquement pour une utilisation avec Enterprise Architect , si vous le souhaitez.

La norme OpenID ne précise rien en ce qui concerne les groupes d'utilisateurs. Certains serveurs OpenID ont cette fonctionnalité intégrée mais doivent encore être activées pour que les groupes puissent être renvoyés dans 'id_token' ou 'user_info'. Les groupes renvoyés peuvent être soit un champ JSON unique, soit un tableau JSON contenant plusieurs noms de groupe.

Connexion du Tester

Une fois tous les champs remplis, cliquez sur le bouton Test . Une fenêtre apparaîtra avec un bouton "Connexion à OpenID". Cliquez sur le bouton pour ouvrir un navigateur Web sur la page d'authentification du serveur OpenID.

Fournissez des informations d'identification valides et autorisez Enterprise Architect à accéder au compte du serveur OpenID (cela peut ou non être requis selon l'environnement OpenID).

En cas de succès, le navigateur devrait se fermer automatiquement et Enterprise Architect affichera une fenêtre de réussite avec les détails de l'utilisateur OpenID, y compris tous les groupes renvoyés et les groupes de modèles auxquels ils sont liés.

Note que les navigateurs Web mettent souvent en cache les sessions ou les informations d'identification des utilisateurs afin qu'ils ne prompt pas de connexion lors de tentatives ultérieures.

Exemple de réponse 'user_info' valide

Ceci est un exemple de réponse pour un serveur OpenID 'KeyCloak'.

Demander à correspondre à l'utilisateur local : nom d'utilisateur

Prétendre correspondre aux groupes locaux : groupes

{

"sous": "6da812c4-8f2c-400f-b602-13bab1d4605e",

"adresse": {},

"name": "Exemple de personne",

"groupes": [

"Utilisateurs spéciaux EA",

"Administrateurs EA"

],

"given_name": "Exemple",

"family_name": "Personne",

"email": "[email protected]",

"nom d'utilisateur": "eperson"

}