Wątek przeniesiony 2017-11-27 13:03 z Newbie przez somekind.

Uwierzytelnianie ePUAP na podstawie danych z Profilu Zaufanego

2
fijau napisał(a):

Rozumiem, że ze środowiska produkcyjnego PZ obecnie może korzystać tylko instytucja publiczna. Zgadza się? Czy orientujecie się w takim razie czy i jeśli tak to kiedy może nastąpić udostępnienie PZ dla firm?

Rola "Instytucja publiczna" jest przeznaczona dla organów administracji publicznej. Na tym polega cała trudność integracji z EPUAP. Środowisko testowe w wielu przypadkach zachowuje się odmiennie w stosunku do produkcji, dokumentacja mija się z prawdą (nie jest aktualizowana zbyt często), a dostęp do produkcji może mieć tylko faktyczna instytucja publiczna.

0

Czesc

czy z waszego doswiadczenia wynika ze na TEST istotny jest URL z ktorego sie wykonuje wywolanie do epupau (nazwa serwera podana we wniosku) czy moze to byc dowolny inny, np localhost?

Dzieki za informajce.

pozdrawiam
Grzegorz

0

Epuap nawet w srodowisku testowym nie pozwala na konfigurację adresu na localhost

0
grzesiek00 napisał(a):

Czesc

czy z waszego doswiadczenia wynika ze na TEST istotny jest URL z ktorego sie wykonuje wywolanie do epupau (nazwa serwera podana we wniosku) czy moze to byc dowolny inny, np localhost?

Dzieki za informajce.

pozdrawiam
Grzegorz

Cześć,

Twoja aplikacja może być postawiona na Twoim komputerze (localhost) i możesz odpytywać EPUAP, ale nie przeprowadzisz całego procesu logowania ponieważ EPUAP w całym procesie kilkukrotnie odpytuje zarejestrowane we wniosku adresy URL. Muszą one być publicznymi adresami. Dane, które są przekazywane tą drogą są niezbędne aby przejść przez cały proces logowania. Testowanie aplikacji najłatwiej jest wykonywać na zainstalowanej instancji, na fizycznym serwerze, z wystawionym publicznym adresem IP.

Pozdrawiam,
Kuba

0
kub3l napisał(a):
grzesiek00 napisał(a):

Czesc

czy z waszego doswiadczenia wynika ze na TEST istotny jest URL z ktorego sie wykonuje wywolanie do epupau (nazwa serwera podana we wniosku) czy moze to byc dowolny inny, np localhost?

Dzieki za informajce.

pozdrawiam
Grzegorz

Cześć,

Twoja aplikacja może być postawiona na Twoim komputerze (localhost) i możesz odpytywać EPUAP, ale nie przeprowadzisz całego procesu logowania ponieważ EPUAP w całym procesie kilkukrotnie odpytuje zarejestrowane we wniosku adresy URL. Muszą one być publicznymi adresami. Dane, które są przekazywane tą drogą są niezbędne aby przejść przez cały proces logowania. Testowanie aplikacji najłatwiej jest wykonywać na zainstalowanej instancji, na fizycznym serwerze, z wystawionym publicznym adresem IP.

Pozdrawiam,
Kuba

Dzięki za odpowiedz i komentarz.

1
kub3l napisał(a):

Twoja aplikacja może być postawiona na Twoim komputerze (localhost) i możesz odpytywać EPUAP, ale nie przeprowadzisz całego procesu logowania ponieważ EPUAP w całym procesie kilkukrotnie odpytuje zarejestrowane we wniosku adresy URL. Muszą one być publicznymi adresami. Dane, które są przekazywane tą drogą są niezbędne aby przejść przez cały proces logowania. Testowanie aplikacji najłatwiej jest wykonywać na zainstalowanej instancji, na fizycznym serwerze, z wystawionym publicznym adresem IP.

Pozdrawiam,
Kuba

