Browser hängt in IdentityServer MVC Walkthrough beim Aufruf von callapi/client_credentials

Question

Ich arbeite über den IdentityServer MVC walkthrough in the documentation und es ist großartig, bis ich zu Teil 2 komme, wo ich eine andere API aus der MVC-App anrufe. Hier hängt der Browser beim Aufruf/callApi/ClientCredentials bis schließlich mit Aufgabe abgebrochen Fehlern Zeitüberschreitung und die VS-Debugger lösen eine Ausnahme Invalid Operation mit der api Startup-Klasse bei app.UseIdentityServerBearerTokenAuthentication(...) mit der inneren Ausnahme: IDX10803: Unable to create to obtain configuration from: 'http://localhost:44300/identity/.well-known/openid-configuration'.

Wie ich sagte, bis jetzt funktionierte alles großartig in der Walkthrough. Das Discovery-Dokument kann über den Browser von dieser Adresse aus problemlos abgerufen werden (kein SSL-Fehler - das Site-Zertifikat ist vertrauenswürdig).

Das sieht ähnlich aus wie here, aber es ist anders, weil in dieser Konfiguration Identityserver und die Access Token Validierungs-Middleware in separaten Prozessen (beide in IIS Express mit meinem Konto ausgeführt) sind. Ich habe versucht, Einstellung DelayLoadMetadata trotzdem und jetzt der Browser gibt die Aufgabe abgebrochen Ausnahme und Visual Studio wirft keine Ausnahme.

Ich fügte Protokollierung hinzu und sah keine Probleme - es zeigt, dass der MVC-Client sein Zugriffs-Token bekommt, und dann war es das.

Ich habe auch alle Apps und SSL-Ports neu konfiguriert, um einen "echten" Hostnamen und ein Zertifikat zu verwenden, damit ich alles über Fiddler ansehen konnte. Das hat für den gesamten Durchlauf (und auch den vorherigen) gut funktioniert, bleibt aber an diesem Punkt hängen. Ich sehe die API-App für das Discovery-Dokument abfragen und es wird nie eine Antwort erhalten.

Was fehlt mir?

Answer 1

Es stellte sich heraus, dass es ein einfacher Fehler meinerseits war. In der Startup-Klasse der API, als ich die Autorisierungseigenschaft IdentityServerBearerTokenAuthenticationOptions initialisiert habe, habe ich die URL fälschlicherweise mit http: // anstelle von https: // vorangestellt. Also, obwohl ich das SSL-Zertifikat hatte und die Ports funktionierten, benutzte die API stattdessen HTTP, um zu versuchen, den Identitätsserver zu erreichen, und anscheinend ist nichts auf meinem Computer an http://localhost:44300 gebunden. Als ich es reparierte

Authority = "https://localhost:44300/identity", 
// added the "s"-^ 

dann arbeitete es wie ein Champion. Ich trete mich selbst dafür, dass ich das verpasst habe. Moral der Geschichte: Überprüfen Sie den Port, Pfad, Zertifikat und das Protokoll sind alle korrekt.

Answer 2

Wenn Sie mit Identity Server 3 arbeiten, sollten Sie in die Datenbanken des Identitätsdatenbasisservers 18 für Clients und Benutzer gelangen. Wenn Sie also diese Tabellen in Ihrer Datenbank sehen können, ist alles in Ordnung.

Jetzt in Ihrem Ressource-Server muss eine StartUp-Klasse mit der Konfiguration, den Token-Anbieter und Validierung zu setzen:

public void Configuration(IAppBuilder app) 
     { 
      // Any connection or hub wire up and configuration should go here 
      var clientId = (string)ConfigurationManager.AppSettings["oauth2.clientid"]; 
      var authority = (string)ConfigurationManager.AppSettings["oauth2.authority"]; 

      app.UseIdentityServerBearerTokenAuthentication(new IdentityServerBearerTokenAuthenticationOptions 
      { 
       Authority = authority, 
       ValidationMode = ValidationMode.ValidationEndpoint, 
       RequiredScopes = new[] { clientId }, 
      }); 

      app.UseResourceAuthorization(new AuthorizationManager()); 

      var config = new HubConfiguration(); 

      config.EnableJSONP = true; 
      app.MapSignalR(config);  


     } 


     private void ConfigureOAuth() 
     { 
      var formatters = GlobalConfiguration.Configuration.Formatters; 
      var jsonFormatter = formatters.JsonFormatter; 
      var settings = jsonFormatter.SerializerSettings; 
      settings.Formatting = Formatting.Indented; 
     } 


public class RequireHttpsAttribute : AuthorizationFilterAttribute 
    { 

     public override void OnAuthorization(HttpActionContext actionContext) 
     { 
      base.OnAuthorization(actionContext); 

      var request = actionContext.Request; 
      if (request.RequestUri.Scheme != Uri.UriSchemeHttps) 
      { 

       actionContext.Response.Content = new StringContent("<p>https scheme required.</p>", Encoding.UTF8, "text/html"); 

       if (string.Compare(request.Method.Method, "GET", true) == 0) 
       { 
        actionContext.Response = request.CreateResponse(HttpStatusCode.Found); 

        var builder = new UriBuilder(request.RequestUri); 
        builder.Scheme = Uri.UriSchemeHttps; 
        builder.Port = 443; 

        actionContext.Response.Headers.Location = builder.Uri; 
       } 
       else 
       { 
        actionContext.Response = request.CreateResponse(HttpStatusCode.NotFound); 

       } 
      } 
     } 
    } 

I ResourceOwner Fluss für diesen Client verwenden. Und meine letzte Empfehlung ist die nächste: Skype verwendet den Port 443, ich weiß, das kann seltsam sein, aber wenn es immer noch schief geht, ändere deinen IdentityServer-Port auf 44305 oder etwas anderes als 44300 oder 443. Skype kann den gleichen Port und den gleichen verwenden du bist verrückt.

Ich hoffe, es hilft.