Autentykacja użytkowników typu Form na serwerze Tomcat

Transkrypt

1 Autentykacja użytkowników typu Form na serwerze Tomcat Małgorzata Tałaj, Marta Lewandowska, Piotr Kopniak Koło Naukowe Pentagon Café Instytut Informatyki Politechnika Lubelska Artykuł prezentuje możliwości deklaratywnej autentykacji użytkownika specyfikowanej przez standard J2EE (Java 2 Enterprise Edition) ze szczególnym uwzględnieniem autentykacji typu Form. Opracowanie zawiera także opis implementacji autentykacji i szyfrowania transmisji na serwerze aplikacji internetowych Tomcat. Wstęp Dwa podstawowe aspekty zapewnienia bezpieczeństwa aplikacji internetowej to zabezpieczenie przed dostępem do poufnych danych przez nieuprawnionych użytkowników Internetu oraz zabezpieczenie przed odczytem informacji przesyłanych przez sieć podczas komunikacji z użytkownikiem zdalnym. Pierwszy aspekt jest spełniany poprzez autentykację użytkownika próbującego uzyskać dostęp do chronionych zasobów polegającej w najprostszym przypadku na weryfikacji hasła podanego przez użytkownika. Hasło wraz z nazwą użytkownika podawane jest zwykle w formularzu na stronie WWW lub oknie dialogowym wyświetlonym przez przeglądarkę internetową, przesyłane na serwer i weryfikowane z hasłem przechowywanym na serwerze. Silniejszą autentykacją zapewniającą większą pewność, co do tego, kim jest dany użytkownik jest wykorzystanie certyfikatów (najczęściej w standardzie X509 [1,2]). Bezpieczeństwo komunikacji zapewniane jest dzięki szyfrowaniu przesyłanych danych przez. Najczęściej w aplikacjach internetowych wykorzystywane jest szyfrowanie asymetryczne poprzez SSL (Secure Socjet Layer) oparte na dwóch kluczach prywatnym i publicznym. Klucz publiczny jest zawarty w certyfikacie pobranym z serwera i służy do szyfrowania danych wysyłanych od klienta do i deszyfrowaniu danych otrzymanych z serwera. Klucz prywatny jest kluczem poufnym i jest wykorzystywany do szyfrowania i deszyfrowania transmisji po stronie serwera [2]. W dalszej części opracowania opisane zostaną metody autentykacji użytkowników według specyfikacji J2EE [3] oraz ich implementacja na serwerze Tomcat. Przedstawiony zostanie także sposób konfiguracji serwera i aplikacji umożliwiający szyfrowaną transmisję danych poprzez SSL. Autentykacja użytkowników Autentykacja użytkowników może zostać zaimplementowana na poziomie serwera WWW) lub poprzez bezpośrednie przeniesienie wymogu zapewnienia bezpieczeństwa na składniki aplikacji, czyli poszczególne strony JSP lub servlety. Pierwszy sposób wprowadzania zabezpieczeń zwany jest deklaratywnym (co jest tematem niniejszego opracowania), drugi zaś zwany jest programistycznym.

2 Autentykacja w systemach WWW może być zaimplementowana na kilka sposobów w związku z tym można wyróżnić cztery typy autentykacji [3,4]: HTTP Basic - podstawowa metoda, najczęściej stosowana, nieszyfrowana, wykorzystująca okno logowania przeglądarki, HTTP Digest - bezpieczniejsza od Basic, dane kodowane funkcją skrótu, rzadko stosowana HTTPS- metoda bazująca na certyfikatach, wykorzystująca protokół HTTP szyfrowany po SSL Typu FORM- metoda umożliwiająca użytkownikowi samodzielne stworzenie stron logowania i błędu HTTP Basic Autentykacja HTTP Basic jest najprostszą formą autentykacji. Polega ona na przesłaniu do serwera WWW pobranych przez przeglądarkę nazwy użytkownika i hasła, które następnie zostają porównane z danymi użytkowników (nazwa użytkownika - login i hasło) znajdującymi się w bazie danych. Podczas próby dostępu do zasobów zdefiniowanych na serwerze WWW jako zabezpieczone, serwer przesyła do przeglądarki polecenie pobrania nazwy użytkownika i hasła. Użytkownik wprowadza dane, które są następnie przesyłane do serwera. Zapamiętanie stanu realizowane jest zwykle poprzez mechanizm ciasteczek (ang. cookies). Procesy zachodzące podczas autentykacji typu Basic przedstawia rys.1. Rys1. Schemat autentykacji typu HTTP Basic. Definicja zabezpieczonych zasobów na serwerze Tomcat, które mają być dostępne tylko dla zweryfikowanych użytkowników, w przypadku autentykacji typu Basic polega na dodaniu do pliku konfiguracyjnego aplikacji web.xml, znajdującego się w katalogu WEB-INF aplikacji WWW, następującego znacznika konfiguracji logowania: <login-config> <auth-method>basic</auth-method> </login-config> Metoda HTTP Basic nie jest jednak bezpiecznym sposobem autentykacji. Problem polega na tym, że przesyłane poprzez sieć hasła są kodowane za pomocą powszechnie znanej metody Base64 [5]. Ponadto serwer WWW nie podlega