Ponieważ materiałów opisujących integrację jest niewiele a ślad po wszystkim co się w sieć wrzuci w tejże sieci zostaje, czuję się w obowiązku założyć konto po to żeby to sprostować. Ktoś w przyszłości kto tu trafi przez wyszukiwarkę, będzie miał szansę znaleźć również sprostowanie, a nie tylko informację, która niepotrzebnie wprowadza w błąd.

Żaden krok autentykacji ePUAP ani potem odpytywania usług integracyjnych (typu getTpUserInfo) nie wymaga odpytywania adresów URL, specyfikacje protokołów są bowiem typu klient-serwer a nie serwer-serwer, jeżeli nawet występuje w przebiegu protokołu odwołanie do wskazanego adresu to jest to przekierowanie a nie odpytanie przez ePUAP. A ponieważ przekierowanie odbywa się na lokalnej maszynie, integracja może odbywać się nawet z domeny która rozwiązuje się przez /etc/hosts. Dla środowiska deweloperskiego - rozwiązanie idealne.

Chętnie się dowiem że jest inaczej, póki co proszę jednak autora powyższej wypowiedzi o odniesienie się do tego komentarza.

Doświadczenia z przejścia ścieżki integracyjnej spisałem na blogu

http://www.wiktorzychla.com/2018/03/sso-integracja-z-epuap-dostawca.html

0

Zgadzam się z tym co pisze użytkownik @torq314.
Issuera mam podanego jako adres https://epuap.giga.katowice.pl.
Natomiast adres zwrotny dla SSO https://epuap.giga.katowice.pl:44315/signin-epuap

Następnie w pliku hosts.etc mam linie
127.0.0.1 epuap.giga.katowice.pl
Serwer www nasłuchuję (a dokładnie serwer developerski z Visual Studio) na localhost na porcie 44315

I wszystko działa następująco:

  1. Moja strona wysyła żądanie do PZ z prośbą o autoryzacją
  2. PZ przekierowuje do formularza logowania
  3. Po poprawnym zalogowaniu PZ przekierowuje na podany przeze mnie adres SSO
  4. Dzięki odpowiedniej konfiguracji pliku hosts.etc, żądania trafiają bezpośrednio do Visual Studio

Panie @torq314 bardzo dziękuję za pomoc. Jakbym czytał własne przemyślenia dotyczące walki z PZ.

0
torq314 napisał(a):
kub3l napisał(a):

Twoja aplikacja może być postawiona na Twoim komputerze (localhost) i możesz odpytywać EPUAP, ale nie przeprowadzisz całego procesu logowania ponieważ EPUAP w całym procesie kilkukrotnie odpytuje zarejestrowane we wniosku adresy URL. Muszą one być publicznymi adresami. Dane, które są przekazywane tą drogą są niezbędne aby przejść przez cały proces logowania. Testowanie aplikacji najłatwiej jest wykonywać na zainstalowanej instancji, na fizycznym serwerze, z wystawionym publicznym adresem IP.

Pozdrawiam,
Kuba

Ponieważ materiałów opisujących integrację jest niewiele a ślad po wszystkim co się w sieć wrzuci w tejże sieci zostaje, czuję się w obowiązku założyć konto po to żeby to sprostować. Ktoś w przyszłości kto tu trafi przez wyszukiwarkę, będzie miał szansę znaleźć również sprostowanie, a nie tylko informację, która niepotrzebnie wprowadza w błąd.

Żaden krok autentykacji ePUAP ani potem odpytywania usług integracyjnych (typu getTpUserInfo) nie wymaga odpytywania adresów URL, specyfikacje protokołów są bowiem typu klient-serwer a nie serwer-serwer, jeżeli nawet występuje w przebiegu protokołu odwołanie do wskazanego adresu to jest to przekierowanie a nie odpytanie przez ePUAP. A ponieważ przekierowanie odbywa się na lokalnej maszynie, integracja może odbywać się nawet z domeny która rozwiązuje się przez /etc/hosts. Dla środowiska deweloperskiego - rozwiązanie idealne.

