Configurer OpenID

Ruban

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

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

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.