0
votes

Erreur du client de découverte IdentityServer4 - Le nom de l'émetteur ne correspond pas à l'autorité

J'obtiens l'erreur «Le nom de l'émetteur ne correspond pas à l'autorité» car j'ai un équilibreur de charge de terminaison SSL devant mon service is4 (c'est-à-dire que l'émetteur est https: // myurl et l'autorité est http: // myurl ).

Que dois-je faire dans cette situation? Les noms DNS sont identiques, c'est le s en https qui provoque l'échec de la validation!

identityserver4

0 commentaires

4 Réponses :

0
votes

Votre URL d'émetteur est https mais l'URL d'autorité est http . Les deux URL doivent être exactement les mêmes.

Sinon, vous pouvez essayer de définir la propriété ValidateIssuerName sur false. Cette propriété décide si le nom de l' issuer doit être identique à l' authority ou non. Par défaut c'est vrai -

            var discoRequest = new DiscoveryDocumentRequest
            {
                Address = "authority",
                Policy = new DiscoveryPolicy
                {
                    ValidateIssuerName = false,
                },
            };

3 commentaires

Salut Aparna, l'autorité doit rester https car c'est ainsi que les clients se connectent au serveur is4, c'est-à-dire via ssl à l'équilibreur de charge. Comment rendre l'émetteur https également? Autant que je sache, cela est généré par is4 mais je ne sais pas comment il décide s'il faut mettre http ou https.

Malheureusement, j'ai ajouté ValidateIssuerName = false et cela m'a juste amené à l'erreur suivante qui était liée à des points de terminaison non valides. J'ai ensuite ajouté ValidateEndpoint = false mais j'ai ensuite eu une erreur invalid_request. Je suis actuellement en train de dépanner pour comprendre ce qu'est cette erreur invalid_request. Une chose est certaine, la même configuration de code / config / load balancer fonctionne correctement si j'utilise uniquement http et non https. Je ne sais pas pourquoi la validation est effectuée sur l'url et pas simplement le nom dns car le nom dns est la partie importante que j'aurais pensé, pas le fait que ce soit http ou https.

J'ai trouvé la propriété PublicOrigin, mais cela seulement (ironiquement!) Aide à définir le nom DNS, il ne contrôle pas la partie http / s. Je pense que travailler sur la désactivation de la validation dans le client de découverte est l'approche la plus pragmatique, je viens de frapper un mur de briques aujourd'hui avec cette erreur invalid_request :(

1
votes

Il est possible que votre émetteur et votre autorité soient différents, mais cela nécessite des modifications de la configuration du serveur et de la demande de découverte.

Sur la méthode de démarrage de votre serveur d'identité, vous pouvez définir l'émetteur:

DiscoveryDocumentRequest discoveryDocument = null;
if (Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") == EnvironmentName.Development)
    {
        discoveryDocument = new DiscoveryDocumentRequest()
        {
            Address = "http://myurl:5000",
            Policy = {
                 RequireHttps = false,
                 Authority = "http://myurl:5000",
                 ValidateEndpoints = false
            },
         };
    }
    else
    {
         discoveryDocument = new DiscoveryDocumentRequest()
         {
             Address = "http://myurl:5000",
             Policy = {
                  RequireHttps = false,
                  Authority = "https://myurl",
                  ValidateEndpoints = false
             },
         };
}
var disco = await httpClient.GetDiscoveryDocumentAsync(discoveryDocument);

Et puis dans votre demande de document de découverte:

var identityServerBuilder = services.AddIdentityServer(options =>
{
    if (Environment.IsDevelopment())
    {
        options.IssuerUri = $"http://myurl:5000";
    }
    else
    {
        options.IssuerUri = $"https://myurl";
    }
})

1 commentaires

salut nick, ça a l'air idéal! J'ai également posté la question sur le gitter is4 et mackie1001 a répondu en expliquant la nécessité de traiter les en-têtes transférés, ce qui, à mon avis, est une solution légèrement meilleure car je n'ai pas besoin de définir l'URI de l'émetteur et de lui permettre de générer comme avant. J'ajouterai sa réponse ci-dessous pour quiconque rencontre ce problème.

0
votes

réponse de mackie1001 sur identityserver4 gitter

votre équilibreur de charge doit transférer sur le protocole d'origine (X-Forwarded-Proto) et vous pouvez l'utiliser pour définir le schéma de requête actuel afin qu'il corresponde à la requête entrante, il vous suffit de créer une fonction middleware pour le faire. : https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.0

pour référence c'est le code que j'ai ajouté au démarrage: -

                app.UseForwardedHeaders(new ForwardedHeadersOptions
                {
                  ForwardedHeaders = ForwardedHeaders.XForwardedProto
                });

merci beaucoup mackie1001!

0 commentaires

0
votes

si vous utilisez nginx comme équilibreur de charge, vous en aurez probablement besoin dans la configuration du service ...

app.UseForwardedHeaders();

puis ajoutez ce middleware avant le middleware du serveur d'identité

services.Configure<ForwardedHeadersOptions>(options =>
            {
                options.ForwardedHeaders =
                    ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;

                // Only loopback proxies are allowed by default.
                // Clear that restriction because forwarders are enabled by explicit
                // configuration.
                options.KnownNetworks.Clear();
                options.KnownProxies.Clear();
            });

0 commentaires