Chętnie się dowiem że jest inaczej, póki co proszę jednak autora powyższej wypowiedzi o odniesienie się do tego komentarza.

Doświadczenia z przejścia ścieżki integracyjnej spisałem na blogu

http://www.wiktorzychla.com/2018/03/sso-integracja-z-epuap-dostawca.html

Witam,

na wstępie chciałbym zaznaczyć, że nie miałem zamiaru nikogo wprowadzać w błąd, a raczej pomóc innym zmagającym się z integracją. Przyznam szczerze, że nie wiedziałem o tym fakcie, który Pan opisuję, a dokładniej, musiałem błędnie zinterpretować zachowanie EPUAP-u. Dziękuję za sprostowanie mojej informacji i mogę zapewnić, że zweryfikuję czy faktycznie jest to tylko przekierowanie, a nie zapytania typu REST kierowane ze strony EPUAP.

Pozdrawiam,
Kuba

0

na wstępie chciałbym zaznaczyć, że nie miałem zamiaru nikogo wprowadzać w błąd, a raczej pomóc innym zmagającym się z integracją. Przyznam szczerze, że nie wiedziałem o tym fakcie, który Pan opisuję, a dokładniej, musiałem błędnie zinterpretować zachowanie EPUAP-u. Dziękuję za sprostowanie mojej informacji i mogę zapewnić, że zweryfikuję czy faktycznie jest to tylko przekierowanie, a nie zapytania typu REST kierowane ze strony EPUAP.

Dziękuję.

Wiadomo że ewentualna nieścisłość, jeśli się pojawiła, to nie jest zamierzona. A ta integracja jest stosunkowo żmudna sama z siebie, z tym dodatkowym ograniczeniem konieczności pracy na publicznych adresach byłaby jeszcze trudniejsza.

Btw. żaden znany mi protokół SSO, z którymi pracowałem (w tym OAuth2, OpenIDConnect, WS-Fed i SAML2) nie wymaga od strony aplikacji publicznego adresu, ponieważ ewentualne przekierowania rozwiązuje przeglądarka a nie serwer. Do zweryfikowania autentyczności żądania dostawcy używają albo client_secret (rodzina OAuth2) albo podpisu (rodzina oparta na SAML/JWT), nie ma potrzeby żądania od dostawcy usługi do aplikacji.

0

Podepnę się pod ten wątek. Mam aplikację webową, która będzie wykorzystywana przez zalogowanych użytkowników. Do uwierzytelnienia planowane jest wykorzystanie ePUAP. Jakie po kolei kroki będą musiały być wykonane przez użytkownika i przez system w tle, aby udało się to zrealizować?

0

Pracuję właśnie nad integracją programu Gabinetowego (aplikacja desktopwą) z systemem eZLA
Aby móc zalogować się do systemu potrzebuję sygnatury z profilu zaufanego ePUAP

Może ktoś z państwa wie jak to dokonać?

0

Czy ktoś, to ogarnął do końca w .NET?

0

Witam
Od jakiegoś czasu walczę z PZ, niestety jest to walka z ...
No ale do rzeczy
Po długich miesiącach dostałem upragniony certyfikat od coi, udało mi się nawet stworzyć poprawny AuthnRequest.
Wcześniejsze wpisy na tym forum były bardzo pomocne. Lecz niestety dalej porażka, wiele godzin kombinacji z podpisaniem ArtifactResolve i ciągle powtarzająca się odpowiedź: "Niepoprawny podpis".
Jak wiecie kontakt z coi ... nie będę komentował.
Owszem przez chwilę byli całkiem pomocni. Nawet w ciągu jednego dnia odpowiedzieli ze dwa razy:)
Ale dalej, muszę się zwrócić o pomoc tutaj.
Czy mógłby ktoś coś więcej opisać, rzucić kawałkiem kodu może.
Walkę podjąłem w PHP. Wiem że w JAVA było by łatwiej, ale proszę o pomoc PHP'owców.

