Ich habe eine Anforderung anSichern Sie einen gestreamten WCF-net.tcp-Dienstendpunkt mithilfe von WIF. Eingehende Anrufe sollten auf unserem Tokenserver authentifiziert werden. Der Dienst wird gestreamt, weil er zum Übertragen großer Datenmengen und Datenmengen entwickelt wurde.

Dies scheint unmöglich zu sein. Und wenn ich nicht um den Haken komme, ist mein Weihnachtsfest ruiniert und ich trinke mich in einer Gosse zu Tode, während fröhliche Käufer über meinen langsam abkühlenden Körper treten. Totes ernst, Jungs.

Warum ist das unmöglich? Hier ist der Catch-22.

Auf dem Client muss ich einen Channel mit dem erstellenGenericXmlSecurityToken Ich bekomme von unserem Tokenserver. Kein Problem.

// people around here hate the Framework Design Guidelines.
var token = Authentication.Current._Token;
var service = base.ChannelFactory.CreateChannelWithIssuedToken(token);
return service.Derp();

Habe ich "no problemo" gesagt? Problemo. Eigentlich,NullReferenceException Stil problemo.

"Bro", fragte ich das Framework, "hast du überhaupt keine Prüfung?" Das Framework war still, also zerlegte ich es und fand es

((IChannel)(object)tChannel).
    GetProperty<ChannelParameterCollection>().
    Add(federatedClientCredentialsParameter);

war die Quelle der Ausnahme, und dass dieGetProperty Anruf kam zurücknull. Also, WTF? Es stellt sich heraus, dass, wenn ich die Nachrichtensicherheit aktiviere und den Client-Anmeldeinformationstyp auf setzeIssuedToken dann existiert diese Eigenschaft jetzt imClientFactory (protip: Es gibt kein "SetProperty" -Äquivalent in IChannel, dem Bastard).

<binding name="OMGWTFLOL22" transferMode="Streamed" >
    <security mode="Message">
        <message clientCredentialType="IssuedToken"/>
    </security>
</binding>

Süss. Keine NREs mehr. Jetzt ist es jedoch mein Mandantbei der Geburt bemängelt (liebe ihn immer noch, tho). Beim Durchstöbern der WCF-Diagnose (Protip: Lassen Sie Ihre schlimmsten Feinde dies tun, nachdem Sie sie zermalmt und vor Ihnen gefahren haben, bevor Sie die Wehklagen ihrer Frauen und Kinder genießen), liegt meiner Ansicht nach eine Sicherheitslücke zwischen Server und Client vor.

Das angeforderte Upgrade wird von "net.tcp: // localhost: 49627 / MyService" nicht unterstützt. Dies kann an nicht übereinstimmenden Bindungen liegen (z. B. aktivierte Sicherheit auf dem Client und nicht auf dem Server).

Wenn ich die Daten des Hosts überprüfe (erneut: zerdrücken, fahren, Protokolle lesen, Wehklagen genießen), sehe ich, dass dies wahr ist

Protokolltyp application / ssl-tls wurde an einen Dienst gesendet, der diese Art der Aktualisierung nicht unterstützt.

"Nun, ich selbst", sagt ich, "ich werde nur die Nachrichtensicherheit auf dem Host aktivieren!" Und ich mache.Wenn Sie wissen möchten, wie es aussieht, ist es eine exakte Kopie der Client-Konfiguration. Sieh nach oben.

Ergebnis:Kaboom.

Die Bindung ('NetTcpBinding', 'http://tempuri.org/') unterstützt Streaming, das nicht zusammen mit der Sicherheit auf Nachrichtenebene konfiguriert werden kann. Überlegen Sie, ob Sie einen anderen Übertragungsmodus oder die Sicherheit auf Transportebene auswählen möchten.

So,Mein Host kann nicht über Token sowohl gestreamt als auch gesichert werden. Fang-22.

tl; dr: Wie kann ich einen gestreamten net.tcp-WCF-Endpunkt mit WIF sichern?