Uwierzytelnianie Windows

Drugim mechanizmem, jaki można wykorzystać w aplikacjach internetowych ASP.NET, jest uwierzytelnianie Windows. Ten sposób uwierzytelniania mocno różni się od opisanego wcześniej uwierzytelniania Forms. Użytkownik nie musi logować się samemu do aplikacji za pomocą formularza. System Windows automatycznie loguje się w aplikacji za pomocą konta Windowsowego aktualnie zalogowanego użytkownika.

Uwierzytelnianie Windows jest preferowanym sposobem uwierzytelniania za każdym razem, gdy użytkownik jest częścią domeny Windows lub z aplikacji mają korzystać użytkownicy znajdujący się w Intranecie (np. sieć firmowa). Ten sposób uwierzytelniania umożliwia wykorzystanie istniejącego zbioru tożsamości użytkowników, takich jak np. Active Directory, co w efekcie powoduje, że nie potrzebne jest przechowywanie i zarządzanie dodatkowym zbiorem danych użytkowników. Dodatkowo zbędne jest również przesyłanie hasła użytkownika przez sieć, co zawsze może nieść ryzyko jego przechwycenia przez niepowołane osoby.

Uwierzytelnianie Windows tak naprawdę określa tożsamość użytkownika oraz ją weryfikuje, nie na poziomie aplikacji ASP.NET, jak to ma miejsce w uwierzytelnianiu Forms. Tym wszystkim zajmuje się Microsoft Internet Information Services (IIS) . IIS po określeniu oraz weryfikacji tożsamości użytkownika przekazuje ją do aplikacji ASP.NET.

Internet Information Services udostępnia kilka mechanizmów pozwalających na zweryfikowanie tożsamości użytkownika.  Są to:

  • Anonimowe uwierzytelnianie
  • Zintegrowane z Windows (NTLM, Kerberos)
  • Basic
  • Digest
  • Oparte o certyfikaty klienta.

Uwierzytelnianie Windows jest domyślnym mechanizmem autoryzacji w aplikacjach ASP.NET. Jest zdefiniowana za pomocą atrybutu mode elementu authentication  w pliku konfiguracyjnym web.config. Na listingu przykładowy fragment web.configa:

   1: <system.web>
   2:   <authentication mode="Windows"/>
   3: </system.web>

W poniższych podrozdziałach zostaną scharakteryzowane wcześniej wspomniane metody określenia tożsamości przez serwer WWW IIS. Z racji, że tematem pracy są mechanizmy uwierzytelniania oraz autoryzacji użytkowników w aplikacjach ASP.NET, a nie IIS, w pracy zostaną tylko pobieżnie opisane. Zostaną również przedstawione plusy i minusy mechanizmów uwierzytelniania na poziomie serwera IIS. Szczegółowe informacje o tym mechanizmach znajdują się na stronach dokumentacji, do których będą prowadzić przypisy.

Anonymous

Uwierzytelnianie Anonymous  umożliwia użytkownikowi dostęp do publicznych części aplikacji bez wymagania od niego loginu oraz hasła. Chociaż widnieje na liście sposób uwierzytelniania przez IIS, tak naprawdę nie jest wymagane od użytkownika potwierdzanie tożsamości.

Za:

  • Oferuje najlepszą wydajność, ponieważ uwierzytelnianie anonimowe nie nakłada dodatkowego obciążenia;
  • Nie wymaga zarządzania kontami użytkowników;
  • Jeśli IIS nie kontroluje hasła, każdy użytkownika ma dostęp do zasobów sieci;

Przeciw:

  • Nie uwierzytelnia klientów w sposób indywidualny;
  • Jeśli IIS nie kontroluje hasła, konto musi mieć możliwość logowania lokalnego;

Basic

IIS umożliwia wykorzystanie mechanizmu uwierzytelniania typu Basic , który jest częścią specyfikacji protokołu HTTP 1.0. Kiedy programista używa uwierzytelniania Basic przeglądarka przesyła login oraz hasło konta Windows użytkownika. Dane te są przesyłane przez  HTTP, gdzie są kodowane za pomocą algorytmu BASE64 . Mimo, że większość web serwisów, serwerów proxy, czy przeglądarek obsługuje uwierzytelnianie Basic, to niestety sposób ten jest mało bezpieczny. BASE64 jest łatwe do rozkodowania, co w gruncie rzeczy powoduje, że hasło jest przesyłane czystym tekstem.