0
unikat112 napisał(a):

Witam
Od jakiegoś czasu walczę z PZ, niestety jest to walka z ...
No ale do rzeczy
Po długich miesiącach dostałem upragniony certyfikat od coi, udało mi się nawet stworzyć poprawny AuthnRequest.
Wcześniejsze wpisy na tym forum były bardzo pomocne. Lecz niestety dalej porażka, wiele godzin kombinacji z podpisaniem ArtifactResolve i ciągle powtarzająca się odpowiedź: "Niepoprawny podpis".
Jak wiecie kontakt z coi ... nie będę komentował.
Owszem przez chwilę byli całkiem pomocni. Nawet w ciągu jednego dnia odpowiedzieli ze dwa razy:)
Ale dalej, muszę się zwrócić o pomoc tutaj.
Czy mógłby ktoś coś więcej opisać, rzucić kawałkiem kodu może.
Walkę podjąłem w PHP. Wiem że w JAVA było by łatwiej, ale proszę o pomoc PHP'owców.

IMO integracja w php moze być po prostu niemożliwa. Nie wiem czy jest biblioteka, która potrafi tak podpisać kopertę, żeby PZ jej nie odrzucił. Chyba, że czujesz się na siłach napisać jakąś własną klasę do podpisywania. Ja temat integracji w PHP odpuściłem dawno temu i Tobie polecam to samo.

0

Wie ktoś, o co chodzi z tym dziwnym wsdlem do tpUserInfo? https://pz.gov.pl/pz-services/tpUserInfo?wsdl
Dotyczy to zresztą chyba wszystkich usług PZ:
Mamy wsp:PolicyReference do #SecurityServiceSignInputPolicy oraz #SecurityServiceSignOutputPolicy, ale nie widzę nigdzie wsp:Policy. Mój kod też nie widzi.

ok, ogarnięte: okazało się że trzeba zerknąć na https://pz.gov.pl/pz-services/tpUserInfo?wsdl=wssec-policies.wsdl ...

W ogóle jakby ktoś jeszcze miał problem że AuthnRequest działa a ArtifactResolve nie (zły podpis) to można sprawdzić CanonicalizationAlgorithm - ja np. używałam http://www.w3.org/TR/2001/REC-xml-c14n-20010315 a powinno być http://www.w3.org/2001/10/xml-exc-c14n# (na blogu https://www.wiktorzychla.com/2018/03/sso-integracja-z-epuap-dostawca.html już o tym było)

0

Witam,
Toczę nierówną walkę z ArtifactResolve i mimo tego, że request wydaje się być zgodny z tym co koledzy i koleżanki publikowali wcześniej na forum, to cały czas dostaję odpowiedź:

com.pentacomp.common.saml.ex.SamlXmlSignatureException: Niepoprawny podpis.

Mój XML wygląda następująco:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
	<soapenv:Header />
	<soapenv:Body>
		<saml2p:ArtifactResolve ID="_84221eaa-d037-4278-b1ae-c64c65b539c1" Version="2.0" IssueInstant="2019-10-11T10:45:59.077Z" xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
			<saml2:Issuer>http://localhost:55222/</saml2: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#rsa-sha256" />
					<Reference URI="#_84221eaa-d037-4278-b1ae-c64c65b539c1">
						<Transforms>
							<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
							<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
								<InclusiveNamespaces PrefixList="ds saml2 saml2p" xmlns="http://www.w3.org/2001/10/xml-exc-c14n#" />
							</Transform>
						</Transforms>
						<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
						<DigestValue>dEZmeGoUqw7nEXgiZuLWe7PvwBtjq1V2VKRFduW41Jc=</DigestValue>
					</Reference>
				</SignedInfo>
				<SignatureValue>Hll5YbghviQiW4UwJ3Y(..)</SignatureValue>
				<KeyInfo>
					<X509Data>
						<X509Certificate>MIIDZTCCAk2gAwIB(..)</X509Certificate>
					</X509Data>
				</KeyInfo>
			</Signature>
			<saml2p:Artifact>AAQAAKFbFR94fxqmioAqjJUwfyUtjJbvUrUM29L6T7oP6OXLt7tjmwjRCFE=</saml2p:Artifact>
		</saml2p:ArtifactResolve>
	</soapenv:Body>
