Catch-22 предотвращает потоковую службу TCP WCF, защищаемую WIF; разрушая мое Рождество, психическое здоровье

У меня есть требование кзащитить потоковую конечную точку службы WCF net.tcp с помощью WIF, Он должен аутентифицировать входящие звонки на наш токен-сервер. Служба потоковая, потому что она предназначена для передачи больших объемов данных и прочего.

Это кажется невозможным. И если я не смогу обойти добычу, мое Рождество испортится, и я выпью себя до смерти в канаве, пока веселые покупатели переступают через мое медленно остывающее тело. Серьезные слова, ребята.

Почему это невозможно? Вот Поймай-22.

На клиенте мне нужно создать канал сGenericXmlSecurityToken Я получаю с нашего токен-сервера. Без проблем.

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

Я сказал "нет проблем"? Problemo. По факту,NullReferenceException проблемный стиль.

«Братан, - спросил я у Фреймворка, - ты вообще проверил ноль?» Фреймворк молчал, поэтому я разобрал и обнаружил, что

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

был источником исключения, и чтоGetProperty звонок возвращалсяnull, Итак, WTF? Оказывается, если я включу безопасность сообщений и установлю тип учетных данных клиентаIssuedToken то это свойство теперь существует вClientFactory (protip: в IChannel, ублюдок, нет эквивалента SetProperty).

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

Сладкий. Нет больше NRE. Тем не менее, теперь мой клиентнеисправен при рождении (все еще люблю его, хотя) Копаясь в диагностике WCF (прототип: заставьте своих злейших врагов делать это после того, как сокрушите их и гоните их перед вами, но прямо перед тем, как получить удовольствие от жалоб своих женщин и детей), я вижу, что это из-за несоответствия безопасности между сервером и клиентом.

Запрошенное обновление не поддерживается 'net.tcp: // localhost: 49627 / MyService'. Это может быть связано с несовпадающими привязками (например, защита включена на клиенте, а не на сервере).

Проверяя дигасы хоста (опять же: раздавить, загнать, прочитать логи, насладиться причитаниями), я вижу, что это правда

Тип протокола application / ssl-tls был отправлен службе, которая не поддерживает этот тип обновления.

«Ну что ж, - говорю я, - я просто включу безопасность сообщений на хосте!» И я делаю.Если вы хотите знать, как это выглядит, это точная копия конфигурации клиента. Уважать.

Результат:Kaboom.

Привязка ('NetTcpBinding', 'http://tempuri.org/') поддерживает потоковую передачу, которую нельзя настроить вместе с безопасностью на уровне сообщений. Подумайте о выборе другого режима передачи или безопасности на транспортном уровне.

Так,мой хост не может быть как потоковым, так и защищенным с помощью токенов, Словить 22.

tl; dr: Как я могу защитить потоковую конечную точку WCF net.tcp, используя WIF ???

Ответы на вопрос(1)

Ваш ответ на вопрос