Partager cette page

# Valider le fournisseur d’identité et activer le SSO

Condition préalable : Définir votre profil

Cette section décrit comment activer le SSO.

Dans cette rubrique :

## Valider un IdP

Pour activer le SSO, vous devez d’abord valider l’IdP alm.

Vous validez un IdP pour vérifier la configuration de l’IdP et la communication entre ALM SP et l’IdP.

Note : Si vous activez l’authentification locale et sélectionnez l’authentification locale comme méthode d’authentification, vous pouvez activer le SSO directement sans valider l’IdP.

Conditions préalables

Avant de valider un IdP, s’assurer que les éléments suivants sont bien en place.

- Au moins un utilisateur administrateur du site ALM est déjà mappé à un utilisateur IdP.

- Les URL ALM et IdP sont ajoutées aux URL de confiance IE.

Valider un IdP en utilisant l’assistant

Vous pouvez valider un IdP en utilisant l’Assistant de configuration SSO. Il est applicable aux environnements non-SaaS uniquement. Pour les environnements SaaS, voir Envoyer l’URL de validation aux utilisateurs de l’IdP à des fins de validation.

Pour valider un IdP en utilisant l’assistant :

1. Dans l’étape Activer le SSO, dans le champ Fournisseur d’identité, sélectionner l’IdP que vous souhaitez valider.
2. En bas de l’étape, cliquer sur Valider.

3. Sur votre page de connexion IdP, saisir votre nom d’utilisateur et votre mot de passe IdP.

4. Dans le champ Statut de validation, vérifier l’état de validation :

   Statut | Description
   --- | ---
   En attente de validation | Le statut initial de validation SSO.
   Validation réussie | La validation a réussi.
   Échec de la validation | La validation a échoué. Les détails de l’échec sont affichés sous le champ État de validation.

Envoyer l’URL de validation aux utilisateurs de l’IdP à des fins de validation

Vous pouvez copier l’URL de validation et l’envoyer aux utilisateurs de l’IdP pour une validation à distance.

Note : Dans un environnement SaaS, vous pouvez uniquement envoyer l’URL de validation aux utilisateurs IdP pour la validation SSO.

1. Dans l’étape Activer le SSO, dans le champ Fournisseur d’identité, sélectionner l’IdP que vous souhaitez valider.
2. Au bas de l’étape, cliquer sur Copier l’URL de validation.

3. Dans la boîte de dialogue Copier l’URL de validation, cliquer sur Copier et envoyer le lien aux utilisateurs de l’IdP.

   Lorsque les utilisateurs IdP ouvrent le lien, ils sont redirigés vers la page de connexion IdP. Après avoir saisi le nom d’utilisateur et le mot de passe de l’IdP, ils sont redirigés vers une page qui indique si la validation a réussi ou non ; si elle a échoué, les raisons de l’échec sont indiquées.

   Si la notification par e-mail est activée, les utilisateurs admin. du site spécifiés peuvent recevoir un e-mail indiquant qui a accédé à l’URL de validation SSO. Pour plus d’informations, voir Envoyer une notification.

Retour en haut

## Activer le SSO

Une fois l’IdP alm validé avec succès, vous pouvez activer le SSO.

Pour activer le SSO, dans le coin inférieur droit de cette étape, cliquer sur Activer le SSO.

Après avoir activé le SSO :

- Vous ne pouvez pas le désactiver.

- L’étape Activer le SSO est renommée Validation SSO, et le bouton Activer le SSO disparaît.

- Vous pouvez ajouter des IdP supplémentaires.

Retour en haut

## FAQ

Q : Après avoir validé l’IdP « alm » dans l’outil de configuration SSO, le navigateur Web m’a redirigé vers l’IdP, mais a signalé l’erreur suivante. Pourquoi ?

R :

Cause profonde : une URL de métadonnées SP incorrecte a été enregistrée dans l’IdP, de sorte que l’IdP ne peut pas reconnaître la demande SAML envoyée par ALM.

Solution: assurez-vous que les métadonnées correctes du SP peuvent être chargées depuis ALM. Par ailleurs, ALM doit être correctement enregistré comme SP dans l’IdP avant de valider l’IdP. Une fois les métadonnées SP enregistrées dans l’IdP, lors de la validation de l’IdP, vous êtes redirigé correctement vers la page de connexion de l’IdP.

Q : Pourquoi n’ai-je pas réussi à valider l’IdP alors que l’IdP a correctement renvoyé la réponse SAML à ALM ?

