Thursday, March 25, 2021

Węzeł krajowy dla .NET - zakończenie zasadniczych prac części klienckiej i serwerowej

Moja implementacja biblioteki integracyjnej dla .NET do Węzła Krajowego, OldMusicBox.EIH.Client, o której wspominałem w poprzednich wpisach otrzymała właśnie sporą aktualizację dodającą do już wcześniej istniejącej demonstracji części klienckiej (czyli przykładowej aplikacji która pokazuje jak implementować klienta węzła krajowego), implementację części serwerowej.
Zwracam uwagę na ten element - istnieje demonstracyjnej wersji serwera oznacza bowiem, że prace integracyjne we własnej aplikacji można rozpocząć od prób integracji z tą przykładową implementacją serwera. Mój serwer, podobnie jak Symulator Węzła Krajowego, nie wymaga posiadania kont, nie wymaga w szczególności wpisywania haseł - użytkownik sam wybiera jakimi atrybutami chce się zalogować. Następnie symuluje część serwerową protokołu SAML2 w takiej wersji w jakiej implementuje go Węzeł Krajowy, zachowując dialekt SAML2 (Artifact Binding) oraz sposób szyfrowania asercji.
Jest to szczególnie użytecznie w sytuacji, w której implementacja klienta nie ma związku z załączoną tu częścią kliencką - na przykład wtedy kiedy klient powstaje w Javie, node.js czy PHP. Dla takich aplikacji klienckich pierwszą możliwością przeprowadzenia testu integracyjnego był do tej pory Symulator Węzła Krajowego. Teraz natomiast można użyć załączonej aplikacji i zasymulować część serwerową mając ją pod całkowitą kontrolą - w szczególności można ją w pełni debugować i dzięki temu prześledzić w którym miejscu aplikacja kliencka popełnia błąd.
Dla zainteresowanych - to było całkiem nietrywialne. Implementacja części klienckiej była wzorowana na przykładowym Javowym kodzie części klienckiej, jaka jest dołączana do dokumentacji WK (formalnie: na stronie symulatora WK znajduje się link do konsolowej aplikacji Java która wczytuje XML z zaszyfrowaną asercją i pokazuje jak go rozkodować). Ale symulowanie serwera wymagało zrozumienia algorytmu Key Agreement w wersji dla krzywych eliptycznych a potem całego mnóstwa prób i błędów. Istniejąca implementacja wymaga od klienta posiadania klucza prywatnego (bo klucz publiczny serwera jest częścią informacji zwracanej w zaszyfrowanej asercji), a serwer potrzebuje, oprócz swojego certyfikatu i klucza prywatnego, również klucza publicznego klienta.