Za:

  • Ponieważ uwierzytelnianie Basic jest częścią standardu HTTP 1.0, jest powszechnie wspieranym sposobem uwierzytelniania;
  • Umożliwia uwierzytelnianie użytkowników wykorzystujących serwer proxy;
  • Umożliwia śledzenie poczynań użytkownika, dzięki czemu można zbierać indywidualne statystyki korzystania z witryny;
  • Może być połączony z uwierzytelnianiem Kerberos;

Przeciw:

  • Z natury jest słabo zabezpieczony bez wykorzystania szyfrowania połączenia, co z kolei może rzutować na wydajność;
  • Wymaga tworzenie indywidualnych kont Windows dla każdego użytkownika;

Digest

Mechanizm uwierzytelniania Digest zostało stworzone głównie w celu rozwiązania największej słabości uwierzytelniania Basic: wysyłanie hasła w czystym tekście. Mechanizm uwierzytelniania Digest w celu uwierzytelniania wykorzystuje hashe. Hash jest wynikiem (o stałej długości pewnej) funkcji matematycznej (zwanej funkcją hashującą) na dowolnej ilości danych. Poziom szyfrowania zależy od długości wykorzystywanego hasha.

Jeżeli użytkownik próbuje uzyskać dostęp do zasobu, do którego jest wymagane uwierzytelnianie Digest, IIS wysyła do użytkownika żądanie przesłania hasha. Klienta za pomocą owej funkcji hashującej łączy hasło oraz dane znane dla obu stron (klienta i serwera). Klient wykorzystuje sposób łączenie danych określony przez serwer. Klient w odpowiedzi wysyła serwerowi hash. Serwer po swojej stronie wykonuje te same operacje (na haśle użytkownika wyciągniętym np. z Active Directory). W przypadku, gdy oba hashe (wysłany przez klienta oraz obliczony przez serwer) są takie same, użytkownik zostaje uwierzytelniony.

Uwierzytelnianie Digest jest niewielką poprawą bezpieczeństwa w stosunku do uwierzytelniania Basic. W przypadku braku wykorzystywania szyfrowania połączenia, atakujący może podsłuchać komunikację między klientem oraz serwerem. Następnie może użyć zebrane informacje w celu powtórzenia komunikacji.

Za:

  • Przesyłany jest hash zamiast hasła przez sieć;
  • Współpracuje z serwerami proxy i zaporami sieciowymi;
  • Nie jest wymagane szyfrowanie połączeń w celu ochrony hasła użytkownika;

Przeciw:

  • Nie umożliwia delegowania poświadczeń bezpieczeństwa;
  • Jest wspierane przez przeglądarkę Internet Explorer w wersji 5.0 lub nowszej;
  • Jest narażony na ataki w przypadku nieużywania szyfrowania połączeń;
  • Wymaga przechowywania hasła za pomocą odwracalnych algorytmów szyfrowania (do obliczenia hasha jest potrzebne hasło w pierwotnej postaci);
  • Wymaga stworzenia indywidualnego konta dla użytkownika w Active Directory;

Integrated Windows Authentication

Uwierzytelnianie zintegrowane z Windows (Integrated Windows Authentication) umożliwia użycie mechanizmu NTLM lub Kerberos i działa tylko w przeglądarce Internet Explorer 2.0 lub nowszej.
W przypadku uwierzytelniania zintegrowanego z Windows, kiedy Internet Explorer próbuje uzyskać dostęp do chronionych zasobów, IIS wysyła dwa nagłówki uwierzytelniające Negotiate oraz NTLM:

  • Jeżeli Internet Explorer rozumie nagłówek Negotiate, skorzysta z tego nagłówka. Używając Negotiate przeglądarka zwróci serwerowi informacje dla uwierzytelniania NTLM oraz Kerberos. Po stronie serwera IIS użyje uwierzytelniania Kerberos w przypadku, gdy klient korzysta z Internet Explorera 5.0 lub nowszego, IIS jest w wersji 5.0 lub nowszej uruchomiony na systemie Windows 2000 lub nowszym oraz obie strony są członkami tych samych domen lub domen zaufanych. W przeciwnym przypadku serwer będzie wykorzystywał uwierzytelnianie NTLM
  • Jeżeli natomiast Internet Explorer nie rozumie nagłówka Negotiate, użyte zostanie uwierzytelnianie NTLM

