WCF, WebAPI und OWIN IIS integrierte Pipeline. Weiter OWIN basierend auf Strecke

Question

Situation

Ich habe eine Silverlight-Anwendung, die einen WCF-Backend verwendet. In Zukunft sind wir mit WebAPI zu JS-Clients gewechselt.

Ich habe ein paar WebAPI Controller, die ich aus dem Silverlight-Client verwenden möchte, und so haben sie in der ASP.Net-Anwendung geladen, die die WCF-Dienste hostet.

Dies funktioniert aus einer Sicht „alle Dienste zur Verfügung stehen“, wird jedoch Authorization mehrfach aufgerufen wird für WCF Anrufe; Von OWIN und durch WCF

Auf der WCF-Seite überprüft meine ServiceAuthorizationManager-Implementierung das Token im AuthHeader und transformiert dann dieses Token (im Sinne von System.IdentityModel Claims Transformation). Auf der WebAPI-Seite verwende ich Thinktecture.IdentityModel, die OWIN Middleware zur Token-Validierung und Schadentransformation zur Verfügung stellt.

Problem ist, die OWIN Middleware für alle Anforderungen aufgerufen wird (einschließlich der WCF-Anfragen). Im Falle einer WCF-Anfrage wird die Validierung und die Umwandlung zweimal ausgeführt. Ich kann nicht einfach den ServiceAuthorizationManager entfernen und die Middleware damit umgehen lassen, da WCF nichts von OWIN kennt und der letzte Schritt des ServiceAuthorizationManagers darin besteht, den Operationskontext Principal zu setzen (anders als ClaimsPrincipal.Current).

Frage

Hat jemand ein Problem wie dieses hatte zuvor mit WCF und WebAPI sitzen nebeneinander? Wäre der beste Ansatz, die OWIN-Pipeline schon sehr früh für WCF-Aufrufe zu löschen, und wenn ja, wie kann dies über eine OMC geschehen? Oder kann ich irgendwie die IAppBuilder.Map-Methode verwenden, um nur die Token-Validierungs- und Transformationskomponenten für API-Routen zu registrieren (in diesem Fall alles Start/API)?

Answer 1

habe ich es geschafft, dies über eine Branched Pipeline zur Arbeit zu kommen.

app.MapWhen(c => c.Request.Path.Value.Contains("/api"), 
        subApp => 
        { 
         subApp.UseJsonWebToken(
          issuer: clientDetails.Issuer, 
          audience: clientDetails.Audience, 
          signingKey: clientDetails.SigningKey); 

         subApp.UseClaimsTransformation(transformer.Transform); 

         var webApiConfig = WebApiConfig.Configure(); 
         webApiConfig.DependencyResolver = StructureMapConfig.HttpDependencyResolver(); 
         subApp.UseWebApi(webApiConfig); 
        }); 

Das Einzige, was ich frage mich, warum ist IAppBuilder.MapWhen wie oben funktioniert, aber wenn ich IAppBuilder.Map verwenden es scheint nicht zu funktionieren ...

app.Map("/api", 
     subApp => ... 

Answer 2

Big dank der Antwort oben. Mit diesem Code konnte ich herausfinden, wie Anrufe konditional weitergeleitet werden können, sodass WCF-Anrufe nicht von Middleware für statische Inhalte übernommen werden.

//app.UseMiddleware<ServeStaticFilesMiddleware>(); 

    app.MapWhen(c => !c.Request.Path.Value.Contains(".svc"), 
      subApp => 
      { 
       subApp.UseMiddleware<ServeStaticFilesMiddleware>(); 
      });