3

Ich habe eine IdentityServer4-Anwendung basierend auf dem IS4-Identity-Beispiel und eine API mit Bearer-Token für die Autorisierung über IS4.AccessTokenValidation. Dies funktioniert auf Localhost über VisualStudio und wenn ich auf einer Windows 2012-VM bereitstellen und über IIS gehostet wird. Wenn ich den Identity Server als App Service-Website für Azure bereitstelle, ist alles in Ordnung. Wenn die API jedoch als App Service mit der gleichen Domäne und demselben Zertifikat wie die VM bereitgestellt wird, gibt jede Methode mit einem Autorize-Attribut (mit einer Richtlinie oder keiner, die keine Rolle spielt) immer eine 401 mit der Header-Nachricht zurück:Authorize erhält immer "Der Signaturschlüssel wurde nicht gefunden" in Azure AppService

Wir verwenden .NET 4.5.2 mit den neuesten Versionen der Pakete IdentityServer4 und IdentityServer4.AccessTokenValidation. Ich habe auch das neueste dieser Pakete von GitHub vom 30/08/16 ohne Änderung gezogen. Ich glaube nicht, dass es ein Fehler ist IS4 Validator sowieso, aber ich weiß nicht, was verursachen könnte. Irgendwelche Vorschläge? Ist es ein Azure-Host-Fehler?

Ich würde gerne in der Lage sein, dies zu debuggen, aber ich kann nicht Remote Debug arbeiten zu dieser App, auch wenn ich von Grund auf neu erstellt, und App-Protokolle sagen mir nichts. Ich habe im ASP.NET Security-Repository geblufft, aber ohne mehr Protokollierung oder Debug-Zugriff bin ich ziemlich ahnungslos, wie ich dieses Problem beheben kann.

API konfigurieren ist sehr einfach:

var jwtBearerOptions = new JwtBearerOptions() 
     { 
      Authority = Configuration["Authentication:IdentityServer:Server"], 
      Audience = Configuration["Authentication:IdentityServer:Server"]+"/resources", 
      RequireHttpsMetadata = false, 

      AutomaticAuthenticate = true, 
      AutomaticChallenge = true, 
     }; 
     app.UseJwtBearerAuthentication(jwtBearerOptions); 

und der Identity Server ist gerade aus den Proben und ein erworbenes Zertifikat zum Signieren verwenden.

Hat jemand andere diese Konfiguration vollständig als 2 Azure App Services funktioniert? Oder was möglicherweise diesen Fehler verursachen könnte, wenn das gleiche Bearer-Token, das an die VM-gehostete API gesendet wird, akzeptabel ist.

+0

Ähnliche Fall für IDsRV3 wurde auf https://gitter.im/IdentityServer/IdentityServer3/archives/2015/04/13 diskutiert. Was ich verstehe ist, dass das Problem auftritt, wenn ich keine Metadaten des Identitätsservers bekomme ('.well-known/opened-configuration'). Auch für mehr Protokollierung, konfigurieren Sie Aspnet-Core-Logging in Ihrem 'api' (Sie können es ermöglichen, schreiben Sie sich in einer Textdatei mit serilog anmelden) und überprüfen Fehlerprotokolle. –

+0

Interessante Möglichkeit in diesem Thread über die Größe des Tokens. Meins ist ziemlich groß, aber ich würde erwarten, dass dies ein Problem für alle Hosts ist. Will ein Spiel damit haben. Sie haben Recht mit der Protokollierung, ich werde Serilog hinzufügen. Sehen Sie, was herauskommt. – user1587195

+0

Ich brauchte mehr Protokollierung und benötigte den Sicherheits-Repo-Code. Es scheint, dass die SigningKey-Validierungsoptionen im App Service aus irgendeinem Grund unterschiedlich sein müssen. – user1587195

Antwort

3

Es stellte sich heraus, dass Sie die IssuerSigningKey in TokenValidationParameters explizit festlegen müssen. Also erhalte ich das Zertifikat aus dem App Service Store und füge es über JwtBearerOptions.TokenValidationParameters hinzu. So Startup Config sieht wie folgt aus:

 public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory) 
    { 
     ... 
     JwtSecurityTokenHandler.DefaultInboundClaimTypeMap = new Dictionary<string, string>(); 
     var tokenValidationParameters = new TokenValidationParameters 
     { 
      // The signing key must match! 
      ValidateIssuerSigningKey = true, 
      IssuerSigningKey = new X509SecurityKey(GetSigningCertificate()), 

      // Validate the JWT Issuer (iss) claim 
      ValidateIssuer = false, 
      //ValidIssuer = "local", 

      // Validate the JWT Audience (aud) claim 
      ValidateAudience = false, 
      //ValidAudience = "ExampleAudience", 

      // Validate the token expiry 
      ValidateLifetime = true, 

      // If you want to allow a certain amount of clock drift, set that here: 
      ClockSkew = TimeSpan.Zero 
     }; 
     var jwtBearerOptions = new JwtBearerOptions() 
     { 
      Authority = Configuration["Authentication:IdentityServer:Server"], 
      Audience = Configuration["Authentication:IdentityServer:Server"]+"/resources", 
      RequireHttpsMetadata = false, 

      AutomaticAuthenticate = true, 
      AutomaticChallenge = true, 

      TokenValidationParameters = tokenValidationParameters 
     }; 
     app.UseJwtBearerAuthentication(jwtBearerOptions); 

     app.UseMvc(); 
     ... 
    } 

Keine Ahnung, warum dies nur auf der Azure App-Service benötigt wird, und nicht auf einem Server oder Entwicklungsmaschine. Kann jemand anderes es erklären? Es würde den ValidateIssuerSigningKey-Standardwert für "App Service" als "True" und an anderer Stelle als "false" vorschlagen.

Verwandte Themen