</soapenv:Envelope>

Nie mam już pomysłów, w czym może tkwić błąd.
Podpisuję element <saml2p:ArtifactResolve> i jeżeli weryfikuję podpis u siebie, to wszystko jest ok.
Czy ktoś, kto już ma poprawnie działający request mógłby go tu zamieścić?
Czy konieczne jest używanie transformaty http://www.w3.org/2002/06/xmldsig-filter2, jak to podane jest w przykładzie z dokumentu https://epuap.gov.pl/wps/wcm/connect/fecfa24a-13b5-4c40-9456-5b379ec14974/Instrukcja_Integratora_DT.pdf?MOD=AJPERES ?

0

Dzięki za wskazówki. Sprawdziłem obydwa serwisy:
W pierwszym wyrzuca mi odpowiedź:

com.pentacomp.common.saml.ex.SamlXmlSignatureException: Wiadomość ArtifactResolve nie jest podpisana.

Co jest zrozumiałe, ponieważ nie mogę za pomocą ich interfejsu wprowadzić podpisu. :)

Natomiast na drugim dostaję dokładnie tą samą odpowiedź co u siebie, czyli Nieprawidłowy podpis...

0

nie patrzyłam dokładnie na xml-a, ale czy na pewno masz dobrze podanego Issuera (localhost??) i SSO callback address?

1

Już wiem co było przyczyną niepoprawnego podpisu...
Tworząc dokument XML używałem:

            XmlDocument xmlDocument = new XmlDocument();

Po zmianie na:

            XmlDocument xmlDocument = new XmlDocument()
            {
                PreserveWhitespace = true,
            };

podpis działa poprawnie.

Odnośnie issuera, to taką nazwę podałem do ePUAP, więc takiego używam :)

0

Staram się właśnie wykonać integrację z PZ SSO. Zacząłem od czytania instrukcji na epuap. Okazało się że tam nie ma nic co jest potrzebne. Mam parę pytań.

  1. Do konsoli draco wgrywamy certyfikat który dostaliśmy od COI w odpowiedzi na wniosek o integrację?
  2. Jeśli tak kto który bo w pliku certyfikat.txt są dwa:
Subject: CN=http://adres.pl,O=nazwa,C=PL
Issuer: CN=INT_ePUAPiPZ
-----BEGIN CERTIFICATE-----
{certyfikat}
-----END CERTIFICATE-----
Subject: CN=INT_ePUAPiPZ
Issuer: CN=INT_ePUAPiPZ
-----BEGIN CERTIFICATE-----
{certyfikat}
-----END CERTIFICATE-----
  1. Jeśli nie to który powinien się znaleźć?
  2. czy powinien być przetransformowanyt z .p12 do .pem (X509) ?
  3. Do wysłania zapytania AuthnRequest potrzebujemy XML (mój poniżej). W jaki sposób go podpisujemy ? Którym certyfikatem? czy coś z tym certyfikatem musimy zrobić?
<saml2p:AuthnRequest xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="AdresurlZwrotny/epuap/" ID="ID-ad9a26a8-c3b9-478e-8ceb-51e38bf04d1f" Version="2.0" IssueInstant="2019-11-04T14:30:30+02:00" Destination="https://pz.gov.pl/dt/SingleSignOnService" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact">
  <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">Nazwa systemu w draco</saml2:Issuer>
  <saml2p:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"/>
