Eastgroup.pl

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

W tej lekcji zajmiemy się tematyką uwierzytelniania – określaniem kto jest kim (potwierdzaniem tożsamości), czy szyfrowaniem. Uwierzytelnianie będzie obejmowało zarówno weryfikację klienta przez serwis, jak i serwisu przez klienta. WCF oferuje następujące mechanizmy uwierzytelniania:

• Brak uwierzytelniania (No authentication) – dostęp anonimowy bez potwierdzania tożsamości,
• Uwierzytelnianie Windows (Windows authentication) – Kerberos dla serwisów działających w ramach domeny Windows, Windows NT LAN (NTLM) dla grup roboczych i samodzielnych systemów,
• Nazwa użytkownika i hasło (Username and password) – klient dostarcza dane, serwis uwierzytelnia klienta na ich podstawie,
• Certyfikat X.509 (X.509 certificate) – klient identyfikuje się korzystając z certyfikatu,
• Wydane żetony (Issued tokens) – klient przekazuje żeton do serwisu, aby zidentyfikować nadawcę,
• Niestandardowy (Custom) – wykorzystanie własnych mechanizmów uwierzytelniania, np. danych biometrycznych.

Dane uwierzytelniające klienta

Podczas uwierzytelniania klienta należy określić, które informacje powinny zostać wykorzystane oraz jak powinny zostać dostarczone do serwisu. Możliwe wartości to: Certificate, IssuedToken, None, UserName i Windows. Nie wszystkie wartości są jednak odpowiednie dla wszystkich bindingów – basicHttpBinding wspiera jedynie opcje UserName i Certificate. Przykład deklaratywnego określenia typu uwierzytelniających danych:

   1: <binding name="myBinding">

   2:   <security mode="Message">

   3:     <message clientCredentialType="Certificate"/>

   4:   </security>

   5: </binding>

Uwierzytelnianie certyfikatem

Przykładowa konfiguracja przy uwierzytelnianiu klienta certyfikatem:

   1: <behaviors>

   2:  <serviceBehaviors>

   3:   <behavior name="ServiceCredentialsBehavior">

   4:    <serviceCredentials>

   5:     <serviceCertificate findValue="Contoso.com" x509FindType="FindBySubjectName" />

   6:    </serviceCredentials>

   7:   </behavior>

   8:  </serviceBehaviors>

   9: </behaviors>

Element serviceCredentials zawiera informacje na temat tego, jak klient będzie uwierzytelniany przez serwis.

Uwierzytelnianie żetonem

Główna idea stojąca za uwierzytelnianiem za pomocą żetonu jest pozwolenie firmom trzecim na potwierdzenie tożsamości klienta. W środowisku .NET przykładem wykorzystania jest usługa CardSpace. Przykładowy kod pliku konfiguracyjnego:

   1: <services>

   2:  <service name="UpdateService" behaviorConfiguration="ServiceCredentials">

   3:   <endpoint address="" binding="wsHttpBinding" bindingConfiguration="requireInfoCard" contract="IUpdateService" >

   4:    <identity>

   5:     <certificateReference findValue="545c3b8e97d99fd75c75eb52c6908320088b4f50" x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My" />

   6:    </identity>

   7:   </endpoint>

   8:  </service>

   9: </services>

  10:  

  11: <bindings>

  12:  <wsHttpBinding>

  13:   <binding name="requireInfoCard">

  14:    <security mode="Message">

  15:     <message clientCredentialType="IssuedToken" />

  16:    </security>

  17:   </binding>

  18:  </wsHttpBinding>

  19: </bindings>

  20:  

  21: <behaviors>

  22:  <serviceBehaviors>

  23:   <behavior name="ServiceCredentials">

  24:    <serviceCredentials>

  25:     <serviceCertificate findValue="545c3b8e97d99fd75c75eb52c6908320088b4f50" x509FindType="FindByThumbprint" storeLocation="LocalMachine" storeName="My" />

  26:     <issuedTokenAuthentication allowUntrustedRsaIssuers="true" />

  27:    </serviceCredentials>

  28:   </behavior>

  29:  </serviceBehaviors>

  30: </behaviors>

