Integracja systemu Kerberos z WebSphere Application Server 7

Poznawanie technologii Web Services zapewniało mi niemałą rozrywkę przez ostatnich kilka dni, a to dopiero początek mojej przygody z SOAP, WSDL i JAX-WS. Temat pochłonął mnie tak bardzo, że zupełnie zapomniałem opisać w jaki sposób dokonałem integracji poprawnie skonfigurowanego systemu Kerberos z WAS'em. Jak wspomniałem konfigurację Kerberos'a mam już za sobą, stąd wykonanie poniższych czynności było jedynie formalnością, dopełnieniem wykonanej wcześniej pracy.

Po zalogowaniu się do konsoli administracyjnej WAS'a przechodzimy do Security -> Global Security -> Kerberos configuration.


Biorąc pod uwagę, że w bazie danych systemu Kerberos istnieje principal WAS/linux-fi5z.site@SITE, który został dodatkowo wyeksportowany do pliku kt.keytab, nasz realm nosi nazwę SITE
a plik konfiguracyjny Kerberos'a znajduje się w /etc pod nazwą krb5.conf, konfiguracja w konsoli administracyjnej powinna wyglądać następująco:


Klikamy myszką "OK" oraz zapisujemy wprowadzone dane "Save".
Od tej chwili domyślnym mechanizmem autoryzacji dla WAS'a jest Kerberos. Należy o tym pamiętać przy kolejnej próbie zalogowania się do konsoli administracyjnej. Komunikat "Login failed. Check the user ID and password and try again." z pewnością pojawi się jeżeli zapomnieliśmy dodać do kerberosowej bazy danych odpowiedniego wpisu.

Dla konta administratora o nazwie admin wymagany principal wprowadzamy następująco:


Podane hasło należy zapamiętać, będziemy używać go podczas logowania się do konsoli administracyjnej.

Troubleshooting - ciąg dalszy

Błędne było przyjęte założenie, że źródłem problemów podczas prób wykorzystania systemu Kerberos jako mechanizmu autoryzacji jest WAS. Pomysły jak rozwiązać zagadkę kończyły się wraz z upływem czasu - może dlatego coś mnie podkusiło aby jeszcze raz zainteresować się plikami Kerberos'a.

Po chwili zastanowienia wpadłem na pomysł aby jeszcze raz wyeksportować principal "WAS/linux-fi5z.site@SITE" do pliku keytab, który miał posłużyć WAS'owi. Użyłem w tym celu kadmin.local wydając za jego pomocą polecenie
ktadd -k /usr/local/var/krb5kdc/kt.keytab WAS/linux-fi5z.site@SITE.
Chcąc sprawdzić czy faktycznie plik kt.keytab zawiera pożądane pola posłużyłem się narzędziem klist.


Jak można zauważyć powyżej, wszystko się zgadza. Użyłem więc tego pliku przy konfiguracji - tym razem obyło się bez problemu.

Jak się okazało kością niezgody był tutaj plik keytab, do którego ścieżkę podawałem w konsoli administracyjnej WAS'a. Niedopatrzenie kosztowało mnie sporo czasu, lekcja nie poszła jednak na marne - teraz z pewnością będę zwracać większą uwagę na zawartość plików, których używam korzystając z zewnętrznych aplikacji.

WAS7 Troubleshooting: Tracing CreateKrbAuthMechanism

Od kilku dni próbuję wykorzystać system Kerberos jako mechanizm autoryzacji w IBM WebSphere Application Server 7 . Wszelkie próby skonfigurowania WAS'a tak aby współpracował z Kerberosem kończą się niepowodzeniem. Za każdym razem pojawia się komunikat:

"org.ietf.jgss.GSSException, major code: 13, minor code: 0 major string: Invalid credentials minor string: Cannot get credential from JAAS Subject for principal: WAS/linux-fi5z.site@SITE".

Zakładam, że konfiguracja systemu Kerberos jest poprawna i "wina" leży w tym przypadku po stronie WAS'a. Podążając dalej tym tropem postanowiłem sprawdzić dokładniej jak przebiega proces tworzenia konfiguracji. Opis jak to zrobić zamieściłem poniżej.

1. Logujemy się do konsoli administracyjnej, w menu wybieramy Troubleshooting -> Logs and trace. Następnie wybieramy server1.


2. Wybieramy Diagnostic Trace.


3. W tym miejscu możemy dokładnie określić plik wyjściowy dla danych. Przechodzimy do Change Log Detail Levels.


4. Następnie mamy możliwość sprecyzowania, które komponenty lub grupy komponentów nas interesują. CreateKrbAuthMechanism odnajdziemy w Groups. Klikamy myszką na znak "+" przy nazwie listy "All Groups" w celu jej rozwinięcia.


5. Klikamy myszką na odnaleziony na liście CreateKrbAuthMechanism. Z menu wybieramy Message and Trace Levels -> finest.