</saml2p:AuthnRequest>
0

Do konsoli draco wgrywamy certyfikat który dostaliśmy od COI w odpowiedzi na wniosek o integrację?

Nie wgrywałem żadnego certyfikatu do konsoli Draco. Nie mogłem się w ogóle do niej zalogować.
Natomiast przy zgłaszaniu prośby o certyfikat zaznaczyłem opcje:

[X] Dostęp do SignatureVerification
[X] Dostęp do TpSigning
[ ] Dostęp do TpMultisign
[X] Dostęp do usług Single Sign-On i Single Logout
[X] Dostęp do TpUserInfo

I mam możliwość SSO oraz podpisywania dokumentów.

czy powinien być przetransformowanyt z .p12 do .pem (X509) ?

Ja przetransformowałem go do pfx. Procedura z której skorzystałem opisana jest tutaj:
https://www.componentspace.com/Forums/1578/SHA256-and-Converting-the-Cryptographic-Service-Provider-Type

Do wysłania zapytania AuthnRequest potrzebujemy XML (mój poniżej). W jaki sposób go podpisujemy ? Którym certyfikatem? czy coś z tym certyfikatem musimy zrobić?

Podpisujemy go kluczem prywatnym wygenerowanym podczas tworzenia żądania certyfikatu.

0
jakub-pawlowski napisał(a):

Do konsoli draco wgrywamy certyfikat który dostaliśmy od COI w odpowiedzi na wniosek o integrację?

Nie wgrywałem żadnego certyfikatu do konsoli Draco. Nie mogłem się w ogóle do niej zalogować.
trzeba dać przypomnij hasło i mailem dostajesz

Natomiast przy zgłaszaniu prośby o certyfikat zaznaczyłem opcje:

[X] Dostęp do SignatureVerification
[X] Dostęp do TpSigning
[ ] Dostęp do TpMultisign
[X] Dostęp do usług Single Sign-On i Single Logout
[X] Dostęp do TpUserInfo
teraz we wniosku tego nie ma (ja nie miałem)

I mam możliwość SSO oraz podpisywania dokumentów.

czy powinien być przetransformowanyt z .p12 do .pem (X509) ?

Ja przetransformowałem go do pfx. Procedura z której skorzystałem opisana jest tutaj:
https://www.componentspace.com/Forums/1578/SHA256-and-Converting-the-Cryptographic-Service-Provider-Type

Do wysłania zapytania AuthnRequest potrzebujemy XML (mój poniżej). W jaki sposób go podpisujemy ? Którym certyfikatem? czy coś z tym certyfikatem musimy zrobić?

Podpisujemy go kluczem prywatnym wygenerowanym podczas tworzenia żądania certyfikatu.

0

trzeba dać przypomnij hasło i mailem dostajesz

A to nie wiedziałem. Logowałem się tym samym hasłem co na profil zaufany.
Spróbuję zrobić, tak jak napisałeś. Natomiast nie zmienia to faktu,że nic nie wgrywałem do Draco.

teraz we wniosku tego nie ma (ja nie miałem)

A jak składałeś wniosek o certyfikat?
Przez skrzynkę podawczą na koncie ePUAP podmiotu publicznego? Link do wniosku:
https://int.epuap.gov.pl/wps/myportal/strefa-klienta/katalog-spraw/opis-uslugi/wniosek-o-certyfikat-do-srodowiska-integracyjnego

Bo w nim nadal są checkbox'y do zaznaczenia:
Dostęp do SignatureVerification
Dostęp do TpSigning
Dostęp do TpMultisign

A dostępy do SSO, SLO i TpUserInfo są pewnie przyznawane jak wypełnisz pola w sekcji "Uprawnienia do logowania SSO" we wniosku z linka.

0
jakub-pawlowski napisał(a):

