Dépannage de l’authentification fédérée Sitecore / Blogs / Perficient

Introduction

Dans ce blog, nous explorerons le dépannage de l’authentification fédérée Sitecore. J’ai utilisé Azure AD B2C comme fournisseur d’identité dans mon guide d’intégration, vous pouvez consulter ici Authentification fédérée Sitecore avec flux d’utilisateurs Azure Ad B2C. Toutefois, la plupart de ces problèmes ne sont pas spécifiques au fournisseur d’identité. Lorsque vous travaillez sur l’authentification fédérée, il y a de fortes chances que vous échouiez dès votre première tentative et que vous soyez potentiellement confronté à certains des problèmes décrits dans cet article de blog. Pour rendre votre configuration d’authentification simple et fluide, voici quelques-unes des erreurs les plus courantes et des solutions pour les corriger.

La définition du manifeste de l’assembly localisé ne correspond pas à la référence de l’assembly

Étant donné que l’implémentation du processeur des fournisseurs d’identité nécessite l’ajout de références à différents assemblys comme

• Sitecore.Owin
• Sitecore.Owin.Authentification
• Microsoft.Owin
• Microsoft.IdentityModel.Protocols.OpenIdConnect
• Microsoft.Owin.Security.OpenIdConnect
• Modèle d’identité

vous pourriez rencontrer une erreur indiquant que la version des assemblys référencés est introuvable ou ne correspond pas à la version référencée.

Le problème:

Étant donné que la distribution Sitecore est livrée avec son propre serveur d’identité, elle fait déjà référence à certains de ces assemblages de certaines versions. Par exemple, mon instance de développement local Sitecore 10.3 fait référence à IdentityModel.dll version 3.10.10, mais le dernier package NuGet est la version 6.2 au moment de la rédaction de cet article de blog. L’installation de la dernière version entraînera l’apparition de cette erreur.

La solution:

Vous devez vérifier la version d’assembly spécifique sur votre instance Sitecore en cours d’exécution et vous assurer d’ajouter la même version comme référence dans votre projet. Pour vérifier à quelle version votre Sitecore fait référence, vous pouvez ouvrir le Web.config et rechercher votre assembly problématique par son nom. Pour vérifier la version d’assembly du fichier réel dans votre instance en cours d’exécution, vous pouvez utiliser cette commande PowerShell. Accédez au dossier bin et exécutez cette commande :

Get-Item .\IdentityModel.dll | Select-Object Name,@{n='FileVersion';e={$_.VersionInfo.FileVersion}},@{n='AssemblyVersion';e={[Reflection.AssemblyName]::GetAssemblyName($_.FullName).Version}}

NOTE: Si vous utilisez des conteneurs Docker, vous pouvez d’abord ouvrir votre conteneur en cours d’exécution et y vérifier les versions d’assembly à l’aide de la même commande PS.

Configuration et topologie Sitecore

Étant donné que nous utilisons l’authentification fédérée pour authentifier les utilisateurs pour l’instance Content Delivery, pour les environnements dans lesquels vous disposez d’une topologie XP Scaled et d’instances CM et CD distinctes, vous devez activer la configuration d’identité uniquement pour le rôle ContentDelivery. Dans les cas où votre topologie est XP unique, vous devrez également activer la configuration de l’identité pour le rôle ContentManagement.

Le problème:

L’activation de la configuration de l’authentification fédérée pour ContentManagement pourrait entraîner la redirection de vos auteurs de contenu vers la page de connexion Azure AD B2C au lieu de la page de connexion du serveur d’identité de Sitecore. La documentation de Sitecore recommande d’utiliser les URL /sitecore et /sitecore/admin pour accéder à Sitecore. Dans mon cas, cela résout https://aip.sc/sitecore et https://aip.sc/sitecore/admin et les deux options redirigent vers Azure AD B2C.

La solution:

Pour éviter cela, veillez à utiliser des fichiers de configuration spécifiques à l’environnement pour empêcher l’application du correctif de configuration d’identité sur les instances CM de l’environnement supérieur. Si vous devez toujours activer la configuration d’identité pour le rôle ContentManagement, le moyen le plus sûr d’accéder à Sitecore est d’utiliser l’URL https://aip.sc/sitecore/login. L’utilisation de l’ancienne page de connexion devrait également fonctionner pour vous https://aip.sc/sitecore/login?fbc=1

