DotNetOpenAuth RelayParty не работает с балансированным весом кластером

Question

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

Наш старый настройки (OpenID RP рабочий):

Browser => SHTTP => Сервер => WebGarden => Нонс/Session магазин

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

Browser => SHTTP => Load Balancer => HTTP => Узел кластера => WebGarden => Нонс/Session магазин DB

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

Exception

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 и использовать соединение без гражданства, но это тоже не сработало. Мы всегда получаем ту же ошибку.

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

Любые идеи?

---

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

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

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

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

Answer 1

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

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