Tuesday, October 9th, 2007...12:11 am

Nietypowo będzie bo o Javie

Jump to Comments

Jak przynajmniej co niektórzy moi znajomi wiedzą musiałem ostatnio rozwiązać pewien mały problem z aplikacją napisaną w Java. Jako że nie do wszystkich chyba wydzwaniałem tamtego wieczora to doświadczeniem podzielę się i tutaj :).

Na poczÄ…tku maÅ‚e zastrzeżenie – jakoÅ› do Å›rodowisk i aplikacji opartych o Java przekonany nie jestem (na swoim laptopie JVM nawet nie posiadam). Co może i da siÄ™ odczuć w ramach tego postu, doÅ›wiadczenia ostatnie raczej mnie do Å›rodowiska nie przekonaÅ‚y.

Problem byÅ‚ wiÄ™c nastÄ™pujÄ…cy – aplikacja napisana w Javie, dziaÅ‚ajÄ…ca konkretnie w Å›rodowisku Tomcat + Axis posiadaÅ‚a niepomiernÄ… potrzebÄ™ uzyskania dostÄ™pu do pewnych usÅ‚ug web services dziaÅ‚ajÄ…cych na IIS6. Pech chciaÅ‚, że dostÄ™p ten nie mógÅ‚ być anonimowy i konieczne byÅ‚o uwierzytelnienie siÄ™ tej apliakcji z użyciem co najmniej NTLM. I tutaj zaczęły siÄ™ pewne schody.

Po usuniÄ™ciu pierwszej warstwy problemów wygenerowanych w Å›rodowisku przez administratorów (po raz kolejny okazuje siÄ™ że to nie jest tak że “samo” siÄ™ psuje a Å›rodowiska testowe, w których wszystko dziaÅ‚a nie sÄ… jednak identyczne z produkcjÄ…) doszliÅ›my w rozwiÄ…zywaniu problemu do momentu gdzie jak zwykle najskuteczniejszÄ… formÄ… diagnostyki jest posÅ‚uchanie “co na drucie piszczy”.

Szybko okazało się, że rzeczona aplikacja nawet może i próbuje rozpocząć sekwencję uwierzytelnienia ale jakoś nie spotyka się to z aprobatą ze strony IIS. I tutaj clue dzisiejszego postu, czyli ta mała rzecz, która powoduje że warto o tym wspomnieć dla potomności. Pomimo że z analizy ruchu sieciowego wyraźnie wynikało że uwierzytelnienie nie następuje to klient w odpowiedzi uzyskiwał kod błędu HTTP 500 (Internal Error) zamiast oczekiwanego HTTP 401 (Unauthorized).

Okazuje się że sytuacja ta opisana jest w artykule KB 903071 i występuje w przypadku, gdy klient próbuje uwierzytelnić się z użyciem NTLMv1 gdy konfiugracja ustawień serwera wymusza NTLMv2. Zwrócenie kodu błędu HTTP 500 jest po prostu sposobem IISa na powiedzenie, że nie podoba mu się sposób uwierzytelnienia wybrany przez użytkownika (do zapamiętania).

Tutaj warto wrócić do środowiska Java, w którym występował problem. Okazuje się, że różne implementacje klienta HTTP w środowisku Java pozwalają na obsługę różnych funkcjonalności, w tym różnych metod uwierzytelnienia. Można porównać je między sobą chociażby na tym zestawieniu.

W tym konkretnym wypadku problem występował z powodu kombinacji trzech czynników:

  • konfiguracji zabezpieczeÅ„ serwera, które zostaÅ‚y wykonane zgodnie z ustalonym w organizacji szablonem, bez uwzglÄ™dnienia specyfiki pracy serwera
  • Wyboru przez developera Å›rodowiska aplikacji, które nie wspieraÅ‚o przyjÄ™tych w ramach organizacji metod uwierzytelnienia
  • BÅ‚Ä™du developera w implementacji usÅ‚ugi (ale to już kompletnie inny temat).

RozwiÄ…zanie tego typu zagadek zajmuje jednak chwilÄ™. Coż … chociaż byÅ‚o z tego trochÄ™ “zawodowej” zabawy.

Wnioski na przyszÅ‚ość dla administratorów … rozmawiajcie ze swoimi developerami, chociażby po to aby ich kontrolować.

Wnioski na przyszÅ‚ość dla developerów … zainteresujcie siÄ™ czasami, czy przyjÄ™te przez Was rozwiÄ…zanie zadziaÅ‚a w istniejÄ…cej infrastrukturze.

Wnioski na przyszÅ‚ość dla mnie … zawsze (no może w miarÄ™ szybko po sprawdzeniu oczywistych rzeczy) rozpoczynać diagnostykÄ™ od analizy tego co “na drucie” piszczy :).

Leave a Reply