Si vous souhaitez trouver plus d’informations sur les modifications d’authentification qui affectent la page de connexion de Sitecore, vous pouvez vous référer à ce lien : https://doc.sitecore.com/xp/en/developers/103/sitecore-experience-manager/understanding-sitecore-authentication-behavior-changes.html

Redirection vers http au lieu de https

Le problème:

Lorsque vous démarrez le processus d’authentification et que vous vous authentifiez avec succès, vous êtes redirigé vers la page à partir de laquelle vous avez initialement commencé. Si vous ne voyez pas vos réclamations, c’est que vous n’avez reçu aucune erreur dans le processus et qu’il semble que rien ne s’est réellement produit, vous devriez vérifier si vous avez été redirigé vers http au lieu de https. Cela peut se produire si vous utilisez un proxy tel que traefik dans la configuration des conteneurs Docker.

La solution:

Pour résoudre ce problème, vous devez implémenter la méthode d’extension nécessaire pour exploiter un site Web sur une connexion HTTP derrière un proxy qui gère le transfert SSL. Un tel proxy ajoute l’en-tête X-Forwarded-Proto pour indiquer la nature de la connexion du client. Ceci est un exemple de classe AppBuilderExtension

using Owin;
using System;

namespace AuthIntegrationPlayground.Identity.Extensions.Owin
{    
    public static class AppBuilderExtensions
    {
        private const string ForwardedProtoHeaderAdded = "ForwardedProtoHeaderAdded";
        
        public static IAppBuilder UseForwardedProtoHeader(this IAppBuilder app)
        {
            if (app == null)
            {
                throw new ArgumentNullException(nameof(app));
            }

            // No need to add more than one instance of this middleware to the pipeline.
            if (app.Properties.ContainsKey(ForwardedProtoHeaderAdded))
            {
                return app;
            }

            app.Properties[ForwardedProtoHeaderAdded] = true;

            app.Use(async (context, next) =>
            {
                var request = context.Request;

                if (request.Scheme != Uri.UriSchemeHttps && string.Equals(request.Headers["X-Forwarded-Proto"], Uri.UriSchemeHttps, StringComparison.OrdinalIgnoreCase))
                {
                    context.Request.Scheme = "https";
                }

                await next.Invoke();
            });

            return app;
        }
    }
}

Et voici comment nous pouvons l’utiliser dans AzureADB2CIdentityProvider.cs

protected override void ProcessCore(IdentityProvidersArgs args)
{
    try
    {        
        //OpenIdConnectAuthenticationOptions
        
        args.App.UseForwardedProtoHeader();//<--- App builder extension
        args.App.UseOpenIdConnectAuthentication(options);
    }
    catch (Exception ex)
    {
        throw ex;
    }
}

IDX21323 : RequireNonce est ‘[PII is hidden]’ Erreur

Il s’agit de l’une des erreurs les plus ennuyeuses qui peuvent transformer votre dépannage d’authentification fédérée Sitecore en une boucle sans fin de recherche d’une solution et d’essai pour voir si elle fonctionne.

Le problème:

La cause première de cette erreur est un problème bien connu dans l’implémentation asp.net Katana. Pour en savoir plus sur ce problème, cliquez ici https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues. Essentiellement, cette erreur s’affichera lorsqu’OpenIdConnect n’a pas pu valider la valeur nonce en raison d’un cookie nonce manquant. Cependant, cette erreur peut être trompeuse et peut apparaître pour de nombreuses raisons différentes :

• Ne pas utiliser le pipeline GetSignInUrlInfo de Sitecore pour générer l’URL de connexion valide
• Le domaine du site Web et le domaine redirectURI sont différents et Sitecore n’a pas accès au cookie nonce après une authentification réussie
• Le cookie Nonce revient du serveur mais le navigateur le bloque. Cela peut arriver si vous n’utilisez pas https. Cela peut même être dû au décalage horaire (l’heure n’est pas réglée correctement). Le navigateur peut marquer le cookie comme expiré.
• Suppression des cookies entre la génération de l’URL de connexion et la redirection depuis le fournisseur externe

Quelques problèmes moins évidents qui pourraient produire cette erreur :

• XDB et/ou xDB.Tracking désactivés dans certains cas
• L’URL du point de terminaison du jeton dans OnCodeRecieved ne se résout pas correctement (mauvaise configuration)

La solution:

Du point de vue du développement, la solution la plus simple pour corriger cette erreur consiste à ajouter CookieManager = new SystemWebCookieManager() dans OpenIdConnectAuthenticationOptions.

