2010-08-19 21 views
8

Her iki barındırma makinesi ve istemci makine aynı etki alanında olduğunda, oluşturduğum bir wcf hizmeti kullanıyorum her şey gayet iyi çalışıyor. Ben DMZ'deki aşağıdaki hatayı alıyorum web sunucusu istemci uygulama yayınladığınızda : Burada WCF Güvenlik Destek Sağlayıcısı Arabirimi (SSPI) anlaşması başarısız oldu

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. 

burada hizmet

 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(); 
      } 

kurmak nerede hizmet ana ve yapılandırma olduğunu Müvekkilim bölüm

<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> 

eminim sorun, windows kimlik doğrulaması kullanıyor olmasıdır. Herhangi bir fikir? Teşekkür ederiz!

+0

% 100 emin değilim, bu yüzden bir yanıt olarak bunu göndermiyorum ama IMO Windows kimlik doğrulaması yalnızca hem istemci hem de sunucu aynı etki alanında veya güvenilir etki alanlarındaysa mümkündür. Btw. Hem dahili ağ hem de DMZ, kurumunuzun bir parçasıysa, neden WsHttpBinding'i mesaj güvenliği ile seçtiniz? Bu en yavaş seçimdir. –

+0

hem dahili ağ hem de DMZ sizin kurumunuzun bir parçasıysa, neden WsHttpBinding'i mesaj güvenliği ile seçtiniz? - çünkü başka bir yol bilmiyorum :) Hangisini kullanmalıyım? Belirtildiği gibi, sorunun neden olduğu Windows kimlik doğrulaması olduğundan eminim. Peki bunun yerine ne kullanmalıyım? Teşekkürler! – twal

cevap

7

Bunun işe yaramayacağını düşünüyorum ve hızlı bir şekilde test etmek için ortamım yok. SSPI, istemcideki ve hizmetteki istemcinin hizmetini doğrulamak için NTLM veya Kerberos (hizmet kimlik bilgileri anlaşması kullanılmıyorsa zorunludur) kullanır. Hem NTLM hem de Kerberos aynı alan adı veya güvenilir alan adı bekliyor.

Mesaj güvenliğini kullanmak istiyorsanız, sertifika veya kullanıcı adı + şifresi kullanmak için yapılandırmanızı değiştirebilirsiniz (servis yine de sertifika gerektirecektir). Etkin dizinde veya başka bir kimlik deposunda kullanıcı adı ve şifreyi doğrulayabilirsiniz.

İleti güvenliğinin en yavaş olanı olduğunu unutmayın. Taşıma güvenliği (HTTPS) ile daha iyi performans elde edilebilir - ağ aygıtları tarafından hızlandırılabilir. HTTPS kullanıyorsanız, bunu Temel kimlik doğrulaması ile birleştirebilir ve kodunuzdan istemci kimlik bilgilerini sağlayabilirsiniz, böylece iç bölgenizde hizmet arayacaksınız ve kimlik doğrulama için alan adı kimlik bilgilerini kullanacaksınız. Hizmet, HTTPS için kullanılan sertifikayla doğrulanacaktır. HTTPS ayrıca, istemcinin hizmete sertifika gönderdiği durumlarda mutant sertifika kimlik doğrulamasına da izin verir - doğru yapılandırılmış istemci sertifikası, etki alanı hesabına eşlenebilir. Bu iki yaklaşım, mesaj güvenliğindeki bahsedilen yaklaşımlara benzer, ancak SOAP üstbilgisinde HTTP üstbilgisinde kimlik bilgilerini göndermek yerine kullanılır.

+0

Teşekkürler! Bunun için yardımın için minnettarım. Temel Bağlama ile çalışıyorum. Bununla birlikte, onunla yaşamamadan önce muhtemelen ona güvenlik eklemem gerekecek. Bilmiyorum, ana bilgisayar güvenlik duvarının arkasında ve tek müşteri DMZ'de olduğunda güvenlik ve güvenlik ihtiyacı nedir? – twal

+0

Ağ mimarinize bağlıdır. Doğrudan servise erişebiliyorsanız (proxy olmadan) HTTPS'yi sorunsuz kullanabilirsiniz. ISA sunucusu gibi bir uygulama proxy'si üzerinden hizmete erişirseniz, istemci ve ISA ile ISA ile servis arasında bir başka HTTPS bağlantınız olacaktır.İleti ISA sunucusunda güvende olmayacak ancak ISA sunucusu sizin kontrolünüz altında olduğu için genellikle sorun değil. –

1

ben size web.config benim sorun çözüldü olarak

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

aşağıdaki kodu yorum gerekir düşünün.

İlgili konular