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 ???