trzeba dać przypomnij hasło i mailem dostajesz

A to nie wiedziałem. Logowałem się tym samym hasłem co na profil zaufany.
Spróbuję zrobić, tak jak napisałeś. Natomiast nie zmienia to faktu,że nic nie wgrywałem do Draco.

teraz we wniosku tego nie ma (ja nie miałem)

A jak składałeś wniosek o certyfikat?
Przez skrzynkę podawczą na koncie ePUAP podmiotu publicznego? Link do wniosku:
https://int.epuap.gov.pl/wps/myportal/strefa-klienta/katalog-spraw/opis-uslugi/wniosek-o-certyfikat-do-srodowiska-integracyjnego
**na int mam tak jak mówisz ale na PROD już nie. **

Bo w nim nadal są checkbox'y do zaznaczenia:
Dostęp do SignatureVerification
Dostęp do TpSigning
Dostęp do TpMultisign

A dostępy do SSO, SLO i TpUserInfo są pewnie przyznawane jak wypełnisz pola w sekcji "Uprawnienia do logowania SSO" we wniosku z linka.
Wybrałem tylko SSO na INT i na PROD

0

mam problem z pierwszym XML

Po przekonwertowaniu na byte[] później na base64 i wysłaniu za pomocą formularza jako parametr SAMLRequest do staję Nieprawidłowe żądanie HTTP..
wzorowałem się na https://bitbucket.org/snippets/rybirek/ky7Aeb#file-AuthnRequest.xml

czy jest ktoś w stanie podpowiedzieć ?

<saml2p:AuthnRequest AssertionConsumerServiceURL="http://[url]/logged" Destination="https://pz.gov.pl/dt/SingleSignOnService" ID="_1d1d730c-a101-4f67-858f-1a9de995e757" IssueInstant="2019-11-05T13:50:48Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Version="2.0" 
    xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">**[IDENTYFIKATOR Z DRACO]**</saml2:Issuer>
    <saml2:NameIDPolicy AllowCreate="true" Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" 
        xmlns:saml2="http://www.w3.org/2000/09/xmldsig#" />
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <ds:Reference URI="#_1d1d730c-a101-4f67-858f-1a9de995e757">
                <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/2000/09/xmldsig#sha1" />
                <ds:DigestValue>NbEJ6ftKP0Z ... 3Q2Y2cb76+KpR/k=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>OqVttBrCagXeQ9Fh+yyd/S1CV0BezGt ... csxNetSnzdSf91JI0wS9Fd6TVkNZ3KmKw==</ds:SignatureValue>
    </ds:Signature>
</saml2p:AuthnRequest>

Jeszcze jedno pytanie.
czy Issuer to
nazwa systemu w Draco ?
identyfikator w Draco?
czy nazwa systemu we Wniosku o certyfikat?

PS: problemem może być to że form jest wywoływany lokalnie?

0

czy wiecie jaką może być przyczyna ** Dostęp zabroniony.**
screenshot-20191106132142.png

0

Cześć,
orientuje się ktoś może jak wygląda sprawa integracji z usługami PZ dla instytucji niepublicznych i co musi zostać spełnione, żeby zostać zewnętrznym dostawca tożsamości?
Próbowałem coś znaleźć w sieci, ale główne wątki i artykuły dotyczyły instytucji publicznych.

0

Udało mi się zrobić skuteczną implementacje
AuthnRequest -> Artifactresolve -> getTpUserInfo w PHP
jeśli ktoś ma problemy mogę pomóc

0
Bart Urbanczyk napisał(a):

Udało mi się zrobić skuteczną implementacje
AuthnRequest -> Artifactresolve -> getTpUserInfo w PHP
jeśli ktoś ma problemy mogę pomóc

Czy mógłbyś podesłać przykładowy AuthnRequest?
(oczywiście z wyczyszczonym certyfikatem itd.)

1 użytkowników online, w tym zalogowanych: 1, gości: 0