DotNetOpenAuth RelayParty не работает на кластере с балансировкой нагрузки

Question

Мы пытаемся переместить приложение ASP.NET MVC, использующее DotNetOpenAuth OpenID версии 3.4.1, из веб-сада с одним сервером в кластер физических серверов, поддерживаемый аппаратным балансировщиком нагрузки.

Наша старая настройка (работает OpenID RP):

Браузер => SHTTP => Сервер => WebGarden => Nonce/Session Store

Наша новая настройка (OpenID RP не работает):

Браузер => SHTTP => Балансировщик нагрузки => HTTP => Узел кластера => WebGarden => База данных Nonce / Session Store

Когда мы аутентифицируемся с новой настройкой, мы правильно перенаправляемся к провайдеру OpenID, но после аутентификации мы перенаправляемся обратно в наш кластер (ретранслятор) и получаем следующее исключение:

исключение

DotNetOpenAuth.Messaging.ProtocolException: Redirects on POST requests that are to untrusted servers is not supported.
 at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean condition, String message, Object[] args) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\ErrorUtilities.cs:line 235
 at DotNetOpenAuth.Messaging.UntrustedWebRequestHandler.GetResponse(HttpWebRequest request, DirectWebRequestOptions options) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\UntrustedWebRequestHandler.cs:line 258
 at DotNetOpenAuth.OpenId.ChannelElements.OpenIdChannel.GetDirectResponse(HttpWebRequest webRequest) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\OpenId\ChannelElements\OpenIdChannel.cs:line 277
 at DotNetOpenAuth.Messaging.Channel.RequestCore(IDirectedProtocolMessage request) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\Channel.cs:line 542
 at DotNetOpenAuth.Messaging.Channel.Request(IDirectedProtocolMessage requestMessage) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\Channel.cs:line 425
 at DotNetOpenAuth.Messaging.Channel.Request[TResponse](IDirectedProtocolMessage requestMessage) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\Channel.cs:line 405
 at DotNetOpenAuth.OpenId.ChannelElements.SigningBindingElement.ProcessIncomingMessage(IProtocolMessage message) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\OpenId\ChannelElements\SigningBindingElement.cs:line 154
 at DotNetOpenAuth.Messaging.Channel.ProcessIncomingMessage(IProtocolMessage message) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\Channel.cs:line 992
 at DotNetOpenAuth.OpenId.ChannelElements.OpenIdChannel.ProcessIncomingMessage(IProtocolMessage message) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\OpenId\ChannelElements\OpenIdChannel.cs:line 172
 at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestInfo httpRequest) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\Messaging\Channel.cs:line 386
 at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse(HttpRequestInfo httpRequestInfo) in c:\TeamCity\buildAgent\work\bf9e2ca68b75a334\src\DotNetOpenAuth\OpenId\RelyingParty\OpenIdRelyingParty.cs:line 501

Мы добавили машины, включенные в список доверенных машин, и для выключения требуется ssl, но это не имеет значения. Мы даже пытались удалить nonce store и использовать соединение без сохранения состояния, но это тоже не сработало. Мы всегда получаем одну и ту же ошибку.

Мы подозревали, что проблема возникает из-за того, что узел кластера имеет другой IP-адрес от балансировщика нагрузки, когда он подключается к провайдеру OpenID, но мы не уверены.

Есть идеи?

---

Спасибо за ответ, позвольте мне дать больше информации:

У нас есть как OP, так и RP. У нас есть несколько организаций, которые на самом деле не доверяют друг другу, поэтому мы распределяем поставщика по каждой организации, а затем используем обмен атрибутами для передачи пользовательских данных (адрес электронной почты, персональный номер и т. Д.) Без необходимости доступа к Хранилища данных друг друга (обычно LDAP) напрямую.

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

Мы попробовали все виды различных конфигураций на обоих концах, но пока безуспешно.

Answer 1

Ссылка на "ненадежный сервер", возможно, немного вводит в заблуждение. Это не имеет отношения к белому / черному списку в файле web.config, хотя это было хорошее предположение. В этом случае все является ненадежным сервером, потому что OpenID использует UntrustedWebRequestHandler, чтобы защитить ваш сайт от множества атак, которым в противном случае OpenID мог бы подвергнуть ваш сайт.

Похоже, что ваш RP завершает аутентификацию с OP, проверяя ответ аутентификации с использованием прямой проверки (тупой режим), и что сама конечная точка OP отправляет ответ HTTP Redirect обратно на ваш RP. Это не разрешено Эта проблема возникает для каждого OP, с которого пытается войти ваш RP, или только с этим? Какие из них имеют эту проблему? Я хотел бы поговорить с владельцем OP о том, что они делают.