2

DotNetOpenAuth OpenID 버전 3.4.1을 사용하는 ASP.NET MVC 응용 프로그램을 단일 서버 웹 가든에서 하드웨어 부하 분산 장치 뒤에있는 실제 서버 클러스터로 이동하려고합니다 .DotNetOpenAuth RelayParty가로드 균형 조정 클러스터에서 작동하지 않습니다.

우리의 오래된 설정 (오픈 ID의 RP 가공) :

브라우저 => SHTTP => 서버 => WebGarden => 난스/세션 저장소가

우리의 새로운 설정 (오픈 ID RP가 작동하지) :

브라우저 => SHTTP =>로드 밸런서 => HTTP => 클러스터 노드 => WebGarden => 난스/세션 저장소 DB

우리는 그 자체로 새로운 인증 할 때 대가리 우리는 올바르게 오픈 ID 공급자로 리디렉션됩니다하지만 인증 후 우리는 우리의 클러스터 (릴레이 파티)로 다시 리디렉션하고 다음과 같은 예외 얻을 :

예외 우리는에 관련된 시스템을 추가 한

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를 제거하고 stateless connection을 사용하려고 시도 했었지만 그것도 작동하지 않았습니다. 우리는 항상 같은 오류가 발생합니다.

클러스터 노드가 OpenID 공급자에 연결할 때로드 밸런서와 다른 IP를 가지고 있기 때문에 문제가 발생한다고 생각되지만 확실하지 않습니다.

아이디어가 있으십니까? 답장을


덕분에, 내가 좀 더 정보를 줄 수 있도록 :

우리는 모두가 사내 영업 이익의와 RP. 우리는 서로를 정말로 신뢰하지 않는 여러 조직을 가지고 있으므로 공급자를 각 조직에 배포 한 다음 속성 교환을 사용하여 액세스 할 필요없이 사용자 데이터 (전자 메일 주소, 개인 번호 등)를 전달합니다. 서로 다른 데이터 저장소 (일반적으로 LDAP)를 직접 저장합니다.

하드웨어로드 밸런서를 통해 클러스터에 연결할 때가 아니라 단일 컴퓨터에서 설치가 정상적으로 작동하는 이유는 무엇입니까 (예 : 클러스터 노드에 직접 연결할 때).

우리는 양끝에 모든 종류의 다른 설정을 시도했지만 지금까지는 운이 없었습니다.

답변

4

"신뢰할 수없는 서버"에 대한 언급은 다소 오해의 소지가 있습니다. 그것은 좋은 추측 이었지만 web.config 파일의 화이트리스트/블랙리스트와 관련이 없습니다. 이 경우 OpenID는 UntrustedWebRequestHandler를 사용하여 OpenID가 사이트를 노출 할 수있는 무수한 공격으로부터 사이트를 보호하기 때문에 모든 것이 신뢰할 수없는 서버입니다.

귀하의 RP가 직접 인증 (벙어리 모드)을 사용하여 인증 응답을 확인하여 OP와 인증을 마치고 OP 엔드 포인트 자체가 RP로 HTTP 리다이렉트 응답을 보내고있는 것 같습니다. 허용되지 않습니다. RP가 로그인하려고 할 때마다이 문제가 발생합니까 아니면이 문제 만 있습니까? 어느 것이이 문제를 나타 냅니까? OP 소유자에게 그들이하는 일에 대해 이야기하고 싶습니다.

+0

시작을 찾는 것이 많은 도움이되었습니다. 우리 코드는 원래 https가 아닌 URL을 작성하고 현재로드 요청자 (URL은 https가 아니라 클러스터 노드에서는 http) 인 dotnetopenauth 예제를 기반으로하므로로드 밸런서는 302 개의 응답을 많이 보냈습니다 . 마지막으로 우리는 모든 부하 분산 응용 프로그램에 대해 https 구성표에 열린 ID와 관련하여 사용되는 모든 나가는 URL을 수정하는 "강제 https"스위치를 추가했습니다. 이 문제가 해결되었습니다. 도움 주셔서 감사합니다. – Garth