3 jakiejkolwiek autentykacji (użytkownik nie ma pewności czy komunikuje się z odpowiednim serwerem). Może to prowadzić do przechwycenia poufnych danych użytkownika. Z tego powodu wraz z tą metodą stosowany jest bezpieczny mechanizm przesyłu taki jak transmisja szyfrowana dzięki SSL bądź zabezpieczenia na poziomie sieci: IPSEC lub VPN. HTTP Digest Drugim typem autentykacji jest autentykacja HTTP Digest, która podobnie jak HTTP Basic, bazuje na nazwie użytkownika i haśle. Dane te są jednak przesyłane do serwera w formie zaszyfrowanej. Poprzez sieć przesyłany jest łańcuch tworzony za pomocą funkcji skrótu MD5 z nazwy użytkownika, hasła, URL, metody żądania HTTP i losowo generowanego przez serwer klucza jednokrotnego użycia (ang. nounce). Prowadzi to do poprawy bezpieczeństwa przesyłanych danych. W tej metodzie serwer WWW również nie podlega autentykacji. Niestety autentykacja ta nie jest szeroko rozpowszechniona i obsługują ją jedynie serwery zgodne w pełni ze standardem J2EE. HTTPS Autentykacja HTTPS jest silnym mechanizmem autentykacji, opartym o transmisję HTTP szyfrowaną protokołem SSL. Metoda ta bazuje na użyciu certyfikatów i kluczy publicznych PKI. Głównym elementem tego podejścia jest system kryptografii oparty o klucze publiczne. Każdy uczestnik wymiany informacji posiada unikatową parę kluczy, używanych do kodowania i dekodowania informacji. Jednym z nich jest ogólnie dostępny klucz publiczny, a drugim tajny klucz prywatny. SSL zapewnia szyfrowanie danych, autentykację serwera, integralność wiadomości oraz opcjonalną autentykację użytkownika dla połączenia TCP/IP. Autentykacja użytkownika poza weryfikacją nazwy użytkownika oraz hasła jest uzupełniona weryfikacją certyfikatu użytkownika. Dzięki temu metoda ta charakteryzuje się poprawą bezpieczeństwa w porównaniu z metodą opartą na formularzu oraz HTTP Basic. Przed wykorzystaniem autentykacji HTTPS, należy się upewnić czy: Obsługa SSL jest odpowiednio skonfigurowana na serwerze, Serwer ma aktualny certyfikat, Użytkownik ma ważny certyfikat z kluczem publicznym. W celu użycia tej metody autentykacji w aplikacji WWW na serwerze Tomcat w pliku web.xml, należy dopisać <login-config> <auth-method>client-cert</auth-method> </login-config> Autentykacja HTTPS polega na wzajemnej autentykacji użytkownika i serwera. Proces ten polega na analizie certyfikatów. Dzięki temu klient ma pewność, że serwer, z którym się połączył nie jest fałszywy. Dodatkowo serwer poprzez analizę certyfikatu klienta może zdecydować o przesłaniu klientowi strony, o którą prosił, bądź