Jak widać mechanizm, jaki zostanie użyty zależy od negocjacji serwera z przeglądarką.
Kiedy w połączeniu jest używany mechanizm uwierzytelniania Kerberos, IIS może przekazywać poświadczenie bezpieczeństwa wśród komputerów z systemem Windows 2000 lub nowszych, które są zaufane oraz konfigurowane do delegacji. Delegacja umożliwia dostęp do zdalnych zasobów w imieniu delegacji użytkownika.

Uwierzytelnianie zintegrowane z Windows jest najlepszym mechanizmem uwierzytelniania w środowisku Intranetowym, gdzie użytkownicy posiadają konta w domenie Windows zwłaszcza, kiedy używane jest uwierzytelnianie Kerberos.

Za:

  • Może zostać użyte z połączeniu z Kerberos, dzięki czemu istnieje możliwość delegowania poświadczeń bezpieczeństwa;
  • Najlepszy mechanizm dla aplikacji działających w środowisku Intranetowym;

Przeciw:

  • Nie można uwierzytelniać użytkownika przez zaporę sieciową chyba, że przez stosowanie połączenia PPTP;
  • Nie wspiera delegacji poświadczeń bezpieczeństwa w przypadku, gdy używamy jest mechanizm NTLM;
  • Jest obsługiwany przez Internet Explorer 2.0 lub nowszy;
  • Kerberos jest obsługiwany przez IIS 5.0 lub nowszy;

Client Certificate Mapping

Mechanizm uwierzytelniania Client Certificate Mapping wykorzystuje mechanizm certyfikatów w celu zabezpieczenia całego procesu uwierzytelniania. Certyfikat jest podpisanym cyfrowo poświadczeniem, że zawiera informacje na temat jednostki oraz jest publicznym kluczem. Zaufana organizacja nazwana Urzędem Certyfikacji wydaje certyfikat po sprawdzeniu, czy podmiot jest tym, za kogo się podaje. Certyfikaty mogą zawierać różne dane.

Systemy operacyjne takie jak Windows nadal wymagają pojęcia konta użytkownika. Mapowanie certyfikatów umożliwia administratorowi na powiązanie pojedynczego certyfikatu (mapowanie jeden do jednego) lub kilku certyfikatów (mapowanie wiele do jednego)  do konta użytkownika. Mapowanie wiele do jednego określa zasady do definiowania kryteriów certyfikatów do mapowania.

IIS używa protokołu SSL / TLS do uwierzytelnienia serwera i zapewnia szyfrowanie sesji HTTP. IIS może również skorzystać z protokołu SSL / TLS w celu uwierzytelnienia użytkownika. W tym celu wymaga od niego przedstawienia zaświadczenia. Przy żądaniu certyfikatu klienta, serwer przedstawia klientowi listę urzędów, którym wierzy. Lista ta z serwerowej listy zaufanych certyfikatów (CTL). Jeżeli klient posiada certyfikat wydany przez urząd certyfikacji z listy dostarczonej przez serwer, wysyła kopię poświadczenia do serwera w celu weryfikacji. Jeśli certyfikat jest ważny, IIS uwierzytelnia użytkownika, którego mapuje na podstawie świadectwa.

Za:

  • Dostarcza bezpieczny sposób uwierzytelniania użytkowników;
  • Zapewnia obustronne uwierzytelnianie klienta i serwera;
  • Umożliwia dostęp do sieciowych zasobów;

Przeciw:

  • Nie umożliwia przekazywania poświadczenia bezpieczeństwa;
  • Nie współpracuje z wszystkimi przeglądarkami;
  • Wymaga szyfrowania SSL / TLS;
  • Jest trudne w konfiguracji, jednakże mapowanie wiele do jednego jest łatwiejsze niż jeden do jednego;
Tags: , , ,
Categories: Techniczne

Permalink E-mail | Kick it! | DZone it! | del.icio.us Komentarze (0) Post RSSRSS comment feed

Dodaj komentarz


(Będzie pokazywało Gravatar ikon)

  Country flag

biuquote
  • Komentarz
  • Przegląd
Loading