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.
Ä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. –
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
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