4 nie. Ma to szczególne znaczenie w przypadku aplikacji biznesowych (banki oraz sklepy internetowe itp.), gdzie bardzo ważna jest poufność przesyłanych danych. Autentykacja z wykorzystaniem certyfikatów ma następujący przebieg. Najpierw użytkownik żąda dostępu do chronionych zasobów. W następnym kroku serwer WWW przedstawia użytkownikowi swój certyfikat. Użytkownik weryfikuje poprawność certyfikatu. W przypadku pomyślnej weryfikacji certyfikatu serwera, użytkownik wysyła swój certyfikat, w celu sprawdzenia go przez serwer. W przypadku pomyślnej weryfikacji użytkownika, serwer przyznaje mu dostęp do żądanych, chronionych zasobów. M a g a z y n k l u c z y M a g a z y n z a u f a n i a S e rw e r. c e r t 1. Żądanie dostępu do chronionych danych 2. Przedstawienie certyfikatu s e r w e r a S e rw e r. c e r t 3. Weryfikacja certyfiaktu S e r w e r 4. Wysyłanie nazwy użytkownika i hasła 5. Dostęp do chronionych danych Rys.2. Autentykacja HTTPS. Autentykacja może zostać przeprowadzona również jednokierunkowo. Weryfikacja autentyczności serwera odbywa się na podstawie certyfikatu, a użytkownika za pomocą nazwy użytkownika i hasła. W takim przypadku użytkownik żąda dostępu do chronionych zasobów, a serwer WWW przedstawia użytkownikowi swój certyfikat. Następnie aplikacja kliencka weryfikuje jego poprawność. W przypadku pomyślnej weryfikacji certyfikatu serwera, użytkownik wysyła: nazwę użytkownika i hasło, których poprawność jest kontrolowana przez serwer. W przypadku podania poprawnych danych użytkownika, serwer przyznaje mu dostęp do żądanych, chronionych zasobów. Schemat tego procesu przedstawia rys. 2. Magazyn zaufania oraz magazyn kluczy serwera są plikami przechowującymi informacje o znanych (również własnych) certyfikatach. FORM Autentykacja typu FORM pozwala przede wszystkim na elastyczne zaprojektowanie wyglądu formularza, poprzez który użytkownik wprowadza dane, a także stron błędów generowanych przez przeglądarkę. Strona logowania oraz strona wyświetlana po błędnym zalogowaniu są przygotowywane samodzielnie na podstawie specyfikacji, a odnośniki do nich umieszczane w pliku konfiguracyjnym aplikacji WWW, czyli web.xml. Proces autentykacji tego typu rozpoczyna się podobnie jak w przypadku poprzednich metod, żądaniem dostępu do chronionych zasobów. W przypadku, gdy użytkownik nie jest zalogowany, serwer przekierowuje go do strony logowania. Po wypełnieniu formularza logowania zostaje on wysłany na serwer gdzie weryfikowane

5 są dane użytkownika. W przypadku pomyślnej autentykacji, następuje sprawdzenie czy użytkownik ten ma prawa dostępu do żądanego zasobu. Jeśli tak, serwer przekierowuje go do tych zasobów przy użyciu ścieżki URL. W przypadku niepowodzenia, zwracana jest strona błędu. Poniższy schemat (rys. 3) obrazuje ten proces. 1. Żądanie do stępu do chronionych danych Serwer 2. Przekierowanie na stronę do logowania J_security_check Sukces? Błąd 3. Zatwierdzenie formular za 4. Przekierow anie na zasoby zw rócenie strony z błędem Rys.3 Autentykacja typu FORM Użycie tego typu autentykacji wymaga dopisania do pliku web.xml znacznika login-config, gdzie należy wskazać względne ścieżki URL stron logowania i błędu. Autentykacja bazująca na formularzu nie jest bezpieczna. Dane przesyłane są otwartym tekstem, serwer nie podlega autentykacji. Nazwa użytkownika i jego hasło mogą zostać przechwycone, chyba, że połączenie będzie szyfrowane za pomocą SSL. Takie rozwiązanie zastosowane jest obecnie testowo do chronionych zasobów koła naukowego Pentagon Café [6]. Przykładowa konfiguracja Konfiguracja logowania do zasobów na serwerze Tomcat opartego na formularzu powinna zostać rozpoczęta od definicji użytkowników i ról w pliku tomcat-users.xml. W przykładowym pliku dodana została nowa rola o nazwie registered-user oraz przypisany został do niej nowy użytkownik o nazwie gosia. <tomcat-users> <role rolename="registered-user"/> <user name="tomcat" password="tomcat" roles="tomcat" /> <user name="role1" password="tomcat" roles="role1" /> <user name="both" password="tomcat" roles="tomcat,role1" /> <user name="gosia" password="balbinka" roles="registereduser"/> </tomcat-users>

6 Drugim krokiem jest zdefiniowanie metody logowania typu FORM oraz podanie ścieżek do strony logowania i strony informującej o błędnym logowaniu w pliku konfiguracji aplikacji web.xml. <login-config> <auth-method>form</auth-method> <form-login-config> <form-login-page>/logon.jsp</form-login-page> <form-error-page>/logonerror.jsp</form-error-page> </form-login-config> </login-config> Następnie należy przygotować strony JSP: logon.jsp - służącą do logowania oraz logonerror.jsp służącą do wyświetlenia informacji o błędnym logowaniu. Strona logowania powinna zawierać formularz do wprowadzania nazwy użytkownika i hasła zdefiniowany w taki sposób, aby parametr action znacznika form miał wartość j_security_check, a parametry name pól tekstowych odpowiednio j_username i j_password. Przykładowy formularz wygląda następująco: <form action="j_security_check" method="post" > <h2>podaj login i hasło:</h2> <p><strong>login: </strong> <input type="text" name="j_username" size="25"> <p><strong>hasło: </strong> <input type="password" size="15" name="j_password"> <p> <input type="submit" value="loguj" > </form> Strona do logowania musi zawierać formularz z tymi specjalnymi wartościami stałymi, aby zapewnić automatyczne dokonanie przez serwer autentykacji typu Form. Dane z formularza będą przesyłane metodą POST, aby hasło nie pojawiało się w pasku adresu przeglądarki WWW. Przygotowaną w ten sposób stronę do logowania przedstawia rys. 4. Kolejnym etapem konfiguracji jest określenie zasobów chronionych w pliku web.xml. W przedstawionym poniżej przykładzie chroniona będzie cała zawartość katalogu logowanie będącego podkatalogiem głównego katalogu aplikacji WWW. Jego zawartość będzie dostępna jedynie dla zweryfikowanego użytkownika posiadającego rolę registered-user. <security-constraint> <web-resource-collection> <web-resource-name>logowanie</web-resource-name> <url-pattern>/secure/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>registered-user</role-name> </auth-constraint> </security-constraint>

