i cały model biznesowy w pi.... :D
0
0
Im dłużej piszę serwis do logowania przez WK i czytam równoległy wątek do eFaktury, tym bardziej utwierdzam się w przekonaniu, aby jak najdalej trzymać się od integracji z rządowymi apkami.
@Wiktor Zychla: Swoje logowanie przez WK robię jako niezależny serwis(który nie będzie miał frontów dla userów). Czy mógłbyś sprawdzić czy nie mam błędu logicznego?
User z apki klika w przycisk logowanie przez WK i uderza do backend, zaś backend uderza do mojego serwisu(chyba, że mogę bezpośrednio z frontów to zrobić).
Backend odpytuje mój serwis i podaje nazwę tenantu, serwis sprawdza czy dany tenant obsługuje WK i ma certyfikaty, generuje xml, koduje go do base64 i zwraca na fronty(w bazie danej serwisu będzie tworzony obiekt user z id, które jest wysyłane w xml). Fronty robią przekierowanie za pomocą formularza do WK.
User loguje się przez WK. WK robi przekierowanie na fronty api. Jak rozumiem w tym miejscu przekierowanie ma postać www.frontyapki.pl/logowaniePZ?samlArt=<id>. www.frontyapki.pl/logowaniePZ przekazuje ja, zaś WK dokleja tylko ?samlArt=<id>. Fronty wysyłają posta do backendu z wartością samlArt.
Backend apki wysyła posta do serwisu z nazwą tenantu oraz wartością samlArt. Na moim serwisie jest odpytywanie WK według instrukcji i po odszyfrowaniu zapisuję dane z WK w bazie danych w moim serwisie pośredniczącym.
Do backendu apki zwracany jest Id usera w bazie mojego serwisu. Backend odpytuje ponownie mój serwis podając id usera (oraz tenant) i dostaje dane usera jak. Na podstawie numeru pesel sprawdzam czy user istnieje w bazie apki, jeżeli nie to jest tworzony. Generowany jest token JWT i zwracany na fronty, gdzie user w razie potrzeby wypełnia potrzebne dane kontaktowe
Kolejne logowanie tego samego usera, to po stronie mojego serwisu powtórzenie całego etapu, gdzie user jest na nowo tworzony w bazie po stronie serwisu.
Mam nadzieję, że opis mój jest zrozumiały. Jeszcze mam sporo pracy przed sobą i niechciałbym popełnić jakiegoś błędu. W ostatni tydzień marca rozpoczynamy testy.
0
Trudno ocenić pomysł nie znając listy wymagań które musi spełniać.
Jedno co się rzuca w oczy to to że połączenie backendu i serwisu to jakiś samodział (Do backendu apki zwracany jest Id usera w bazie mojego serwisu. Backend odpytuje ponownie mój serwis podając id usera i dostaje dane usera).
To otwiera pole dla jakichś problemów, luk itp. Gdyby to był jakiś normalny protokół SSO to serwis działałby po prostu jako Relying Identity Provider, co w każdym protokole SSO jest po prostu jedną z możliwych ról idp.
Z punktu widzenia backendu aplikacji byłoby to więc normalnej dostawca, który z tyłu miałby WK. W przyszłości taka konstrukcja, mimo że początkowo droższa, mogłaby być może bardziej elastyczna.
Ale zastrzegam że to komentarz w ciemno i nie podejmuję się na łamach forum internetowego recenzować architektury opisanej tak niezobowiązująco :)
0
Wymaganiem jest, aby przeszło audyt z WK/COIG. Dwie różne 2 apki mają z tego korzystać. One są kompletnie niezależne i napisane w różnych językach. Zamiast zwracać Id, mogę ze swojego serwisu zwracać po prostu dane odszyfrowane.
Dostałem za zadanie napisanie logowania przez WK. Reaserch, implementacja itp jest na moich barkach.
0
Po przejrzeniu całego wątku chciałbym zapytać czy komuś może udało się zrobić integracje WK w PHP? I czy ewentualnie mógłby podpowiedzieć co robić?
0
@Dawid Gut: Tak naprawdę osobiście największy problem miałem z podpisaniem plików, reszta rzeczy to tylko uzupełnienia xmla o odpowiednie dane oraz przesłanie do WK dokumentu, aby uzyskać zwrotne dane oraz wygenerowanie dokumentu do base64 i przesłanie w formularzu, aby usera przekierować . Widzę, że do podpisania pliku w php jest np. takie coś https://github.com/selective-php/xmldsig jeszcze coś do odszyfrowania potrzebujesz.
To jest pomocne https://mc.bip.gov.pl/interoperacyjnosc-mc/wezel-krajowy-dokumentacja-dotyczaca-integracji-z-wezlem-krajowym.html Zał 2. Instrukcja Integratora Dostawcy Usług DU.docx (434,12 KB)
Sprawdź też sobie githuba od @Wiktor Zychla co prawda C#, ale przyda się Tobie info co trzeba dokładnie wyciągnąć z pliku do odszyfrowania plus są stare certyfikaty oraz zaszyfrowane xml, które bardzo pomagają w testach lokalnych
0
@Michalk001: Aktualnie jedynie co mnie zastanawia to czy da się odszyfrować w PHP, gdyż z resztą sobie poradziłem.
0
@Dawid Gut: https://www.example-code.com/phpext/saml_decrypt_response.asp Zobacz na to
W moim przypadku napisałem osobny microservis tylko do WK w C#, aby nie musieć pisać implementacji dla 2 różnych aprek. Jednek w jsa drugiej w pythonie. Może i u ciebie można to tak zrobić?
0
To szyfrowanie asercji jest kosmicznie przekombinowane i trudno powiedzieć czemu służy. Nie od wczoraj robię takie sztuki a to widziałem po raz pierwszy i jak na razie ostatni tamże.
Powtarzanie tego w kolejnych platformach technologicznych jest żmudne i niczego nie wnosi. Żeby chociaż referencyjny kod dali na kilka platform, to nie. Jest w javie i jak się chce gdzieś indziej to trzeba sobie przepisać.
I oczywiście API jakiego tam użyli się nie przenosi.
0
@Michalk001: I mi również na myśl przychodzi koncepcja mikroserwisu.
@Wiktor Zychla: Oby jak najmniej podobnych rozwiązań.
0
Hej, integruje sie z epuapem i potrzebuje pomocy. W 2018r byl implementowany system do integracji, zostal on porzucony az do teraz. Mamy certyfikat ktory jest niestety przedawniony przez co nie mozemy dobic sie do TpUserInfo. Staramy sie o nowy dla srodowiska integracyjnego, Korzystamy z tego Instrukcja generowania ządania certyfikatu oraz wysylamy wniosek przez epuap o wydanie na podstawie wygenerowanego certyfikatu (o ten Wniosek o certyfikat do środowiska integracyjnego ePUAP/PZ - Wniosek o certyfikat dla środowiska integracyjnego.xml) nowego a nastepnie dodajemy go do p12. Niestety przy pierwszym POST na https://int.pz.gov.pl/dt/SingleSignOnService dostajemy 403 i Dostep zabroniony. Ktos moze sie natknal na to i jest w stanie pokierowac co zle robimy.
0
Single Sign On na epuap już od dawna nie jest dostępny, bo został zastąpiony Węzłem Krajowym. To inny system, inne certyfikaty, inna ścieżka integracji.
Epuap obsługuje tylko usługi typu tpsigning5.
0
Od jednostki publicznej otrzymałem certyfikaty zakupione w Certum Certification Authority. W rozmowie z COI powiedzieli mi, że proszą o część publiczną certyfikatu wraz z parametrami.
Tylko nie wiem jak to wygenerować poprawnie i z jakimi parametrami(?, być może źle tutaj coś zrozumiałem). Wiem tyle, że za pomocą openSSL należy to zrobić.
@Wiktor Zychla: Mógłbyś podesłać jak to dokładnie trzeba zrobić? Średnio znam się na takich rzeczach jak certyfikaty i rzeczy z nimi związane.
1
OpenSSL albo - jak ktoś nie lubi aplikacji command line'owych z milionem magicznych przełączników - jakimś kombajnem z GUI. Ja lubię Keystore Explorer
https://keystore-explorer.org/
W apce importujesz certyfikat z kluczem prywatnym, klikasz prawym na cert, Export / Export public key.
Jeśli chodzi o "parametry" to potrzebują dwóch - które się wpisuje w AuthnRequest: Issuer i AssertionConsumerUrl (adres zwrotny). Trzeba to podać dokładnie literka-w-literkę tak jak będzie wpisywane w AuthnRequest, z dokładnością do małych/wielkich liter i wszelkich dodatków (typu /). Czyli na przykład https://foo.bar/sso i https://foo.bar/soo/ to już byłyby dwie różne wartości i żądania byłyby odrzucane.
0
Dzięki, to już im w sumie podawałem wcześniej, ale podam jeszcze raz. Myślałem, że o coś innego im chodziło.
A jeszcze pytanko. Mam certyfikat to podpisu xml oraz do deszyfracji. Jak dobrze rozumiem to tylko klucz publiczny im wysyłam z certyfikatu do podpisu?
1
Obu tylko publiczny
0
@Wiktor Zychla: Cześć, mam pytanie odnośnie Twojej implementacji klienta .NET integrującego się z WK. Na swoim blogu (https://www.wiktorzychla.com), w artykule dotyczącym integracji z ePuap, napisałeś że ".NET nie ma wsparcia dla protokołu SAML2 w bibliotece standardowej". I w swoim kliencie sam zaimplementowałeś całego SAML'a 2. Od tamtego czasu się sporo pozmieniało i z tego co znalazłem w dokumentacji Microsoftowej, to już powstała implementacja do SAML2 (Microsoft.IdentityModel.Tokens.Saml2, wsparcie od .net framework 4.5 oraz .net 6). Próbowałeś już może przerzucać się ze swojej implementacji SAML'a 2 na tę Microsoftową?
0
@Oven222: U siebie korzystałem z .NET 6 i nie implementowałem nic, korzystałem z gotowych libek (Org.BouncyCastle, System.Security.Cryptography).
Trochę to trwało, ale od miesiąca moje wersja logowania do WK działa produkcyjnie już.
0
Tokeny a protokół to dwie różne rzeczy.
Model tokenów oni mają od dawna ale wsparcia protokołu nie. Technicznie - token saml to tylko fragment protokołu, użyty w momencie w którym dostaje się odpowiedź. Wcześniej trzeba wykonać żądanie (AuthnRequest i okolice) i tego tam nie ma.
A co do samego tokena, WK go zwraca z zaszyfrowaną asercją, czego jak pamiętam ten model Microsoftowy też nie obsługiwał.
Jak się pojawi nie
Microsoft.IdentityModel.Tokens.Saml2
a
Microsoft.IdentityModel.Protocols.Saml2
to będziemy się przyglądać ;)
0
Cześć,
Wątek ma już swoje lata - jak jest aktualnie czy z integracji do ePUAP mogą korzystać też firmy czy nadal tylko instytucje ?
0
Hej,
Czy ktoś może pisał integracje z WK w Javie i wie może skąd przy odszyfrowywaniu asercji brana jest wartość encKey (Jest to pseudokod z instrukcji intregatora)
Key encryptionKey = keyCipher.decryptKey( encKey, “http://www.w3.org/2001/04/xmlenc#kw-aes256” );
Do końca nie jestem pewien jak ją otrzymac. Niby XMLCipjer ma metode createEncryptedKey ale klucz który wypluwa jest praktycznie pusty i nie nadaje sie do podstawienia pod decryptKey
0
Witam serdecznie,
Od pewnego czasu poszukuję wszelkich informacji mogących być przydatnymi do szeroko rozumianej integracji z ePUAP, przyznam że w mojej opinii brakuje jakiegoś oficjalnego podsumowania/dokumentu, który by jasno wskazywał kolejne kroki w kontekście całości integracji. Są dostępne instrukcje pojedynczych serwisów, ale chciałbym to pozbierać do logicznej całości.
Nie ułatwia fakt, że część materiałów nie jest już dostępna - linki nie są już aktualne.
Pozwolę sobie zapytać o kilka rzeczy licząc na pomoc koleżanek i kolegów, którzy podejmowali się takich realizacji:
Zakładając, że chcemy się zintegrować w zakresie ESP (wysyłka, pobieranie).
- ePUAP, PZ, WK
Kolega "pytajnik" zadał podobne pytanie, chciałbym je nieco rozwinąć.
Śledząc niniejszy wątek wnioskuję, że kwestia wymagalności integracji z ww. serwisami ewoluowała na przestrzeni czasu. Przewinęło się już w wątku -w ostatnich postach- że aby zintegrować system z platformą ePUAP konieczna jest integracja z Węzłem Krajowym, natomiast od strony praktycznej jakie ma to znaczenie dla komunikacji z ePUAP? Czytając dokumentację właśnie ePUAP wnioskuję, że do podpisywania żądań wykorzystywany jest certyfikat, który jest "autoryzowany" przez COI?
Integracja z PZ jak rozumiem służyła dawniej również innym celom, obecnie "jedynie" podpisywaniu dokumentów i weryfikacji podpisów?
Z góry dziękuję za wszelkie informacje,
Pozdrawiam
0
Cześć, czy ktoś próbował i zrobił logowanie przez WK za pomocą typescript i node.js? Zatrzymałem się na etapie podpisu koperty, ale zawsze dostaje odpowiedź "Błąd podczas weryfikacji podpisu lub certyfikatu w żądaniu AuthnRequest wysłanym przez system kliencki o nazwie Issuer '...': Niepoprawny podpis.". Jakieś wskazówki na przeskoczenie problemu? Czy podpisywana koperta może być w postaci stringa w jednej linii? Czy trzeba przetworzyć klucz(.key) lub certyfikat (.pem)? Używam biblioteki xml-crypto i po kilku zmianach w bibliotece wykonuje moim zdaniem identyczną postać AuthnRequest, tylko jest ona ciągiem znaków zamiast ładnie sformatowanego xml.
Pozdrawiam
0
Szymon Kaleba napisał(a):
Cześć, czy ktoś próbował i zrobił logowanie przez WK za pomocą typescript i node.js? Zatrzymałem się na etapie podpisu koperty, ale zawsze dostaje odpowiedź "Błąd podczas weryfikacji podpisu lub certyfikatu w żądaniu AuthnRequest wysłanym przez system kliencki o nazwie Issuer '...': Niepoprawny podpis.". Jakieś wskazówki na przeskoczenie problemu? Czy podpisywana koperta może być w postaci stringa w jednej linii? Czy trzeba przetworzyć klucz(.key) lub certyfikat (.pem)? Używam biblioteki xml-crypto i po kilku zmianach w bibliotece wykonuje moim zdaniem identyczną postać AuthnRequest, tylko jest ona ciągiem znaków zamiast ładnie sformatowanego xml.
Pozdrawiam
- Podpisany xml bez znaków nowej linii bywa łatwiejszy do prawidłowego podpisania, choć w teorii po to jest normalizacja w trakcie generowania sygnatury żeby być na to odpornym. Ale pomagałem kiedyś komuś, bodaj w PHP, komu sygnatury generowane biblioteką phpową przechodziły przez epuap tylko jak xml był jednolinijkowy
- Bicie głową w symulator który zwraca błąd podpisu można sobie trochę złagodzić, pisałem już o tym, w moim repo na GitHub z kodem klienta dla .net, jest też zastępnik serwera, który sobie można użyć lokalnie w kontrolowanych warunkach, z kodem klienta w czymkolwiek. Różnica między moim zastępnikiem serwera a symulatorem wk jest taka że mój można lokalnie debugować, jest więc większą szansa że się wyłapie co jest nie tak
0
Cześć.
Spotkał się ktoś może z takim błędem podczas wylogowywania z WK (login-services/singleLogoutService) na symulatorze
Error reading XMLStreamReader: Unexpected character 'S' (code 83) in prolog; expected '<' at [row,col {unknown-source}]: [1,1]
Sam request wylogowania wyglada wg mnie ok.
<saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">XXXXX</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<ds:Reference URI="XXXXX">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>XXXXXX</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
XXXXXX
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>XXXXXXX</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2:NameID xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">XXXXXX</saml2:NameID>
<saml2p:SessionIndex>_XXXXXXX</saml2p:SessionIndex>
</saml2p:LogoutRequest>
0
PatrykLubiKotlina napisał(a):
Cześć.
Sam request wylogowania wyglada wg mnie ok.
Moim zdaniem nie wygląda ok. Ichniejsze wylogowanie działa na SOAP Binding, znaczy że ma być obsługiwane przez POST serwer-serwer, z kopertą SOAP nad LogoutRequest.
Jakiś przykładowy ściągnięty chwilę temu z kodu przykładowego klienta:
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/"/>
<s:Body>
<saml2p:LogoutRequest xmlns:eidas="http://eidas.europa.eu/saml-extensions"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
ID="id_943c9c2b-faf8-474c-851f-d3357b7945ee"
Version="2.0"
IssueInstant="2023-07-06T09:14:08.7578621Z"
Destination="http://localhost:44318/login-services/singleLogoutService"
xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer>http://localhost:63273</saml:Issuer>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<Reference URI="#id_943c9c2b-faf8-474c-851f-d3357b7945ee">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<DigestValue>E8yKGQ16kHh/pt5+nAFFdo5ZTQpfMqh6b1V0gY39KtU=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>ew84nuLp24Km0o...wG+w==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIICpjCCAY6gAwIBAgIIC8A8wuQV...ViYw==</X509Certificate>
</X509Data>
</KeyInfo>
</Signature>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">username</saml:NameID>
<saml2p:SessionIndex>s8daaaa5b-e116-4eea-a99f-3ae3cf1bd8c0</saml2p:SessionIndex>
</saml2p:LogoutRequest>
</s:Body>
</s:Envelope>
0
Integrował się ktoś może z systemem e-doręczeń? Jest potrzebny do tego węzeł krajowy? Są z tym jakieś problemy?
0
czesc,
robile wlasnie integracje z Wezlem Krajowym. jestem na etapie robienia integracji w javie i utknalem na wysylce artifactResolve, zastanawiam sie gdzie robie blad, bo wydaje mi sie ze prawidlowo podpisuje koperte (ale moge sie mylic)
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<soap:Body>
<saml2p:ArtifactResolve xmlns:coi-extension="http://coi.gov.pl/saml-extensions" xmlns:coi-naturalperson="http://coi.gov.pl/attributes/naturalperson" xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" xmlns:eidas="http://eidas.europa.eu/saml-extensions" xmlns:kirwb="http://wb.kir.pl/saml-extensions" xmlns:naturalperson="http://www.w3.org/2001/04/xmlenc#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" ID="ID-46b10a3a-56f8-453c-8c15-e94a78a74784" IssueInstant="2023-10-11T12:52:21Z" Version="2.0">
<saml2:Issuer>xxx</saml2:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
<ds:Reference URI="#ID-46b10a3a-56f8-453c-8c15-e94a78a74784">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces PrefixList="ds saml2 saml2p xenc"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
<ds:DigestValue>YgpSbTLN5OVhEqQX(...)</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>JJ4hjv5kq25eDnX9P0fN0rk8EM+dXSkfdKQ+6ZaO+ImxtvbSdHyJdRPADwQRmJOjqh(...)</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIICrTCCAZWgAwIBAgIIWt1Iyb(...)</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml2p:Artifact>AAQAAFJ5nb7HH1nUx52nOYz1/gffN9(...)</saml2p:Artifact>
</saml2p:ArtifactResolve>
</soap:Body>
</soap:Envelope>
strzelam POSTEM z xmlem na:
https://int.login.gov.pl/login-services/idpArtifactResolutionService
w odpowiedzi idpArtifactResolutionService dostaje:
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>pl.gov.coi.common.saml.ex.SamlXmlSignatureException: Niepoprawny podpis.</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
gdzie moglem popelnic blad? czy mieliscie podobne problemy? o dziwio SSO zwraca mi SAMLart a wykorzystuje ten sam mechanizm podpisu koperty.
korzystam z OpenSAML jak rowniez dla testu pozyczylem sobie snippet od kolegi @Dymb
do podpisu wykorzystuje plik .p12 dostarczony przez COI (z koncowka _sig)
0
Adam Włodarczyk napisał(a):
czesc,
robile wlasnie integracje z Wezlem Krajowym. jestem na etapie robienia integracji w javie i utknalem na wysylce artifactResolve, zastanawiam sie gdzie robie blad, bo wydaje mi sie ze prawidlowo podpisuje koperte (ale moge sie mylic)
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/> <soap:Body> <saml2p:ArtifactResolve xmlns:coi-extension="http://coi.gov.pl/saml-extensions" xmlns:coi-naturalperson="http://coi.gov.pl/attributes/naturalperson" xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" xmlns:eidas="http://eidas.europa.eu/saml-extensions" xmlns:kirwb="http://wb.kir.pl/saml-extensions" xmlns:naturalperson="http://www.w3.org/2001/04/xmlenc#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" ID="ID-46b10a3a-56f8-453c-8c15-e94a78a74784" IssueInstant="2023-10-11T12:52:21Z" Version="2.0"> <saml2:Issuer>xxx</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/> <ds:Reference URI="#ID-46b10a3a-56f8-453c-8c15-e94a78a74784"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces PrefixList="ds saml2 saml2p xenc"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>YgpSbTLN5OVhEqQX(...)</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>JJ4hjv5kq25eDnX9P0fN0rk8EM+dXSkfdKQ+6ZaO+ImxtvbSdHyJdRPADwQRmJOjqh(...)</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIICrTCCAZWgAwIBAgIIWt1Iyb(...)</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml2p:Artifact>AAQAAFJ5nb7HH1nUx52nOYz1/gffN9(...)</saml2p:Artifact> </saml2p:ArtifactResolve> </soap:Body> </soap:Envelope>strzelam POSTEM z xmlem na:
https://int.login.gov.pl/login-services/idpArtifactResolutionService
w odpowiedzi idpArtifactResolutionService dostaje:
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>pl.gov.coi.common.saml.ex.SamlXmlSignatureException: Niepoprawny podpis.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>gdzie moglem popelnic blad? czy mieliscie podobne problemy? o dziwio SSO zwraca mi SAMLart a wykorzystuje ten sam mechanizm podpisu koperty.
korzystam z OpenSAML jak rowniez dla testu pozyczylem sobie snippet od kolegi @Dymb
do podpisu wykorzystuje plik .p12 dostarczony przez COI (z koncowka _sig)
Jesteś pewien tego <InclusiveNamespaces .... /> ?
0
Wiktor Zychla napisał(a):
Adam Włodarczyk napisał(a):
czesc,
robile wlasnie integracje z Wezlem Krajowym. jestem na etapie robienia integracji w javie i utknalem na wysylce artifactResolve, zastanawiam sie gdzie robie blad, bo wydaje mi sie ze prawidlowo podpisuje koperte (ale moge sie mylic)
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/> <soap:Body> <saml2p:ArtifactResolve xmlns:coi-extension="http://coi.gov.pl/saml-extensions" xmlns:coi-naturalperson="http://coi.gov.pl/attributes/naturalperson" xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" xmlns:eidas="http://eidas.europa.eu/saml-extensions" xmlns:kirwb="http://wb.kir.pl/saml-extensions" xmlns:naturalperson="http://www.w3.org/2001/04/xmlenc#" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:xenc11="http://www.w3.org/2009/xmlenc11#" ID="ID-46b10a3a-56f8-453c-8c15-e94a78a74784" IssueInstant="2023-10-11T12:52:21Z" Version="2.0"> <saml2:Issuer>xxx</saml2:Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/> <ds:Reference URI="#ID-46b10a3a-56f8-453c-8c15-e94a78a74784"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"> <InclusiveNamespaces PrefixList="ds saml2 saml2p xenc"/> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> <ds:DigestValue>YgpSbTLN5OVhEqQX(...)</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>JJ4hjv5kq25eDnX9P0fN0rk8EM+dXSkfdKQ+6ZaO+ImxtvbSdHyJdRPADwQRmJOjqh(...)</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>MIICrTCCAZWgAwIBAgIIWt1Iyb(...)</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature> <saml2p:Artifact>AAQAAFJ5nb7HH1nUx52nOYz1/gffN9(...)</saml2p:Artifact> </saml2p:ArtifactResolve> </soap:Body> </soap:Envelope>strzelam POSTEM z xmlem na:
https://int.login.gov.pl/login-services/idpArtifactResolutionService
w odpowiedzi idpArtifactResolutionService dostaje:
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/> <soap:Body> <soap:Fault> <faultcode>soap:Server</faultcode> <faultstring>pl.gov.coi.common.saml.ex.SamlXmlSignatureException: Niepoprawny podpis.</faultstring> </soap:Fault> </soap:Body> </soap:Envelope>gdzie moglem popelnic blad? czy mieliscie podobne problemy? o dziwio SSO zwraca mi SAMLart a wykorzystuje ten sam mechanizm podpisu koperty.
korzystam z OpenSAML jak rowniez dla testu pozyczylem sobie snippet od kolegi @Dymb
do podpisu wykorzystuje plik .p12 dostarczony przez COI (z koncowka _sig)Jesteś pewien tego
<InclusiveNamespaces .... />?
Tak, namierzyłem problem i spowodowany był błędem w AuthNRequest, dane wysyłane do COI nie pozwalały na utworzenie systemu po stronie WK. Także gdyby ktoś miał podobny problem to polecam zwrócić uwagę na konstrukcję RequestedAttributes, muszą zawierać DOKŁADNIE takie claimy jak w dokumencie od COI. W innym wypadku nie utworzy się system dla issuera po stronie WK i mimo odpowiedzi z parametrem SAMLart, nie będzie możliwe prawidłowe odczytanie koperty ArtifactResolve po stronie idpArtifactResolutionService.
<eidas:RequestedAttributes>
<eidas:RequestedAttribute FriendlyName="FamilyName" Name="http://eidas.europa.eu/attributes/naturalperson/CurrentFamilyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<eidas:RequestedAttribute FriendlyName="FirstName" Name="http://eidas.europa.eu/attributes/naturalperson/CurrentGivenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<eidas:RequestedAttribute FriendlyName="DateOfBirth" Name="http://eidas.europa.eu/attributes/naturalperson/DateOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
<eidas:RequestedAttribute FriendlyName="PersonIdentifier" Name="http://eidas.europa.eu/attributes/naturalperson/PersonIdentifier" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" isRequired="true"/>
</eidas:RequestedAttributes>
aktualnie jestem na etapie odszyfrowania asercji (EncryptedAssertion) - jakby ktoś miał gotowy kawałek w javie to byłbym bardzo wdzięczny za podrzucenie :)