6. Klikamy myszką na przycisk "OK". Następnie potwierdzamy operację zapisu - "Save".


7. Domyślna lokalizacja pliku trace.log to /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1/. Tam odnajdziemy uzyskane informacje.

Instalacja i konfiguracja systemu Kerberos

Zaczynając swoją przygodę z oprogramowaniem Kerberos 5 Release 1.8 nie rozstawałem się z dokumentacją nawet na chwilę. Ku mojemu zdziwieniu, już przy pierwszej napotkanej przeszkodzie okazało się, że wszelkie zgromadzone przeze mnie informacje sprawiają wrażenie niewystarczających do rozwiązania problemu. Zanim jednak przedstawię więcej szczegółów na ten temat chciałbym opisać krok po kroku czynności niezbędne do wykonania przy instalacji i konfiguracji systemu kerberos.

1. Instalacja

Źródła do pobrania: krb-1.8-signed

Przed przystąpieniem do instalacji należy upewnić się, że system zawiera kompilator gcc oraz narzędzie yacc, co można sprawdzić poleceniem which, które zwraca pełną ścieżkę do programu (np. which yacc). U mnie na SUSE Enterprise Server 11 domyślnie zainstalowane oprogramowanie nie zawierało ani jednego ani drugiego, dlatego zmuszony byłem uzupełnić system o paczki rpm:
gcc oraz bison (które przeważnie można znaleźć na dvd z linuxem).

Po rozpakowaniu archiwum ze źródłami systemu kerberos powinniśmy przejść do wnętrza folderu krb5-1.8/src/ oraz wykonać następujące komendy:
./configure
make
make check (jeżeli chcemy przetestować skompilowany system)
make install

2. Konfiguracja

Przykładowa zawartość pliku /etc/krb5.conf dla hosta o nazwie linux-fi5z znajdującego się w domenie site wygląda następująco:


Realm wg obowiązującej konwencji powinien nosić taką samą nazwę jak domena i składać się wyłącznie z wielkich liter. Jak można zauważyć usługa Key Distribution Center oraz serwer administratora znajdują się pod adresem linux-fi5z.site a ich pliki log mieszczą się w /var/log/krb5/ .

Przykładowy plik konfiguracyjny usługi KDC /usr/local/var/krb5kdc/kdc.conf :


Tutaj staramy się nie zmieniać zbyt wiele bez wyraźnej potrzeby, pozostawiamy większość domyślnych wartości.

Informację o usługach kerberosa działających na danych portach powinniśmy umieścić w pliku /etc/services dodając do niego poniższe linie:


Kolejnym krokiem jest stworzenie bazy danych dla usługi KDC za pomocą polecenia /usr/local/sbin/kdb5_util create -r SITE -s

Dodawać administratorów będziemy za pomocą narzędzia /usr/local/sbin/kadmin.local . Polecenie mające na celu dodanie uzytkownika root do grupy administratorów wyglądać będzie następująco addprinc root/admin

Natomiast dodanie użytkownika, który będzie korzystać z usług za pomocą systemu kerberos przeprowadzamy poleceniem addprinc user_name

Dla nowo utworzonych użytkowników powinniśmy stworzyć listę uprawnień /usr/local/var/krb5kdc/kadm5.acl , w której na potrzeby przykładu nadamy każdemu administratorowi wszelkie dostępne uprawnienia: */admin@SITE *

Utworzenie pliku keytab umożliwi demonowi kadmind dekodowanie biletów Kerberosa w celu przyznania lub nie dostępu do bazy danych. Po uruchomieniu narzędzia /usr/local/sbin/kadmin.local wydajemy polecenie ktadd -k /usr/local/var/krb5kdc/kadmin5.keytab kadmin/admin kadmin/changepw

Po wykonaniu podstawowej konfiguracji systemu Kerberos możemy uruchomić usługi krb5kdc i kadmind (/usr/local/sbin/).

3. Napotkana przeszkoda

Chcąc sprawdzić czy system Kerberos działa poprawnie postanowiłem skorzystać z dołączonych przykładowych aplikacji. W tym celu dodałem do bazy danych pozycję sample/linux-fi5z.site@SITE oraz linijkę sample 13135/tcp do pliku /etc/services . Następnie uruchomiłem przykładowy serwer komendą sserver -p 13135 -S /usr/local/var/krb5kdc/kt.keytab .
Po uzyskaniu za pomocą kinit biletu TGT umożliwiającego dalsze działania postanowiłem połączyć się z serwerem komendą sclient linux-fi5z . Jak można zauważyć poniżej test zakończył się niepowodzeniem.


"Wrong principal in request" - nie jestem w stanie odgadnąć, co jest przyczyną błędu, za wszelkie pomysły na rozwiązanie zagadki będę bardzo wdzięczny.