Element identity w sekcji endpoint pozwala różnym punktom końcowym dostarczać funkcjonalność uwierzytelniania dla serwisu. W tym przykładzie element certificateReference dostarcza szczegóły na temat tego, jakie mechanizmy uwierzytelniania zostaną wykorzystane.

Uwierzytelnianie systemu Windows

Uwierzytelnianie Windows jest domyślnie wykorzystywane do uwierzytelnianie klienta przy zabezpieczeniach na poziomie wiadomości. Ustawić ten typ uwierzytelniania można zarówno deklaratywnie, jak i imperatywnie. Poniżej przykład deklaratywny:

   1: <bindings>

   2:  <wsHttpBinding>

   3:   <binding name="messageSecurity">

   4:    <security mode="Message">

   5:     <message clientCredentialType="Windows"/>

   6:    </security>

   7:   </binding>

   8:  </wsHttpBinding>

   9: </bindings>

Przykład imperatywny:

   1: UpdateServiceClient proxy = new UpdateServiceClient();

   2: proxy.ClientCredentials.Windows.ClientCredential = CredentialCache.DefaultCredentials;

   3: proxy.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;

   4: proxy.ClientCredentials.Windows.AllowNtlm = false;

Atrybut allowImpersonationLevel określa typ podszywania się, które serwis może wykonać. Więcej na ten temat będzie można przeczytać w następnej lekcji.

Dane uwierzytelniające serwisu

Wspomniana była już możliwość wysyłania danych uwierzytelniających przez serwis do klienta. Przykładowa konfiguracja:

   1: <behaviors>

   2:  <serviceBehaviors>

   3:   <behavior name="serviceBehavior" >

   4:    <serviceCredentials>

   5:     <serviceCertificate findValue="RPKey" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" />

   6:    </serviceCredentials>

   7:   </behavior>

   8:  </serviceBehaviors>

   9: </behaviors>

Jeżeli klient potrzebuje zaszyfrować komunikat wysyłany do serwisu, musi mieć klucz publiczny certyfikatu. Może on zostać dostarczony ręcznie lub dostarczony na drodze negocjacji. Zachowanie to można ustawić za pomocą atrybutu negotiateServiceCredential, w elemencie message bindingu:

   1: <wsHttpBinding>

   2:  <binding name="wsHttp">

   3:   <security mode="Message">

   4:    <message clientCredentialType="Certificate" negotiateServiceCredential="true" />

   5:   </security>

   6:  </binding>

   7: </wsHttpBinding>

Uwierzytelnianie niestandardowe

Pomimo tego, że wbudowane metody uwierzytelnianie są pomocne, nie ma możliwości, aby były wystarczające w każdym możliwym przypadku. Dla takich przypadków mamy możliwość dostarczenia własnych mechanizmów uwierzytelniania. W tym celu tworzymy obiekt dziedziczący po UserNamePasswordValidator, w który przeciążamy metodę Validate. Jeżeli metoda się zakończy oznacza to, że dostarczone dane są poprawne. Jeżeli dane nie są poprawne należy zgłosił wyjątek SecurityTokenValidationException. Przykład:

   1: public class CustomAuthenticator : UserNamePasswordValidator

   2: {

   3:  public override void Validate(string userName, string password)

   4:  {

   5:   if (userName != "anyuser" || password != "good")

   6:     throw new SecurityTokenValidationException("Invalid credentials");

   7:  }

   8: }

Po utworzeniu klasy walidatora należy skonfigurować serwis tak, aby z niej korzystał:

   1: <serviceBehaviors>

   2:  <behavior name="CustomValidator">

   3:   <serviceCredentials>

   4:    <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType="ThisAssembly.CustomAuthenticator, ThisAssembly"/>

   5:    <serviceCertificate findValue="localhost" x509FindType="FindBySubjectName" storeLocation="CurrentUser" storeName="My" />

   6:   </serviceCredentials>

   7:  </behavior>

   8: </serviceBehaviors>