Czy istnieje sposób aby tego uniknąć (na przykład automatycznie logując się do aplikacji przy użyciu danych wprowadzonych podczas autoryzacji w domenie Windows)? Jak najbardziej tak – aczkolwiek nie jest to zadaniem trywialnym. Niniejszy artykuł opisuje proces integracji serwera BEA WebLogic z systemem Kerberos, jednakże jego celem nie jest wyjaśnienie wszystkich aspektów tego procesu (wyjaśnienie na tym poziomie szczegółowości mogłoby z powodzeniem wypełnić książkę). Celem tego artykułu jest raczej przeprowadzenie operatora domeny Active Directory przez proces integracji w najbardziej typowych warunkach.

Środowisko testowe

Środowisko testowe składać się będzie z trzech komputerów (p. Rys. 1):

1. zeus: pracujący pod Windows 2003 kontroler domeny olympus.net (ang. Domain Controller, DC), z uruchomionym Centrum Dystrybucji Kluczy (ang. Key Distribution Center, KDC) systemu Kerberos. (Uwaga: proces integracji różni się w zależności od wersji systemu Windows, pod kontrolą której pracują DC i KDC. Niniejszy artykuł opisuje proces integracji w oparciu o system Windows 2003).

2. athena: serwer aplikacji BEA Weblogic 9.2. Na potrzeby tego artykułu zakładamy, że systemem operacyjnym na serwerze athena jest system UNIX-owy

3. apollo: stacja robocza klienta, który jest zalogowany w domenie i chce uzyskać dostęp do aplikacji zainstalowanej na serwerze athena.

Rys. 1. Środowisko testowe i proces logowania się do aplikacji WWW zintegrowanej z systemem Kerberos (1 – Użytkownik zalogowany do stacji apollo.olympus.net próbuje uzyskać dostęp do części chronionej aplikacji WWW. 2 – przeglądarka użytkownika wysyła żądanie do serwera aplikacji WWW athena.olympus.net, i odbiera odpowiedź HTTP401, rozpoczynającą proces logowania się do aplikacji za pośrednictwem systemu Kerberos. 3 – Komputer apollo.olympus.net łączy się z KDC (zeus.olympus.net) i wysyła żądanie przyznania ticketa. 4 – po pozytywnej identyfikacji użytkownika i hosta w domenie, serwer KDC odsyła ticket do komputera apollo.olympus.net. 5 – ticket zostaje przekazany komputerowi athena.olympus.net. Po poprawnym przetworzeniu ticketu, proces identyfikacji użytkownika kończy się sukcesem. 6 – serwer athena.olympus.net łączy się z LDAP Active Directory, celem pobrania grup AD (traktowanych jako role użytkownika). Po pobraniu grup kończy się proces autoryzacji użytkownika w aplikacji WWW)

Konfiguracja w KDC

Proces integracji serwera Weblogic z domeną Windows należy rozpocząć od utworzenia w kontrolerze domeny zeus.olympus.net konta dla serwera aplikacji. Konto to musi spełniać kilka określonych warunków (p. tabela 1)

Typ pola	Wartość	Uwagi
First name	athena.olympus.net	Nazwa konta identyczna z nazwą hosta (oczywiście w domenie musi istnieć serwer DNS i ReverseDNS odwzorowujący dla hosta athena.olympus.net
Login	athena.olympus.net	Login taki sam jak nazwa hosta.
Hasło	longlongpassword	Hasło będzie wykorzystane dalej, do generowania pliku zawierającego klucz szyfrowania
Algorytm szyfrowania hasła	DES	Po włączeniu szyfrowania DES na koncie należy zresetować hasło konta, podając nowe hasło 100% zgodne ze star

Tabela 1. Konto w Active Directory przeznaczone dla serwera aplikacji

Integracja z systemem Kerberos wymaga zarejestrowania w KDC usług, z którymi będziemy się integrować. Dokonujemy tego poprzez ustalenie tzw. Service Principal Names, SPN, na podstawie których identyfikowane sa usługi, dla których system Kerberos wystawia tickety. Aby zarejestrować SPN dla serwera Weblogic, w linii komend serwera KDC (zeus.olympus.net) wpisujemy:

setspn -a HOST/athena.olympus.net@OLYMPUS.NET athena.olympus.net
setspn -a HTTP/athena.olympus.net@OLYMPUS.NET athena.olympus.net

gdzie athena.olympus.net to nazwa konta użytkownika (zarejestrowanego w kontrolerze domeny) z którego uruchamiany jest serwer aplikacji na komputerze athena.olympus.net@OLYMPUS.NET

Aby sprawdzić poprawność wygenerowanych SPNs należy na serwerze KDC wpisać następującą komendę:

setspn –L athena.olympus.net

po wpisaniu powyższej komendy, powinny zostać wyświetlone SPNs skojarzone z kontem Active Directory athena.olympus.net

Następnym krokiem jest utworzenie tzw. pliku keytab zawierającego klucz służący do szyfrowania i deszyfrowania ticketów wydawanych przez system Kerberos dla serwera athena:

ktpass -princ HTTP/athena.olympus.net@OLYMPUS.NET
-mapuser athena.olympus.net
-crypto DES-CBC-MD5
-ptype KRB5_NT_PRINCIPAL
-mapop set +desonly
-pass longlongpassword
-out c:\temp\athena.http.keytab

ktpass -princ HOST/athena.olympus.net@OLYMPUS.NET
-mapuser athena.olympus.net
-crypto DES-CBC-MD5
-ptype KRB5_NT_PRINCIPAL
-mapop set +desonly
-pass longlongpassword
-out c:\temp\athena.host.keytab

Podczas tworzenia pliku keytab należy podać SPN, dla którego tworzony jest plik keytab, algorytm szyfrowania ticketów oraz hasło użytkownika wymienionego w parametrze mapuser. Obydwa pliki keytab (zapisane na dysku w miejscu wyspecyfikowanym w parametrze out) przekazujemy następnie administratorowi serwera athena.

Konfiguracja serwera athena

Pierwszym krokiem konfiguracji serwera athena.olympus.net jest skonfigurowanie klienta systemu Kerberos, czyli przekazanie mu danych domeny OLYMPUS.NET. Dokonujemy tego poprzez wykonanie następującego wpisu w plikach /etc/krb5/kdc.conf oraz /etc/krb5/krb5.conf

[kdcdefaults] kdc_ports = 88,750 [realms] OLYMPUS.NET = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /etc/krb5/kadm5.keytab acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s default_principal_flags = +preauth }