7 Rys. 4. Formularz logowania na stronie login.jsp. Jeżeli wymagane jest szyfrowanie transmisji poufnych danych konieczne jest określenie zasobów, które mają być dostępne tylko przez SSL, czyli z wykorzystaniem protokołu https. Mógłby to być np.: katalog /secure lub katalog zawierający stronę do logowania. Dostęp do tak zdefiniowanych zasobów będzie szyfrowany, a szyfrowanie będzie wymuszane przez serwer Tomcat, tzn. wszystkie próby dostępu nieszyfrowanego będą przekierowywane na port transmisji wykorzystującej SSL. Wskazanie zasobów dostępnych z wykorzystaniem SSL (w tym przypadku zawartości katalogu /ssl) przedstawia poniższy fragment pliku web.xml: <security-constraint> <web-resource-collection> <web-resource-name>ssl</web-resource-name> <url-pattern>/ssl/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>confidential</transport-guarantee> </user-data-constraint> </security-constraint> Znacznik transport-guarantee może przyjmować jedną z dwóch wartości: Integral lub Confidential. Pierwsza zapewnia integralność danych podczas transmisji, druga zapewnia poufność danych. W praktyce oba tryby wymuszają użycie SSL. Po prawidłowo przygotowanej konfiguracji, w przypadku, gdy użytkownik będzie próbował się dostać się do zasobów chronionych tzn. zawartości katalogu

8 /secure serwer wyśle mu stronę do logowania. Przesłanie strony do logowania może zostać poprzedzone przesłaniem do przeglądarki certyfikatu serwera, jeśli strona do logowania została umieszczona w katalogu dostępnym tylko przez SSL. Po podaniu nazwy i hasła przez użytkownika serwer weryfikuje użytkownika i jego przynależność do grupy registered-user mającej dostęp do zasobów chronionych. Jeżeli wszystko przebiegnie prawidłowo użytkownik otrzyma dostęp w przeciwnym wypadku otrzyma stronę logonerror.jsp. Na stronie błędu można dodatkowo umieścić skrypt JavaScript umożliwiający powrót do strony logowania: <a href= javascript:history.back(1) >Zaloguj ponownie</a> Podsumowanie Specyfikacja J2EE określa kilka sposobów autentykacji użytkownika. W zasadzie każdy sposób autentykacji wymaga podania nazwy użytkownika i hasła. Bez hasła mogą obejść się metody oparte na szyfrowaniu transmisji, ponieważ dzięki wykorzystaniu mechanizmu SSL przesyłany jest na serwer certyfikat klienta z jego kluczem publicznym, który stanowi niejako jego cyfrowy podpis. Najwygodniejszym rozwiązaniem z punktu widzenia niewielkich aplikacji internetowych jest zastosowanie autentykacji typu Form. Umożliwia ona przygotowanie własnej strony logowania oraz strony informującej o błędzie. To rozwiązanie może zostać także w prosty sposób uzupełnione o szyfrowanie transmisji, co zapewnia bezpieczne przesłanie hasła i innych poufnych danych przez sieć. Wymienione zalety autentykacji typu Form zadecydowały o tym, że jest ona często stosowana i została zastosowana także do zabezpieczenia zasobów koła naukowego Pentagon Café. Literatura: [1] Public-Key Infrastructure (X.509) (pkix), < [2] P. Kopniak: Evaluation of Possibilities of Java Cryptography Architecture and Java Mail Libraries Usage to Encrypt Massages. w "Annales Universitatis Mariae Curie-Skłodowska, Sectio AI Informatica", vol. II, Wydawnictwo UMCS, Lublin, 2004, s , [3] The Java EE 5 Tutorial, < [4] M. Hall, More Servlets and JavaServer Pages, Pearson Education, 2001, [5] The Base16, Base32, and Base64 Data Encodings, < [6] Koło Naukowe Pentagon Café, <fttp://cafe.pollub.pl>