Plus d’informations sur l’authentification unique basée sur OIDC
Dépannage du backend OIDC basé sur un service Windows
Pour ce faire, exécutez toute commande avec le MemoQ.Security.Oidc.ConfigTool. Le plus sûr est GetBackendBaseUrl, car cela ne change rien dans la configuration.
Dans une invite de commande avec des droits d’administrateur, exécutez ces commandes:
cd "%PROGRAMFILES%\Kilgray\MemoQ Server\Oidc"
MemoQ.Security.Oidc.Backend.ConfigTool.exe GetBackendBaseUrl
Après que l’invite de commande a retourné, la mise à jour de la base de données est terminée.
Cela est causé par un problème connu du cadre .NET. Les fichiers exe dans le dossier %PROGRAMFILES%\Kilgray\MemoQ Server\Oidc sont des archives auto-extractibles. Leurs contenus (les programmes réels) sont extraits dans (et exécutés à partir de) un sous-dossier du dossier %TEMP% de l’utilisateur. Il peut arriver que quelque chose (par exemple, un logiciel antivirus, une mise à jour de .NET, etc.) nettoie le dossier %TEMP % , après quoi le serveur principal OIDC et son outil de configuration ne peuvent plus s’exécuter.
Pour éviter cela: Créez une variable d’environnement appelée DOTNET_BUNDLE_EXTRACT_BASE_DIR, avec une étendue Machine ou Système. Définissez sa valeur à %PROGRAMDATA %\Temp\.net. Redémarrez ensuite le service principal OIDC0 : Exécutez la commande services.msc, faites un clic droit sur le service MemoQ OIDC Backend dans la liste, et dans le menu, cliquez sur Démarrer.
S’il y a un problème avec votre connexion OIDC, parcourez cette liste avant de contacter le soutien de memoQ.
-
Exécutez MemoQ.Security.Oidc.Backend.ConfigTool.exe, situé dans le dossier %PROGRAMFILES%\Kilgray\MemoQ Server\Oidc pour vous assurer que la partie OIDC dans la base de données de memoQ TMSest à jour (l’exécution du ConfigTool effectue automatiquement la mise à jour).
-
Exécutez MemoQ.Security.Oidc.Backend.ConfigTool.exe avec la commande GetIdProvider pour lister les fournisseurs d’identité configurés. C’est très utile si la page de connexion de memoQwebne montre pas les boutons OIDC ou si l’option Utiliser un fournisseur d’identité externe est désactivée dans l’application de bureau memoQ. Ces éléments ne devraient pas se produire si vous avez au moins un fournisseur d’identité configuré.
-
S’il y a des problèmes avec la page de connexion de memoQweb, exécutez MemoQ.Security.Oidc.Backend.ConfigTool.exe avec la commande GetMemoQWebBaseUrls. Vérifiez si l’URL de base de memoQweb est configurée correctement.
-
Ouvrez la base de données du memoQ TMSdans Microsoft SQL Server Management Studio et vérifiez si elle a une table appelée dbo.__EFMigrationsHistory. Si ce n’est pas le cas, vous devez installer la partie OIDC de la base de données: exécutez MemoQ.Security.Oidc.Backend.ConfigTool.exe avec la commande GetMemoQWebBaseUrls. Cela est nécessaire pour éviter les problèmes de CORS sur le serveur principal OIDC lorsqu’il est utilisé à partir de memoQweb. Vous devez ensuite configurer OIDC (en tant que service Windows), comme décrit dans la documentation concernant la fenêtre « Configurer l’authentification unique OIDC ». Notez que vous pouvez avoir plusieurs URL de base configurées ici.
-
Vérifier quels fournisseurs d’identité OIDC sont configurés sur memoQ TMS : Ouvrez https://<lenom d’hôte du serveurprincipalOIDC>:<le port du serveur principalOIDC>/auth/id_providers (par exemple, https://memoqserver.mycompany.com:5001/auth/id_providers) dans un navigateur. memoQ TMS renvoie un fichier JSON contenant les données de base des fournisseurs d’identité configurés.
-
Vérifier les possibilités de signature OIDC sur memoQ TMS : Ouvrez https://<nom d’hôtedu serveur principalOIDC>:<portdu serveur principal OIDC>/login (par exemple, https://memoqserver.mycompany.com:5001/login) dans un navigateur. memoQ TMS renvoie la partie OIDC de la page de connexion.
Migrer les utilisateurs de l’OSS Windows vers la nouvelle solution basée sur OIDC
Les utilisateurs peuvent migrer leurs comptes du SSO Windows vers le compte basé sur OIDC. Cela se produit de la même manière qu’avec memoQ TMS comptes:
-
Les utilisateurs se connectent au memoQ TMS avec leur compte OIDC.
-
Ils choisissent l’option J’ai déjà travaillé sur ce serveur lorsqu ’on leur demande, et saisissent leur nom d’utilisateur et mot de passe AD Windows.
-
memoQ TMS lie les deux comptes, et par la suite, les utilisateurs ne peuvent se connecter qu’avec leur compte OIDC.
Les utilisateurs qui passent à un fournisseur OIDC conservent leurs précédents droits d’accès et membres de groupe. Lorsqu’un administrateur de memoQ synchronise memoQ TMS avec Windows Active Directory, les membres du groupe de ces utilisateurs seront mis à jour.
Si l’organisation conserve le SSO Windows même après avoir mis en place le SSO basée sur OIDC, vous pouvez migrer un utilisateur vers le système basé sur Windows. Supprimer leur compte dans memoQ ou memoQweb, puis synchroniser votre memoQ TMS avec Windows Active Directory. Le compte apparaîtra à nouveau dans la liste des utilisateurs en tant qu’utilisateur Windows AD.
Schéma général de l’authentification utilisateur basée sur OIDC
La nouvelle façon d’approuver l’identité des utilisateurs est basée sur le protocole OpenID Connect, qui est soutenu par les principaux fournisseurs d ’identité, également connus sous le nom de systèmes d’identité et de gestion d’accès (IAM). Ces schémas montrent comment le flux d’authentification de l’utilisateur se déroule dans l’application de bureau memoQ et dans memoQweb.
- Dans memoQ, l’utilisateur choisit de se connecter avec un fournisseur d’identité externe (Okta, Azure AD, etc.)
- L’application de bureau memoQ demande et obtient l’URL de la page de connexion du serveur principal OIDC (pour choisir un fournisseur d’identité).
- L’application de bureau memoQ génère un identifiant de connexion aléatoire pour identifier la session de connexion. Il ouvre l’URL de connexion (reçue à l’étape 2) dans le navigateur par défaut de la machine et transmet le hachage de l’ID de connexion généré à la page de connexion. Cette page est diffusée par le serveur principal OIDC sur HTTPS.
- Sur la page de connexion, l’utilisateur choisit un fournisseur d’identité. La fonction de connexion du serveur principal OIDC transmet le hachage de l’identifiant de connexion et le nom du fournisseur d’identité. En réponse, il reçoit une réorientation vers la page de connexion du fournisseur d’identité, avec le hachage d’identifiant de connexion et un chemin de rappel comme paramètres.
- Le navigateur est redirigé vers le fournisseur d’identité, transmettant le hachage de connexion et le chemin de rappel en tant que paramètres.
- Le fournisseur d’identifiant authentifie l’utilisateur et génère un code d’authentification. Ensuite, il redirige le navigateur vers le chemin de rappel et transmet le code d’authentification généré.
- Le navigateur est redirigé vers le chemin de rappel et transmet le hachage de l’identifiant de connexion ainsi que le code d ’authentification au serveur principal OIDC en tant que paramètres.
- Le backend OIDC appelle le fournisseur d’identité pour échanger le code d’autorisation reçu contre un jeton d’identité. Cela se fait par une communication back-canal plus sûre.
- Le serveur principal OIDC reçoit et valide le jeton d’identification reçu, qui contient les revendications de l’utilisateur (les détails de l’utilisateur authentifié), puis l’enregistre dans la base de données de memoQ en utilisant le jeton d’identification comme clé de l’enregistrement.
- L’application de bureau memoQ envoie l’ID de connexion au memoQ TMS, et demande une session memoQ.
- Le memoQ TMS crée un hachage à partir de l’ID de connexion et essaie d’obtenir le jeton d’ID basé sur ce hachage. S’il réussit, il crée une session memoQ pour l’utilisateur authentifié du jeton d’identité.
Le flux de connexion de memoQweb suit la même logique que le bureau:
- L’utilisateur ouvre memoQweb (pratiquement, le module de connexion central sur le Web) pour travailler dans webtrans ou webPM. L’écran de connexion affiche la liste des fournisseurs d’identité enregistrés sous le formulaire de connexion traditionnel de memoQ.
- Sur la page de connexion, l’utilisateur choisit un fournisseur d’identité. Le client web génère un identifiant de connexion aléatoire pour identifier la session de connexion.
- Le navigateur est redirigé vers le fournisseur d’identité, transmettant le hachage de connexion et le chemin de rappel en tant que paramètres.
- Le fournisseur d’identifiant authentifie l’utilisateur et génère un code d’authentification. Ensuite, il redirige le navigateur vers le chemin de rappel et transmet le code d’authentification généré.
- Le navigateur est redirigé vers le chemin de rappel et transmet le hachage de l’identifiant de connexion ainsi que le code d ’authentification au serveur principal OIDC en tant que paramètres.
- Le backend OIDC appelle le fournisseur d’identité pour échanger le code d’autorisation reçu contre un jeton d’identité. Cela se fait par une communication back-canal plus sûre.
- Le serveur principal OIDC reçoit et valide le jeton d’identification reçu, qui contient les revendications de l’utilisateur (les détails de l’utilisateur authentifié), puis l’enregistre dans la base de données de memoQ en utilisant le jeton d’identification comme clé de l’enregistrement.
- L’ memoQweb interface envoie l’ID de connexion au memoQ TMS, et demande une session memoQ.
- Le memoQ TMS crée un hachage à partir de l’ID de connexion, et essaie d’obtenir le jeton d’ID basé sur ce hachage. S’il réussit, il crée une session memoQ pour l’utilisateur authentifié du jeton d’identité.
Identifier l’utilisateur dans la base de données des utilisateurs de memoQ
- Si l’utilisateur est trouvé dans la base de données des utilisateurs, le flux d’autorisation normal de memoQ commence, et l’utilisateur obtient sa licence et ses droits d’accès (c’est-à-dire qu’il est connecté).
- Si l’utilisateur n’est pas trouvé, cela signifie que c’est la première fois qu’il essaie de se connecter avec ces identifiants IDP. Selon que l’utilisateur a déjà travaillé ou non sur ce memoQ TMS, le serveur principal OIDC créera un nouvel utilisateur pour cette personne ou mettra à jour l’ancien(voir les détails plus loin).
Conseils pour environnements de test
Il y a deux choses qui peuvent simplifier l’installation SSO, mais qui ne devraient pas être utilisées dans les environnements de production. Cependant, lorsque vous essayez cette fonction pour la première fois, vous pourriez vouloir passer plus rapidement par la configuration.
Dans un environnement de test, vous pouvez utiliser un certificat auto-signé au lieu d’un certificat commercial.
- Téléchargez, décompressez et exécutez le fichier script CreateAndInstallSelfSignedCert.ps1 en mode administrateur. Cette étape créera un certificat auto-signé, l’enregistrera en tant que certificat approuvé et l’exportera dans un fichier .pfx protégé par mot de passe dans le dossier actuel.
- Ouvrez l’application Gérer les certificats d’ordinateur et dans les nœuds Certificats - Ordinateur local/Personnel/Certificat et Certificats - Ordinateur local/Autorités de certification racines de confiance/Certificat, vous devriez voir le certificat nouvellement créé.
- Modifiez le fichier appsettings.json, définissez la propriété Kestrel.Certificates.Default.Subject sur la valeur utilisée précédemment comme <nom dns pour le certificat>.
Sur chaque ordinateur client où quelqu’un utilisera l’application de bureau memoQ ou memoQweb, vous devez enregistrer le certificat comme étant de confiance:
- Copiez le fichier de certificat créé sur l’ordinateur de serveur vers l’ordinateur client.
- Double-cliquez sur le fichier et l’assistant d’importation de certificat s’ouvrira.
- Sélectionnez utilisateur actuel comme emplacement de stockage et cliquez sur Suivant.
- Cliquez sur Suivant de nouveau.
- Entrez le mot de passe du fichier de certificat (celui que vous avez défini lors de l’exportation du certificat), puis cliquez sur Suivant.
- Cliquez sur Suivant de nouveau.
- Cliquez sur Terminer.
Si vous devez utiliser le serveur principal OIDC sur la machine serveur avec des certificats autosignés, vous devez également effectuer cette procédure sur la machine serveur à partir de l’étape 2.
Dans un environnement de test, vous pouvez utiliser un fichier de certificat au lieu d’un magasin de certificat.
Kestrel au début du fichier %PROGRAMDATA%\memoQ Server\Oidc Backend\appsettings.json par ceci:
"Kestrel": {
"Certificates": {
"Default": {
"Path": "<absolute-path-of-certificate-file>",
"Password": "",
},
},
},
Accordez au serveur principal OIDC un accès en lecture à ce certificat :
- Ouvrez le dossier qui contient le fichier PFX.
- Faites un clic droit sur le certificat. Dans le menu contextuel, choisissez Propriétés.
- Dans la fenêtre des propriétés du<certificat> , cliquez sur l’onglet Sécurité, puis cliquez sur le bouton Modifier.
- Dans la fenêtre des droits d’accès pour <certificat>, cliquez sur le bouton Ajouter.
- Dans la fenêtre Sélectionner des utilisateurs..., entrez le nom du service Gestionnaire d’authentification (si nécessaire, exécutez
services.mscpour voir la liste de tous les services), et cliquez sur le bouton Vérifier les noms. - Lorsque Windows reconnaît le nom du service, cliquez sur le bouton OK.
- Dans la fenêtre des droits d’accès pour les clés privées de <certificat> , cliquez sur le nom du service. Assurez-vous que le service n’a que le droit d’accès en lecture, puis cliquez sur le bouton OK.