70-503: Transport-Level Security

Ten artykuł pochodzi z serii przygotowań do egzaminu 70-503: Windows Communication Foundation.

Bezpieczeństwo tworzonych serwisów to podstawowa sprawa, która powinna odgrywać znaczącą już od samego początku projektu. W tym artykule skupimy się na bezpieczeństwie związanym z infrastrukturą – jak ograniczyć dostęp nieuwierzytelnionym użytkowników. Większość bindingów ma wbudowane możliwości związane z bezpieczeństwem – może to być SSL, IPsec, może też ich nie być wcale. wsDualHttpBinding to przykładowy binding, który nie wspiera zabezpieczeń na poziomie transportu. Wiąże się to z zasadą jego działania.

Artykuł ten skupia się na możliwościach WCF związanych z bezpieczeństwem, oraz biningach, które je obsługują.

Główne zadania bezpieczeństwa w WCF, to zagwarantowanie:

  • Uwierzytelnienia nadawcy
  • Uwierzytelnienie serwisu
  • Spójność komunikatu
  • Tajność komunikatu
  • Rozpoznawanie odpowiedzi

Bezpieczeństwo oferowane przez WCF wykorzystuje wiele istniejących rozwiązań, jak np. SSL, Kerberos, czy Active Directory Domain Services (AD DS). To, które z nich są wykorzystywane zależy od wybranego bindingu.

basicHttpBinding

Celem stworzenia basicHttpBinding jest zapewnienie kompatybilności z istniejącymi rozwiązaniami, takimi jak ASP.NET Web Services, czy WSE. Jest to jedyne rozwiązanie, które nie jest zabezpieczone w domyślnej konfiguracji. Zachowanie to można jednak zmienić zarówno w kodzie, jak i w pliku konfiguracyjnym. Poniższy przykład przedstawia deklaratywny sposób konfiguracji:

   1: <basicHttpBinding>
   2:   <binding name="TransportBinding">
   3:     <security mode="Transport">
   4:       <transport clientCredentialType="Basic"
   5:         proxyCredentialType="Basic"
   6:         realm="contoso" />
   7:     </security>
   8:   </binding>
   9: </basicHttpBinding>

Element security ma ustawiony tryb na Transport. Informuje nas to, że wykorzystane zostaną zabezpieczenia na poziomie transportu komunikatów, żądania będą pojawiały się przez połączenia SSL. Atrubuty elementu transport opisane są poniżej:

  • clientCredentialType - określa w jaki sposób będzie następowało uwierzytelnianie. Możliwe wartości to: Basic, Certificate, Digest, None, Ntlm i Windows.
  • proxyCredentialType – typ uwierzytelniania żądania za pomocą serwerów pośredniczących. Możliwe wartości: Basic, Digest, None, Ntlm, Windows.
  • realm – określa domenę, która zostanie wykorzystana, gdy uwierzytelnianie przyjmuje typ Basic, lub Digest.

Poniżej zaprezentowany został kod tworzący binding oraz konfigurujący go w sposób imperatywny:

   1: BasicHttpBinding binding = new BasicHttpBinding();
   2: binding.Name = "TransportBinding";
   3: binding.Security.Mode = BasicHttpSecurityMode.Transport;

wsHttpBinding

Binding ten wykorzystuje protokół HTTP (dokładniej HTTPS) do komunikacji. W przeciwieństwie do basicHttpBinding, serwis z którym się komunikujemy musie wspierać SOAP v1.2 oraz WS-Addressing.

Konfiguracja w pliku XML:

   1: <wsHttpBinding>
   2:   <binding name="TransportBinding">
   3:     <security mode="Transport">
   4:       <transport clientCredentialType="Basic"
   5:         proxyCredentialType="Basic"
   6:         realm="contoso" />
   7:     </security>
   8:   </binding>
   9: </wsHttpBinding>

Konfiguracja w kodzie:

   1: WSHttpBinding binding = new WSHttpBinding();
   2: binding.Name = "TransportBinding";
   3: binding.Security.Mode = SecurityMode.Transport;

netTcpBinding

Jak sama nazwa wskazuje nie wykorzystuje się tu HTTP, a TCP.

Konfiguracja w pliku XML:

   1: <netTcpBinding>
   2:   <binding name="TransportBinding">
   3:     <security mode="Transport">
   4:       <transport clientCredentialType="Windows"
   5:         protectionLevel="EncryptAndSign" />
   6:     </security>
   7:   </binding>
   8: </netTcpBinding>