Tabela 2. Przykładowa treść pliku kdc.conf

Najważniejszym ustawieniem jest tutaj podanie ścieżki do pliku krb5.conf oraz włączenie preautentykacji dla wszystkich principali.

Kolejnym krokiem konfiguracyjnym jest utworzenie/edycja pliku krb5.conf, który powinien zawierać informacje o kontrolerze/kontrolerach domeny, algorytmie szyfrowania ticketów, ustawieniach klienta Kerberosa oraz samej domenie AD.

[libdefaults] default_realm = OLYMPUS.NET default_tkt_enctypes = des-cbc-md5 default_tgs_enctypes = des-cbc-md5 ticket_lifetime = 600 [realms] OLYMPUS.NET = { kdc = 10.1.1.1:88 kdc = 10.1.1.2:88 kdc = 10.1.1.3:88 kdc = 10.1.1.4:88 admin_server = 10.1.1.1 default_domain=OLYMPUS.NET } [domain_realm] .olympus.net = OLYMPUS.NET [appdefaults] autologin = true forward = true encrypt = true forwardable= true

Tabela 3. Przykładowa treść pliku krb5.conf, konfigurująca więcej niż jeden serwer KDC

Po utworzeniu/edycji dwóch powyższych plików, należy pobrać od administratora KDC dwa pliki keytab, które zostały utworzone podczas przygotowywania KDC do integracji z serwerem aplikacji.

Po otrzymaniu obu plików keytab należy je scalić za pomocą narzędzia ktutil, wydając następujące komendy:

ktutil – uruchamia narzędzie ktutil

rkt athena.http.keytab – wczytuje keytab HTTP

rkt athena.host.keytab – wczytuje keytab HOST

wkt athena.keytab – zapisuje scalony plik keytab

q – zamyka narzędzie ktutil

Po wykonaniu scalenia, należy sprawdzić poprawność konfiguracji wydając polecenie

kinit –k –t /<ścieżka>/athena.keytab

Jeżeli nie otrzymamy komunikatu o błędzie, konfiguracja hostów zakończyła się sukcesem i możemy przejść do konfiguracji serwera BEA WebLogic.

Konfiguracja serwera aplikacji

Aby rozpocząć konfiguracje, należy przygotować plik konfiguracji logowania w domenie JAAS dla serwera aplikacji, krb5.login.config. Powinien on zawierać m.in. dane niezbędne serwerowi aplikacji do zlokalizowania pliku athena.keytab. Przykładową treść takiego pliku przedstawia tabela 4.