Si cela ne fonctionne pas et que vous ne parvenez pas à déterminer la cause du problème, vous pouvez essayer ce qui suit :

• Le meilleur moyen de dépanner l’authentification fédérée Sitecore consiste probablement à utiliser simplement le débogueur Visual Studio. Connectez votre débogueur VS à l’instance en cours d’exécution et placez des points d’arrêt dans les méthodes de notification et votre AuthController. Pour que cela fonctionne, assurez-vous de publier en tant que débogage et non en tant que version. Suivez étape par étape l’authentification, depuis la génération de l’URL de connexion jusqu’à la réception des réclamations et leur affichage sur la page. Faites attention aux URL des points de terminaison et aux propriétés OpenIdConnectAuthenticationOptions
• Essayez de trouver plus d’informations en consultant Owin.log ou l’Observateur d’événements de votre système.
• Si vous avez implémenté une logique personnalisée dans les méthodes de notification (appel de services externes ou modification de la demande d’authentification), essayez de la commenter

Message d’erreur générique « Une erreur s’est produite »

Dans certains cas, généralement après avoir étendu ou modifié votre code, vous pourriez être confronté au message d’exception indiquant simplement « Une erreur s’est produite ». Dans ce cas, le mieux est de revoir la configuration complète de l’authentification et de vous assurer que toutes les parties intégrantes sont présentes. Soyez conscient de toute modification du code qui pourrait affecter le processus d’authentification. Si vous pensez que cette erreur provient d’Azure AD B2C, Application Insights peut vous aider à déterminer la cause réelle de cette erreur.

Résumé

Dans ce blog, nous avons passé en revue certains des problèmes les plus courants auxquels vous pouvez être confronté lors de l’intégration de Sitecore et Azure AD B2C. Cette intégration étant de nature complexe, de nombreux facteurs peuvent affecter le résultat. Les versions d’assembly, les configurations côté Sitecore et Azure AD B2C, le code personnalisé ou les dépendances externes peuvent entraîner l’échec de l’authentification. La clé d’un dépannage réussi de l’authentification fédérée Sitecore en général est de penser d’une manière qui vous mènera à trouver la cause première et donc à pouvoir la résoudre. Souvent, vous vous retrouverez à chercher une réponse sur Internet sans même savoir quelle est l’erreur.

Dernier conseil

Voici quelques conseils pour vous faciliter la tâche lorsque vous travaillez sur l’authentification fédérée.

• Évitez de tout mettre en œuvre en même temps – Il n’est pas conseillé de procéder à une implémentation complète avec toutes les transformations de revendications, le générateur d’utilisateurs personnalisé, l’extraction des données utilisateur d’API externes, l’extension du modèle de contact xConnect, etc. avant de pouvoir s’authentifier avec le minimum requis pour l’authentification. Ce n’est pas nécessairement une mauvaise chose, mais si vous commencez à rencontrer des erreurs lors de l’authentification, vous pourriez avoir du mal à découvrir la cause de l’échec de l’authentification. Au lieu de cela, essayez d’implémenter juste un minimum qui fonctionne sans problème, puis passez à l’étendre en fonction de vos besoins.
• Évitez d’utiliser différents guides comme référence – Si vous utilisez différents guides comme référence et faites référence à différentes parties de ces guides, vous pourriez vous retrouver avec une solution inutilisable et finalement réécrire la mise en œuvre complète depuis le début. La raison en est qu’il existe différents guides pour différentes versions de Sitecore et certains guides obsolètes pour Azure AD B2C. Vous devez toujours vous référer à la documentation de Sitecore et de Microsoft car elle est à jour, ainsi qu’aux guides spécifiques à votre version de Sitecore et à la configuration de votre projet.
• Gardez à l’esprit le résultat final – Après quelques itérations, vous atteindrez l’état souhaité pour votre processus d’authentification. Mais avant de commencer à travailler dessus, vous devez planifier à l’avance. C’est une bonne chose que tout soit documenté au même endroit. Pour les scénarios complexes, vous devez toujours disposer de diagrammes soutenant votre solution. Vous devez connaître les cas d’utilisation de vos revendications et de vos jetons d’accès (le cas échéant) afin de pouvoir faire avancer les choses de manière à les prendre en charge à la fin. Avec ces connaissances documentées, vous verrez les avantages à long terme puisque vous pourrez les utiliser comme référence future.