Atrybut clientCredentialType określa mechanizm, który zostanie wykorzystany w celu uwierzytelnienia. Możliwe wartości:

  • Certificate – w celu uwierzytelnienia żądania dostarczany jest certyfikat,
  • None – żądania traktowane są jako anonimowe,
  • Windows – wykorzystane zostaną mechanizmy systemu Windows.

Atrybut protectionLevel pozwala określić sposób, w jaki będą szyfrowane komunikaty:

  • None – komunikat nie będzie kodowany,
  • Sign – komunikat jest podpisany cyfrowo, jednak nie jest szyfrowany,
  • EncryptAndSign – szyfrowanie oraz podpisanie w sposób cyfrowy.

To, co możemy skonfigurować w pliku XML można zrobić także przez kod:

   1: NetTcpBinding binding = new NetTcpBinding();
   2: binding.Name = "TransportBinding";
   3: binding.Security.Mode = SecurityMode.Transport;
   4: binding.Security.Transport.ClientCredentialType =
   5: TcpClientCredentialType.Windows;

netNamedPipeBinding

Nazwane potoki (ang. named pipes) są zopytmalizowane pod kątem komunikacji między procesami w ramach jednej maszyny. Implementacja związana z zabezpieczeniami jest niemal taka sama jak w przypadku netTcpBinding. Główna różnica jest taka, że TCP ma kilka dodatkowych funkcji. Poniższa konfiguracje demonstruje różnice:

   1: <netNamedPipeBinding>
   2:   <binding name="TransportBinding">
   3:     <security mode="Transport">
   4:       <transport protectionLevel="EncryptAndSign" />
   5:     </security>
   6:   </binding>
   7: </netNamedPipeBinding>

Konfiguracja przez kod:

   1: NetNamedPipeBinding binding = new NetNamedPipeBinding();
   2: binding.Name = "TransportBinding";
   3: binding.Security.Mode = NetNamedPipeSecurityMode.Transport;

msmqIntegrationBinding

Metoda zoptymalizowana pod kątem klientów w WCF, które komunikują się z serwisami MSMQ, które nie są napisane w WCF. Ten binding daje możliwość wykorzystania uwierzytelniania systemu Windows, w tym także AD DS. Wymagane jest, by klient i serwis znajdowały się w tej samej domenie. MSMQ daje możliwość dołączenia do komunikatu certyfikatu, który ma zapewnić, że komunikat został nim podpisany. Przykład:

   1: <msmqIntegrationBinding>
   2:   <binding name="TransportBinding">
   3:     <security mode="Transport">
   4:       <transport msmqAuthenticationMode="WindowsDomain"
   5:         msmqEncryptionAlgorithm="AES"
   6:         msmqProtectionLevel="EncryptAndSign"
   7:         msmqSecureHashAlgorithm="SHA1" />
   8:     </security>
   9:   </binding>
  10: </msmqIntegrationBinding>

Atrybut msmqAuthenticationMode kontroluje, w jaki sposób użytkownik zostanie uwierzytelniony. Pozostałe trzy atrybuty dotyczą zabezpieczania samego komunikatu.

Konfiguracja przez kod:

   1: MsmqIntegrationBinding binding = new MsmqIntegrationBinding();
   2: binding.Name = "TransportBinding";
   3: binding.Security.Mode = MsmqIntegrationSecurityMode.Transport;
   4: binding.Security.Transport.MsmqAuthenticationMode = MsmqAuthenticationMode.WindowsDomain;

netMsmqBinding

Wykorzystuje ten sam protokół, co msmqIntegrationBinding (MSMQ). Różnica polega na tym, że serwis docelowy będzie zaimplementowany w WCF. Konfiguracja jest praktycznie identyczna do tej w msmqIntegrationBinding:

   1: <netMsmqBinding>
   2:   <binding name="TransportBinding">
   3:     <security mode="Transport">
   4:       <transport msmqAuthenticationMode="WindowsDomain "
   5:         msmqEncryptionAlgorithm="AES"
   6:         msmqProtectionLevel="EncryptAndSign"
   7:         msmqSecureHashAlgorithm="SHA1" />
   8:     </security>
   9:   </binding>
  10: </netMsmqBinding>

Przez kod:

   1: NetMsmqBinding binding = new NetMsmqBinding();
   2: binding.Name = "TransportBinding";
   3: binding.Security.Mode = NetMsmqSecurityMode.Transport;
   4: binding.Security.Transport.MsmqAuthenticationMode = MsmqAuthenticationMode.WindowsDomain;

W następnym artykule przestawione zostaną zabezpieczenia na poziomi komunikatu.

Tagi: , , , ,

Add comment




  Country flag
biuquote
  • Comment
  • Preview
Loading


Eastgroup.pl na facebooku