com.sun.security.jgss.initiate { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/athena.olympus.net@OLYMPUS.NET" useKeyTab=true keyTab="/etc/athena.keytab" storeKey=true; }; com.sun.security.jgss.accept { com.sun.security.auth.module.Krb5LoginModule required principal="HTTP/athena.olympus.net@OLYMPUS.NET" useKeyTab=true keyTab="/etc/athena.keytab" storeKey=true; };

Tabela 4. Przykładowa treść pliku krb5.login.config

Plik krb5.login.config powinien zostać utworzony w obrębie domeny serwera WebLogic. W dalszej części artykułu przyjmujemy, że został on utworzony w katalogu głównym domeny, oznaczanym jako $DOMAIN_HOME.

Po utworzeniu konfiguracji logowania domeny JAAS, należy uzupełnić zestaw parametrów rozruchowych serwera WebLogic o parametry specyficzne dla integracji z serwerem Kerberos. Listę parametrów zawiera tabela 5.

-Djava.security.krb5.realm=OLYMPUS.NET -Djava.security.krb5.kdc=10.1.1.1 -Djava.security.auth.login.config= ${DOMAIN_HOME}/krb5.login.config -Djavax.security.auth.useSubjectCredsOnly=false -Dweblogic.security.enableNegotiate=true -Dweblogic.security.identityAssertionTTL=-1 -Dsun.security.krb5.debug=true -DDebugSecurityAdjudicator=true -Dweblogic.debug.DebugSecurityAtn=true -Dweblogic.debug.DebugSecurityAtz=true

Tabela 5. Lista dodatkowych parametrów rozruchowych serwera BEA WebLogic

Na liście parametrów znajdują się między innymi nazwa domeny, adres KDC, położenie pliku konfiguracji logowania. Parametr weblogic.security.identityAssertionTTL określa czas (w sekundach) ważności pojedynczego ustalenia tożsamości logującego się do usługi. Standardowo ma on wartość 300, ustawienie na -1 oznacza, że od razu po zalogowaniu dane ustalenie tożsamości jest nieważne i proces logowania powinien się rozpocząć od nowa przy każdej następnej próbie uzyskania dostępu do aplikacji przez danego użytkownika. Ostatnie cztery parametry włączają tryb DEBUG logowania mechanizmów dokonujących identyfikacji i autoryzacji w WebLogic. Ustawienie ich na true powoduje duży przyrost logów, dlatego po fazie testów integracji najlepiej przestawić je na false. Logi autentykatorów znajdują się w katalogu DOMAIN_HOME/servers/<nazwa_serwera_weblogic>.

Po dodaniu parametrów rozruchowych należy uruchomić domenę i zalogować się do konsoli zarządzania serwerem. Po zalogowaniu się, należy przejść do Security Realms/<nazwa_domeny_JAAS> i wejść na zakładkę Providers.

Rys. 2. Konfiguracja autentykatorów serwera WebLogic zintegrowanego z domeną Active Directory.

Na zakładce Providers należy skonfigurować dwa autentykatory. Pierwszym z nich jest NegotiateIdentityAsserter, który powinien znaleźć się na szczycie stosu autentykatorów serwera WebLogic. Jego konfiguracja jest trywialna – w zdecydowanej większości przypadków wystarczy go tylko dodać do stosu.

Kolejnym autentykatorem, który należy skonfigurować w celu zintegrowania serwera WebLogic z domeną Active Directory jest ActiveDirectoryAuthenticator.

Rys. 3. Konfigurowanie ActiveDirectoryAuthenticator

Podczas jego konfigurowania (na zakładce „Provider Specific” p. Rys. 3), należy wprowadzić informacje o domenie AD, między innymi:

· adres IP Kontrolera Domeny

· port, na którym działa usługa LDAP AD zawierająca dane domeny

· gałąź użytkowników w drzewie LDAP AD

· gałąź grup w drzewie LDAP AD

· nazwę i hasło użytkownika zarejestrowanego w domenie, z uprawnień którego korzysta system podczas logowania się do LDAP AD. W naszym przykładzie, użytkownikiem takim będzie athena.olympus.net

Następnie należy przygotować naszą aplikację WWW do integracji z Kerberosem. Dokonujemy tego, zmieniając wpis dotyczący konfiguracji logowania w pliku web.xml aplikacji na:

<login-config>

<auth-method>CLIENT-CERT</auth-method>

</login-config>

Konfiguracja przeglądarki klienta

Zakładamy, że klient zalogowany na stacji apollo.olympus.net będzie uzyskiwał dostęp do aplikacji za pomocą przeglądarki MS Internet Explorer 7.0. Aby skonfigurować tą przeglądarkę do łączenia się z naszą aplikacją, należy dodać komputer athena.olympus.net do strefy „Lokalny intranet”. Dokonujemy tego poprzez wybranie z menu głównego przeglądarki pozycji „Narzędzia > Opcje internetowe”. Następnie, na zakładce „Zabezpieczenia” wybieramy pozycję „Lokalny intranet” i naciskamy przycisk „Witryny”. Upewniamy się, że opcje „Uwzględnij wszystkie lokalne witryny (sieć intranet), które nie należą do innych stref” oraz „Uwzględnij wszystkie witryny, które nie używają serwerów proxy” są zaznaczone. Później klikamy w przycisk „Zaawansowane” i dodajemy adres athena.olympus.net do listy witryn traktowanych jako lokalny intranet.

Następnie, na zakładce „Zabezpieczenia”, klikamy w przycisk „Poziom niestandardowy” i w sekcji „Uwierzytelnianie użytkownika” wybieramy opcję „Zaloguj automatycznie tylko w strefie intranetu”.

Podsumowanie

Czas na przetestowanie nowego sposobu logowania do aplikacji WWW. Aby tego dokonać, logujemy się na stację apollo.olympus.net i podajemy w przeglądarce adres sięgający do strefy chronionej naszej aplikacji. Jeżeli zamiast prawidłowego ekranu aplikacji zobaczymy ekran z błędem protokołu HTTP, przechodzimy do fazy debugowania właśnie wykonanej integracji. Ale to już temat na zupełnie inny artykuł.