R :

Cause profonde : Les affirmations de réponse SAML ne contenaient pas l’affirmation requise de « Clé d’identité ».

Solution: Si l’IdP renvoie une réponse SAML, cela signifie que la relation de confiance entre l’IdP et ALM a bien été établie. Le seul problème est que l’utilisateur IdP ne peut pas être validé par ALM. Les utilisateurs ALM et les utilisateurs IdP sont mis en correspondance en utilisant les valeurs IdentiyKey. Si l’IdP ne fournit pas la valeur IdentityKey dans la réponse SAML, ALM ne peut pas faire correspondre l’utilisateur IdP à un utilisateur ALM, et donc la validation échoue.

Pour résoudre ce problème, dans l’IdP, mappez IdentityKey comme attribut SAML sur un attribut IdP qui peut identifier de manière unique l’utilisateur IdP.

Q : Comment puis-je savoir qu’une relation de confiance entre l’IdP et ALM a bien été établie ?

R : Dans le navigateur Web, saisissez l’URL du SP ALM comme ceci : `{ALM host:port}/osp/a/alm/auth/app/`. Si elle vous redirige vers la page de connexion de l’IdP et si après authentification elle vous redirige vers la page du SP sans erreur, cela signifie que le SP a reçu la réponse SAML de l’IdP : la relation de confiance entre l’IdP et ALM a bien été établie.

Q : Pourquoi n’ai-je pas réussi à me connecter à ALM via le Lanceur du client ALM après l’activation du SSO dans ALM 15.0 ?

R :

Cause profonde : Une ancienne version de Lanceur du client ALM a été utilisée.

Solution: Télécharger le dernier Lanceur du client ALM pour travailler avec la solution SSO ALM 15.x.

https://marketplace.microfocus.com/appdelivery/content/alm-client-launcher

Q : Pourquoi puis-je cliquer sur le bouton Activer le SSO même si je n’ai pas réussi à valider « l’alm » IdP ?

R : Si vous réglez Activer l’authentification locale sur OUI dans *Activer l’authentification locale, ALM authentifie les utilisateurs locaux du côté ALM et authentifie les utilisateurs IdP du côté IdP. Si vous êtes un utilisateur local ALM, ALM vous permet d’activer le SSO même si l’IdP « alm » ne réussit pas la validation car, dans ce cas, vous avez toujours la possibilité de vous connecter à ALM en tant qu’utilisateur local pour corriger la configuration IdP afin que les utilisateurs IdP puissent se connecter à ALM.

Q : Si certains problèmes provoquent l’échec de l’authentification SSO et que je ne peux pas ouvrir l’outil de configuration SSO, que dois-je faire ?

R : Nous vous recommandons d’activer l’authentification locale afin que, une fois le SSO activé, les utilisateurs locaux puissent toujours se connecter à ALM pour résoudre les problèmes de configuration du SSO.

Q : Est-ce que je vais perdre mon compte local après l’activation du SSO ?

R : Depuis la version 15.0.1, une fois le SSO activé, tous les utilisateurs sont authentifiés soit par l’authentification SSO, soit par l’authentification locale.

Les comptes locaux sont toujours conservés dans ALM après l’activation du SSO. Pour être authentifié, chaque compte local doit remplir l’une des deux conditions suivantes :

- Chaque utilisateur local est associé à un utilisateur IdP.
- Chaque utilisateur local est configuré en tant qu’utilisateur local ALM et l’authentification locale est activée.

Q : Puis-je contourner le partenariat fédéré et me connecter directement à ALM ?

R : ALM 15.0.1 et les versions ultérieures prennent en charge l’authentification locale. Lorsque l’authentification locale est activée, l’administrateur du site peut configurer un utilisateur en tant qu’utilisateur local d’ALM en spécifiant son IdP ID comme « local » : ces utilisateurs locaux peuvent se connecter directement à ALM.

Q : Après l’activation du SSO, qu’adviendra-t-il des projets créés et consultés avant l’activation du SSO ?

R : Il n’y a pas d’impact sur les données du projet. L’authentification SSO ne modifie que la gestion des utilisateurs.

Q : Si j’utilise QC/ALM depuis des années, ai-je toujours accès aux mêmes ressources qu’auparavant ?

R : Le passage en mode SSO ne modifie pas les noms d’utilisateur des utilisateurs existants. Ils peuvent toujours accéder aux mêmes ressources que lorsque ALM s’exécute en mode non SSO.

