Можно ли взломать клиент WCF для передачи учетных данных сообщения без SSL?

Question

я написал пользовательская привязка WCF некоторое время назад, позволяющая моей ферме с балансировкой нагрузки размещать службы через IIS.Причиной пользовательской привязки было то, что каждый сервер не имел SSL, но ему требовалась возможность принимать учетные данные клиента, состоящие из имени пользователя и пароля.Прокси-сервер перед этой фермой имеет SSL, поэтому трафик будет шифроваться вне брандмауэра.Эта пользовательская привязка работает нормально, но теперь я нахожусь на этапе, когда мне нужно локально наблюдать за трафиком с моей машины, и я хотел сделать это без SSL в сочетании.

Проблема в том, что на клиенте .net, если я устанавливаю режим безопасности = «TransportWithMessageCredential», у меня должен быть SSL, иначе я получаю забавную ошибку «неверная схема, ожидается https»

Можно ли написать что-то специальное, чтобы клиент «игнорировал» отсутствие SSL, но при этом позволял мне передавать имя пользователя и пароль через заголовок SOAP?

Answer 1

Да, я написал сообщение в блоге об этом некоторое время назад под названием "Как:SSL Passthrough с WCF --или-- TransportWithMessageCredential через простой HTTP".

Короче говоря, вам нужно создать свой собственный HttpTransportBindingElement подкласс, который «лжет» об обеспечении безопасности.

Answer 2

Eсть Исправление для .net 3.5 SP1, который добавляет свойство AllowInsecureTransport в SecurityBindingElement.Это также будет в .net 4 beta 2.

Answer 3

Я предполагаю, что в вашей пользовательской привязке вы также получите сообщение об ошибке, если просто используете режим безопасности = «Сообщение»?Пользовательская привязка на самом деле не была необходима, поскольку (если я не ошибаюсь) вы можете использовать wsHttpBinding с режимом безопасности = «Сообщение» (не требуя SSL).

Другая альтернатива — просто создать сертификат SSL самостоятельно, установить его в IIS и реализовать политику доверия всем сертификатам в вашем вызывающем коде, но это обычно не одобряется (как и отправка имен пользователей и паролей по незащищенному каналу).

Третий вариант — изменить операции вашего контракта, чтобы они принимали имена пользователей и пароли (или какой-либо токен) в качестве параметра, или изменить контракты данных, чтобы вы могли отправлять информацию вместе с любым объектом, который вы уже отправляете.