Mam wymaganiezabezpieczyć strumień końcowy usługi WCF net.tcp za pomocą WIF. Powinien uwierzytelniać połączenia przychodzące na naszym serwerze tokenów. Usługa jest przesyłana strumieniowo, ponieważ jest przeznaczona do przesyłania dużych ilości danych.

To wydaje się niemożliwe. A jeśli nie uda mi się obejść haczyka, moje Święta Bożego Narodzenia zostaną zrujnowane, a ja piję się na śmierć w rynsztoku, podczas gdy wesołe kupujące przechodzą przez moje powoli chłodzące ciało. Poważnie, chłopaki.

Dlaczego to niemożliwe? Oto Catch-22.

Na kliencie muszę utworzyć kanał za pomocąGenericXmlSecurityToken Dostaję z naszego serwera tokenów. Bez problemu.

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

Czy powiedziałem „nie ma problemu”? Problem. W rzeczywistości,NullReferenceException problem stylu.

„Bro”, zapytałem Framework, „czy nawet nie sprawdzasz?” Framework był cichy, więc zdemontowałem go i znalazłem

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

było źródłem wyjątku i żeGetProperty telefon wracałnull. Więc, WTF? Okazuje się, że po włączeniu zabezpieczenia wiadomości i ustawieniu typu poświadczenia klienta naIssuedToken wtedy ta właściwość istnieje teraz wClientFactory (protip: Nie ma odpowiednika „SetProperty” w IChannel, draniu).

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

Słodkie. Nigdy więcej NRE. Jednak teraz mój klient jestbłąd przy urodzeniu (wciąż go kocham, tho). Przekopywanie się przez diagnostykę WCF (protip: spraw, by twoi najgorsi wrogowie robili to po zmiażdżeniu ich i kierowaniu nimi przed sobą, ale tuż przed rozkoszowaniem się lamentami swoich kobiet i dzieci), widzę, że to z powodu niedopasowania bezpieczeństwa między serwerem a klientem.

Żądana aktualizacja nie jest obsługiwana przez 'net.tcp: // localhost: 49627 / MyService'. Przyczyną może być niedopasowanie powiązań (na przykład zabezpieczenie włączone na kliencie, a nie na serwerze).

Sprawdzanie diagów hosta (znowu: zgniatanie, dysk, czytanie dzienników, cieszenie się lamentami), widzę, że to prawda

Typ protokołu application / ssl-tls został wysłany do usługi, która nie obsługuje tego typu aktualizacji.

„Cóż, ja”, mówię, „po prostu włączę zabezpieczenia wiadomości na hoście!” I ja to robię.Jeśli chcesz wiedzieć, jak to wygląda, jest to dokładna kopia konfiguracji klienta. Sprawdzać.

Wynik:Kaboom.

Powiązanie ('NetTcpBinding', 'http://tempuri.org/') obsługuje transmisję strumieniową, której nie można skonfigurować razem z zabezpieczeniami poziomu wiadomości. Rozważ wybór innego trybu transferu lub wybranie zabezpieczeń poziomu transportu.

Więc,mój host nie może być zarówno przesyłany strumieniowo, jak i zabezpieczany przez tokeny. Złap 22.

tl; dr: Jak mogę zabezpieczyć strumieniowany punkt końcowy WCF net.tcp za pomocą WIF ??