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.

2 comments:

Unknown said...

Witam,
Chciałbym prosić o informację odnośnie wspomnianej przez Pana implementacji klienta w języku Java, czy uzyskał Pan ją z pliku "Zal. 5 Instrukcja Integratora Dostawcy Środka Identyfikacji (DŚI).docx? Czy może z innego źródła np. cpa.gov.pl -> IntegracjaWK - v1 -> SDKs -> java?

Chciałbym również Panu podziękować za dzielenie się wiedzą oraz udostępnianiem pomocnych materiałów.

Wiktor Zychla said...

Ta przykładowa wspomniana aplikacja jest dostępna z witryny symulatora WK. To zwykła konsolowa aplikacja, która wczytuje XML z zaszyfrowaną asercją i krok po kroku rozkodowuje tego XMLa - samo rozkodowanie jest owszem opisane w dokumentacji, jest tam nawet pseudokod, ale na moim poziomie doświadczenia ten pseudokod był jednak zbyt "pseudo" i zrekonstruowanie działającego kodu, który można by przerobić na C# zajęłoby chyba bardzo dużo czasu. Stąd ta konsolowa aplikacja Java była bardzo, bardzo pomocna.

To nie jest jednak pełne demo, nie ma tam w szczególności w ogóle początkowych kroków protokołu SAML2.

Symulator WK ma z kolei blokadę IP i dostępny jest tylko z sieci, które są zgłoszone przy uzyskiwaniu wniosku o dostep do symulatora.