2012-03-22 5 views
0

Я реализую простой балансировщик нагрузки - это HTTP-прослушиватель, который анализирует входящие запросы из браузера и направляет их в соответствующее приложение ASP.NET. Он прослушивает определенный порт (8801), и при маршрутизации он сохраняет исходный URI и изменяет только номер порта, например. https://machine.domain.com:8801/testsite/Default.aspx может быть перенаправлен на https://machine.domain.com:8811/testsite/Default.aspxWIF пассивная федерация с пользовательским балансировщиком нагрузки на месте

Без обеспечения безопасности работы маршрутов просто отлично. Проблема возникает, когда я пытаюсь применить федерацию WIF к приложениям ASP.NET. Я использую ADFS 2.0. Вот два сценария, я пытался:

сценарий 1

WS-Federation пассивный конечный полагающейся стороны установлен в приложении ASP.NET URI

Когда балансировки нагрузки URI доступен через браузер, загрузите балансир маршруты к Приложение ASP.NET и страница загружаются, однако RequestSecurityTokenResponse от STS перенаправляется непосредственно в приложение ASP.NET (а не балансировщик нагрузки) в соответствии с настройкой пассивной конечной точки. Так что это работает, но поскольку я хочу, чтобы вся связь с ASP.NET-приложением обрабатывалась через балансировщик нагрузки, этот сценарий не соответствует моим требованиям.

сценарий 2

опираясь WS-Federation пассивного конечной партии имеет значение для загрузки балансира URI

Когда балансировки нагрузки URI доступен через браузер, загрузка балансир маршруты в приложение ASP.NET, который возвращает Несанкционированный ответ , переадресация браузера на STS, RequestSecurityTokenResponse перенаправляется обратно на балансировщик нагрузки, но когда он перенаправляется в приложение ASP.NET, я получаю ответ 401 - Unauthorized: доступ запрещен из-за неверных учетных данных. Это связано с несоответствием URI, которое я считаю, поскольку маркер saml выдается для URI балансировки нагрузки. Я пробовал различные комбинации зрительного ура и царств, но никакого успеха.

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

Надеюсь, я достаточно четко объяснил свою проблему.

Помощь высоко ценится Спасибо

ответ

1

В конце концов, проблема была где-то в другом месте. То, что на самом деле делает мой балансировщик нагрузки, это преобразовать входящий HttpListenerRequest в новый HttpWebRequest, который затем перенаправляется в соответствующее приложение ASP.NET. Тем не менее, я не отключил автопереадресацию перенаправленного запроса, поэтому произошли перенаправления из приложения ASP.NET в ADFS. Этот код сделал магию:

HttpWebRequest.AllowAutoRedirect = false;

+0

Из любопытства, где вы разместили этот код в своем решении? – shenn

0

В ваших полагающихся приложениях сторонних web.config, вы можете подтвердить, что ваш federatedAuthentication раздел выглядит примерно так (сфера ниже должна быть указана ваш порт NLB):

<federatedAuthentication> 
    <wsFederation passiveRedirectEnabled="true" issuer="https://mysts.com/v2/wsfederation" realm="https://machine.domain.com:8801/testsite/Default.aspx" requireHttps="false" /> 
    <cookieHandler requireSsl="false" /> 
</federatedAuthentication> 

Кроме того, еще одна проблема, о которой вы должны знать, - это cookie сеанса. WIF использует DPAPI по умолчанию для шифрования, поэтому вам придется использовать RsaEncryptionCookieTransform. Такая же проблема возникает при использовании WIF в Azure. Вот статья, которая показывает, как это делается:

http://msdn.microsoft.com/en-us/library/windowsazure/hh289318.aspx

+0

cheers mate, в конце концов, RsaEncryptionCookieTransform не понадобился, спасибо в любом случае – vvega

 Смежные вопросы

  • Нет связанных вопросов^_^