2010-08-19 30 views
8

Tôi đang sử dụng dịch vụ wcf mà tôi đã tạo, khi cả máy lưu trữ và máy khách nằm trên cùng một miền, mọi thứ hoạt động tốt. Khi tôi xuất bản ứng dụng máy khách đến máy chủ web trong DMZ Tôi nhận được lỗi sau:WCF Thỏa thuận Giao diện Nhà cung cấp Hỗ trợ Bảo mật (SSPI) không thành công

SOAP security negotiation with 'http://10.0.0.14:3790/Bullfrog/QBService/QBService' for 
target 'http://10.0.0.14:3790/Bullfrog/QBService/QBService' failed. See inner exception 
for more details.The Security Support Provider Interface (SSPI) negotiation failed. 

Đây là dịch vụ của tôi chính nơi tôi thiết lập dịch vụ

 Uri baseAddress = new Uri("Http://10.0.0.14:3790/Bullfrog/QBService"); 
     ServiceHost selfHost = new ServiceHost(typeof(QBService), baseAddress); 

      try 
      { 
       selfHost.AddServiceEndpoint(
        typeof(IQBService), 
        new WSHttpBinding(), 
        "QBService"); 

       ServiceMetadataBehavior smb = new ServiceMetadataBehavior(); 
       smb.HttpGetEnabled = true; 
       selfHost.Description.Behaviors.Add(smb); 
       selfHost.Open(); 

       Console.WriteLine("The service is ready"); 


      } 
      catch (CommunicationException ce) 
      { 
       //log.Error(ce.Message, ce); 
       Console.WriteLine(ce.Message, ce); 
       selfHost.Abort(); 
      } 

và đây là cấu hình phần trên thân chủ tôi

<system.serviceModel> 
<bindings> 
    <wsHttpBinding> 
    <binding name="WSHttpBinding_IQBService" closeTimeout="00:01:00" 
     openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" 
     bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard" 
     maxBufferPoolSize="524288" maxReceivedMessageSize="65536" 
     messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true" 
     allowCookies="false"> 
     <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" 
      maxBytesPerRead="4096" maxNameTableCharCount="16384" /> 
     <reliableSession ordered="true" inactivityTimeout="00:10:00" 
      enabled="false" /> 
     <security mode="Message"> 
     <transport clientCredentialType="Windows" proxyCredentialType="None" 
      realm="" /> 
     <message clientCredentialType="Windows" negotiateServiceCredential="true" 
      algorithmSuite="Default" /> 
     </security> 
    </binding> 
    </wsHttpBinding> 
</bindings> 
<client> 
    <endpoint address="http://10.0.0.14:3790/Bullfrog/QBService/QBService" 
     binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IQBService" 
     contract="IQBService" name="WSHttpBinding_IQBService"> 
    <identity> 
     <userPrincipalName value="[email protected]" /> 
    </identity> 
    </endpoint> 
</client> 

tôi chắc chắn các vấn đề là bởi vì nó đang sử dụng xác thực cửa sổ. Bất kỳ ý tưởng? Cảm ơn bạn!

+0

Tôi không chắc chắn 100% vì vậy tôi không đăng câu trả lời này nhưng xác thực Windows IMO chỉ có thể thực hiện được nếu cả máy khách và máy chủ nằm trong cùng miền hoặc trong miền đáng tin cậy. Btw. nếu cả mạng nội bộ và DMZ là một phần của cơ sở hạ tầng doanh nghiệp của bạn thì tại sao bạn chọn WsHttpBinding với bảo mật thư? Đó là sự lựa chọn chậm nhất. –

+0

nếu cả hai mạng nội bộ và DMZ là một phần của cơ sở hạ tầng doanh nghiệp của bạn tại sao bạn chọn WsHttpBinding với bảo mật thư? - bởi vì tôi không biết bất kỳ cách nào khác :) Tôi nên sử dụng? Như đã đề cập, tôi chắc chắn rằng đó là xác thực cửa sổ đang gây ra sự cố. Vậy tôi cần phải sử dụng cái gì? Cảm ơn! – twal

Trả lời

7

Tôi không nghĩ rằng điều này sẽ làm việc và tôi không có môi trường để nhanh chóng kiểm tra nó. SSPI sử dụng NTLM hoặc Kerberos (bắt buộc nếu thỏa thuận thông tin đăng nhập dịch vụ không được sử dụng) để xác thực dịch vụ trên máy khách và ứng dụng khách trên dịch vụ. Cả NTLM và Kerberos đều mong đợi cùng một miền hoặc miền đáng tin cậy.

Nếu bạn muốn sử dụng bảo mật thư, bạn có thể thay đổi cấu hình để sử dụng chứng chỉ hoặc tên người dùng + mật khẩu (dịch vụ sẽ vẫn yêu cầu chứng chỉ). Bạn có thể xác thực tên người dùng và mật khẩu trong thư mục hoạt động hoặc trong bất kỳ cửa hàng thông tin xác thực nào khác.

Hãy nhớ rằng bảo mật thư là thư chậm nhất. Hiệu suất tốt hơn có thể đạt được với an ninh giao thông (HTTPS) - nó có thể được tăng tốc bởi các thiết bị mạng. Nếu bạn sử dụng HTTPS, bạn có thể kết hợp nó với xác thực cơ bản và cung cấp thông tin đăng nhập của khách hàng từ mã của bạn để bạn sẽ gọi dịch vụ trong vùng nội bộ của mình và bạn sẽ sử dụng thông tin đăng nhập miền để xác thực. Dịch vụ sẽ được xác thực bằng chứng chỉ được sử dụng cho HTTPS. HTTPS cũng cho phép xác thực chứng chỉ mutal khi máy khách gửi chứng chỉ đến dịch vụ - nếu chứng chỉ máy khách được cấu hình đúng có thể được ánh xạ tới tài khoản miền. Hai cách tiếp cận này tương tự như các phương pháp được đề cập trong bảo mật thư nhưng thay vì gửi thông tin đăng nhập trong tiêu đề HTTP tiêu đề SOAP được sử dụng.

+0

Cảm ơn bạn! Tôi đánh giá cao sự giúp đỡ của bạn về điều này.! Tôi nhận được nó làm việc với các ràng buộc cơ bản. Mặc dù tôi có lẽ sẽ cần phải thêm bảo mật cho nó trước khi đi với nó. Tôi không biết, nguy cơ và nhu cầu bảo mật là gì khi máy chủ đứng sau tường lửa và máy khách duy nhất nằm trong DMZ? – twal

+0

Tùy thuộc vào cấu trúc mạng của bạn. Nếu bạn có thể truy cập trực tiếp vào dịch vụ (không có proxy), bạn có thể sử dụng HTTPS mà không gặp bất kỳ vấn đề gì. Nếu bạn truy cập dịch vụ thông qua một số proxy ứng dụng như máy chủ ISA, bạn sẽ có kết nối HTTPS riêng biệt giữa máy khách và ISA và một kết nối khác giữa ISA và dịch vụ.Tin nhắn sẽ không được bảo mật trên máy chủ ISA nhưng thường không phải là vấn đề vì máy chủ ISA nằm dưới sự kiểm soát của bạn. –

1

Tôi nghĩ bạn nên bình luận đoạn mã sau trong web.config của bạn

<identity> 
     <userPrincipalName value="[email protected]" /> 
</identity> 

vì nó giải quyết vấn đề của tôi.

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