Ils sont simplement mis en correspondance avec les utilisateurs IdP correspondants. Le tableau UTILISATEURS comporte 2 colonnes supplémentaires : US_IDENTITY_KEY et US_IDPID_NAME pour conserver les informations de mappage de chaque utilisateur.

Q : Lorsque j’essaie d’accéder à ALM 15.0 après m’être authentifié dans IdP, pourquoi le navigateur Web signale-t-il « 431 champs d’en-tête de demande trop grands » ?

R : Lorsque ALM 15 fonctionne en mode SSO, certaines sessions IdP et SP supplémentaires sont ajoutées au cookie des requêtes HTTP, ce qui rend la taille de l’en-tête de la requête beaucoup plus importante que lorsqu’ALM fonctionne en mode non SSO. Si le proxy inverse ou l’ALM de l’utilisateur a restreint la taille de l’en-tête de la requête pour qu’elle soit inférieure à la taille réelle, ce problème se produit.

Pour résoudre ce problème, modifiez les paramètres d’ALM Jetty afin d’augmenter la taille de l’en-tête de la demande. Taille recommandée : 81920. Pour en savoir plus sur la façon de configurer « requestHeaderSize » des connecteurs Jetty, consultez la documentation Jetty.

Si le proxy inverse restreint également la taille de l’en-tête de la demande, demandez à l’administrateur réseau de modifier cette taille.

Q : Comment modifier manuellement les fichiers de configuration du SSO si le dossier du référentiel ALM change après l’activation du SSO ?

R : Pour modifier manuellement les fichiers de configuration du SSO :

1. Dans le fichier `qcConfigFile.properties` situé dans `{dossier_installation}`, mettez à jour la valeur de « repositoryPath » pour le nouveau dossier de référentiel.

2. Dans le fichier `wrapper.conf` situé dans `{deployment_folder}/wrapper`, mettez à jour la valeur de « wrapper.java.additional.34 » comme suit :

   `wrapper.java.additional.34=-Dalm.osp.framework.generic-properties-filename="{New ALM repository}/sa/DomsInfo/osp/basic.properties"`

3. Dans le fichier `basic.properties` situé dans `{dossier du référentiel du projet}`, mettez à jour la valeur de « oauth-keystore.file » comme suit :

   `oauth-keystore.file={New ALM repository}\\sa\\DomsInfo/osp/basic.pfx`

4. Dans le fichier `ospcfg.xml` situé dans `{dossier du référentiel du projet}`, mettez à jour la valeur de name="propertiesFile" comme suit :

   `<NamedValue value="{New ALM repository}\sa\DomsInfo/osp/alm.properties" name="propertiesFile"/>`

5. Exécuter Configurer le fournisseur de services et Configurer le fournisseur d’identité dans l’Outil de configuration SSO.

Note : Pour plus de détails sur la façon de modifier le référentiel ALM, voir Comment déplacer le référentiel de domaine d’un emplacement à un autre lors de l’utilisation de TD for QC.

Q : Une fois le SSO activé, si je me connecte à ALM en utilisant Chrome ou Edge (version 86 et ultérieure), je suis redirigé vers la page de connexion IdP. Une fois connecté à l’IdP, Chrome ou Edge continue de me rediriger entre ALM et IdP.

R : Modifiez le paramètre de sécurité dans Chrome ou Edge :

1. Saisissez « chrome://flags/ » dans Chrome ou « edge://flags/ » dans Edge.
2. Recherchez le mot clé « SameSite by default cookies ».

3. Pour Chrome : Réglez les options Cookies sans SameSite doit être sécurisé et Cookies par défaut de SameSite sur Désactivé.

   Pour Edge : Définissez les options Cookies par défaut de SameSite et Schemeful Same-Site sur Désactivé.

Retour en haut

https://admhelp.microfocus.com ALM 8942
Conseils pour améliorer vos résultats de recherche... ALM Help Center ALM Help Center Aide ALM 17.0 Tout Afficher le centre d’aide local Afficher le centre d’aide en ligne arrière Revenir en arrière dans l’historique de navigation avant Avancer dans l’historique de navigation Désactiver la mise en surbrillance dans les résultats de recherche rubrique suivante Atteindre la rubrique suivante rubrique précédente Atteindre la rubrique précédente Imprimer la rubrique actuelle Version :