2012-03-14 23 views
6

Dưới đây là tình hình tôi đang cố gắng để đối phó với:Làm thế nào để chuyển hướng một dịch vụ WCF đến một HTTPS endpoint với Windows chứng

Chúng tôi có một khách hàng WCF làm việc với một thiết bị đầu cuối http và https endpoint nhưng không phải khi nó được chuyển hướng (302) từ http đến https. Chúng tôi có một cân bằng tải F5 đang thực hiện chuyển hướng và chức năng SSL nhưng theo như tôi có thể nói, nó không làm bất cứ điều gì bất ngờ cho các yêu cầu. Chuyển hướng có vẻ là thủ phạm, nơi WCF không muốn cung cấp thông tin xác thực Windows Kerberos sau khi chuyển hướng được thực hiện.

Trình tự cho một cuộc gọi thành công (ví dụ http không có chuyển hướng) đi như thế này:

  • Khách hàng - Gửi yêu cầu POST cho dịch vụ với chương trình http
  • Server - Đáp ứng với 401 trái phép
  • Khách hàng - Gửi POST thương lượng với ủy quyền
  • Máy chủ - Trả lời với 100 Tiếp tục
  • Khách hàng - Gửi dữ liệu xà phòng và hoàn tất thành công

Khi cuộc gọi được chuyển hướng và thất bại nó đi như thế này:

  • Khách hàng - Gửi yêu cầu POST cho dịch vụ với chương trình http
  • Server - Trả 302 với chuyển hướng đến https chương trình cho cùng một địa chỉ
  • Khách hàng - Gửi GET cho địa chỉ https (Tôi không thể hiểu tại sao đây là GET và không phải là POST)
  • Server - Trả lời 401 không được phép
  • Khách hàng - ném ngoại lệ "Yêu cầu HTTP không được ủy quyền với giao thức xác thực ứng dụng khách 'Thoả thuận'. Authentication header nhận từ máy chủ là 'Negotiate, NTLM'."

Nó tương tự như this problem nhưng không giống hệt nhau (và không có một câu trả lời thực sự có mặc dù nó tham khảo 'giao thức phá vỡ WCF' mà chúng tôi có thể tìm thấy documetation trên) .Nếu chúng ta tắt quy tắc chuyển hướng F5 http và https hoạt động lưu lượng truy cập tốt.Làm WCF thực sự không xử lý chuyển hướng đơn giản này? Có một workaround hoặc bất kỳ tài liệu nào về lỗ hổng này?

Cấu hình ứng dụng khách (lưu ý rằng khi thử nghiệm điều này với https, tôi thay đổi TransportCredentialOnly thành Giao thông vận tải):

<client> 
     <endpoint address="http://fooserver/MyService.svc/" binding="basicHttpBinding" bindingConfiguration="clientBinding" contract="Contracts.IMyService" /> 
</client> 
<bindings> 
<basicHttpBinding> 
    <binding name="clientBinding"> 
     <security mode="TransportCredentialOnly"> 
      <transport clientCredentialType="Windows" proxyCredentialType="Windows" /> 
     </security> 
    </binding> 
</basicHttpBinding> 

máy chủ cấu hình trông như thế này:

<system.serviceModel> 
    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" /> 
    <services> 
     <service behaviorConfiguration="MyServiceBehavior" name="MyService"> 
      <endpoint address="" binding="basicHttpBinding" bindingConfiguration="securedBinding" contract="Contracts.IMyService"> 
      </endpoint> 
     </service> 
    </services> 
    <bindings> 
     <basicHttpBinding> 
      <binding name="securedBinding"> 
       <security mode="TransportCredentialOnly"> 
        <transport clientCredentialType="Windows" proxyCredentialType="Windows"/> 
       </security> 
      </binding> 
     </basicHttpBinding> 
    </bindings> 
    <behaviors> 
     <serviceBehaviors> 
      <behavior name="MyServiceBehavior"> 
       <serviceMetadata httpGetEnabled="true"/> 
       <serviceDebug includeExceptionDetailInFaults="true"/> 
       <useRequestHeadersForMetadataAddress> 
        <defaultPorts> 
         <add scheme="http" port="80" /> 
         <add scheme="https" port="443" /> 
        </defaultPorts> 
       </useRequestHeadersForMetadataAddress> 
      </behavior> 
     </serviceBehaviors> 
    </behaviors> 
</system.serviceModel> 
+0

Có thể trùng lặp [Tại sao WCF không gọi được dịch vụ SOAP khi gặp phải phản hồi 302?] (Http://stackoverflow.com/questions/17152385/why-would-wcf-fail-to-call-a -soap-service-khi-a-302-response-là-gặp phải) – Luizgrs

Trả lời

1

Tôi không thể hiểu tại sao đây là một GET và không phải là một POST

Đó là nguyên nhân của vấn đề của bạn. Sau khi nhận được phản hồi 302 cho POST, hành vi được mong đợi cho khách hàng là GET URL mới.Xem thông tin sau tại http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Nếu mã trạng thái 302 được nhận để đáp ứng yêu cầu khác GET hoặc HEAD, tác nhân người dùng KHÔNG ĐƯỢC tự động chuyển yêu cầu trừ khi người dùng có thể xác nhận, vì điều này có thể thay đổi các điều kiện theo đó yêu cầu được đưa ra.

Ngoài ra, các bài sau SO có một số thông tin tốt: Response.Redirect with POST instead of Get?

Vì vậy, WCF là làm những gì nó nên làm bằng cách từ chối để lại POST sau một chuyển hướng 302. Rất tiếc, tôi không chắc chắn những gì có thể được thực hiện để giải quyết vấn đề của bạn, ngoài việc chỉ định giao thức chính xác lần đầu tiên để tránh 302.

+0

Điều đó chắc chắn giải thích GET, nhưng có vẻ như WCF sẽ có thể xử lý công tắc này. Có lẽ trong nội bộ của nó WCF chỉ gửi tín dụng trên một bài viết? Có lẽ phần đó của khung công tác không được triển khai đúng cách? Một số cách để biết chắc chắn sẽ là tuyệt vời. –

+0

401 Unauthorized có bao gồm các tiêu đề WWW-Authenticate thích hợp không? –

+0

cả 401 (với chuyển hướng và không có chuyển hướng giống hệt nhau) –

1

Tôi đã làm điều tương tự và tôi có thể xác nhận điều này không hiệu quả. Điều gì thậm chí còn tồi tệ hơn nó có lẽ là không thể thay đổi mà không thay thế mặc định thực hiện vận tải WCF HTTP.

Cả chuyển hướng và xác thực được xử lý trực tiếp bên trong xử lý HTTP của WCF vốn là nội bộ. Bạn không thể xử lý chuyển hướng theo cách thủ công gây ra sự cố nếu bạn nhận được 301 Đã di chuyển vĩnh viễn và WCF không sử dụng thông tin xác thực ứng dụng được định cấu hình của bạn sau khi chuyển hướng.

Sự cố khi gửi GET thay vì POST sau khi chuyển hướng phải được giải quyết về mặt lý thuyết bằng cách trả lại 307 Chuyển hướng tạm thời thay vì 302 Tìm thấy.

+0

Tôi khá chắc chắn chúng tôi đã thử điều này và WCF không hiểu câu trả lời.Tôi hy vọng có những cách để đối phó với điều này trong 4.5 nhưng tôi đã không nhìn vào nó. –

Các vấn đề liên quan