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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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é.