Uwierzytelnianie ePUAP na podstawie danych z Profilu Zaufanego

@Sasser: zerknij w dokumentacje na usługę Multisign, tutaj możesz mieć załączniki w postaci PDFów zerknij na element attachmentDto

JacekStawicki360 napisał(a):

@Wiktor Zychla:

Dziękuję. Twoja pomoc jest nieoceniona.

Wracam z kolejnym pytaniem.
Z demo chcę wykonać "Signing an XML document with Profil Zaufany"
Wszystko fajnie tylko, że na stronie epuap mam do dyspozycji jedynie "Podpisz podpisem kwalifikowanym".

Nie wiem dlaczego nie ma opcji podpisu Profilem zaufanym i np. bankiem.
Może wiesz co jest tego powodem?

Druga sprawa. Wykonaując "Single Sign-on through Profil Zaufany" od razu wyrzuca błąd HTTP Error 401.0 - Unauthorized
zamiast przekierować na /Account/Logon

Zostawię to info dla potomnych. Otóż nie widać opcji podpisu PZ gdy nie ma się założonego Profilu Zaufanego na platformie testowej można to zrobić przez formularz i jako hasła jednorazowego użyć 12345678 a potem odczekać 2tyg aż łaskawie nadadzą.

@Bart Urbanczyk: I potem mogę wyciągnąć z tego podpisany dokument PDF?

Mam problem z przejściem z TpSigning do Tpsigning5. Bez problemu łączę się z TpSigning, ale gdy próbuję się łączyć z TpSigning5, Profil Zaufany zwraca błąd ns1:SecurityError.
Na wniosku składanym przez ePUAP nie miałem zaznaczonego TpSigning5 (wówczas o nim nie wiedziałem), czy mogę nie mieć dostępu do usług TpSigning5?

@EgzoT: tak, to jest osobne uprawnienie i certyfikaty które miały dostęp do TpSigning nie mają z automatu uprawnienia do TpSigning5

@Bart Urbanczyk: teraz sporo tworzymy kont testowych na testowym epuap i jak się wyśle maila na [email protected] z treścią że się prosi o potwierdzenie profilu testowego takiego-a-takiego to nie czekamy teraz dłużej niż 24h, a czasem nawet tego samego dnia jest informacja zwrotna.

Może ktoś z was się spotkał z następującym błędem w TpSigning5, przy łączeniu z TpSigning ten problem nie występował:
soap:Client
Unmarshalling Error: unexpected (uri:"http://signing.ws.comarch.gov", local:"doc"). Expected elements are <{}selectedSignatureMethod>,<{}cancelURL>,<{}additionalInfo>,<{}doc>,<{}successURL>,<{}failureURL>

Aktualizacja:
Udało mi się to rozwiązać, należy dodać pustą wartość xmlns="".
U mnie za pomocą:
doc.setAttributeNS(Constants.NamespaceSpecNS, "xmlns", "")

Cześć,
Potrzebuję podpowiedzi od kogoś, komu udało się zintegrować z Węzłem Krajowym.

Chcemy zintegrować się z WK, ponieważ pragniemy dać użytkownikom naszego oprogramowania możliwość uwierzytelniania w Krajowym Systemie e-faktur za pomocą PZ.

W dokumencie https://mc.bip.gov.pl/fobjects/download/1183960/zal-1-warunki-przylaczenia-do-wezla-krajowego-dostawcy-uslug-du-docx-docx.html znajduje się informacja:

W celu uzyskania dostępu do środowiska testowego należy złożyć pismo drogą elektroniczną ePUAP skierowane do Departamentu Tożsamości Cyfrowej KPRM z prośbą o udzielenie dostępu do środowiska testowego (symulatora).

Pytanie: logując się do ePUAP jako kto?
Firma, dla której pracuje jest spółka akcyjną. Rozmawialiśmy z sekretariatem Departamentu Tożsamości Cyfrowej KPRM - zadano nam pytanie, czy jesteśmy podmiotem publicznym. Odpowiedzieliśmy, że nie. Jest to - rzekomo - przeszkodą w integracji. Pani z sekretariatu ma się, jednak, z kimś jeszcze skonsultować...

Jak przebrnęliście przez ten początkowy etap?

Będę niezwykle wdzięczny za wszelkie sugestie.

@Wojtek P: Nie ma takiej możliwości, żeby komercyjne oprogramowanie, nie będące w dyspozycji podmiotu publicznego, tylko kogoś innego, było zintegrowane z WK. Procedurę przyłączeniową może inicjować i prowadzić tylko podmiot publiczny (technicznie może to scedować na kogoś). Mamy już działające przyłączenia i wiadomo że to się może zmieniać z dnia na dzień, ale jeśli się nie zmieniło, to jest tak jak piszę. Jeżeli uda się wywalczyć wyjątek, to pogratulować.

Zamiast używać prawdziwego symulatora, do przygotowania kodu można użyć zastępnika z mojego githuba, to pozwoli przygotować implementację klienta, ale nadal pozostaje przyłączenie tego klienta do testowego a potem produkcyjnego WK, a to można zrobić tylko w imieniu podmiotu publicznego.

@Wiktor Zychla:

Chodzi o podpis zaufany (aka "podpis profilem zaufanym", "e-podpis"), który jest jednym z możliwych tzw. wektorów uwierzytelnienia w API KSeF (Krajowy System e-faktur). (Oczywiście, nie jest to jego jedyne zastosowanie, tylko specyficzna potrzeba oprogramowania produkowanego przez firmę, dla której pracuję.)

Dokumentacja metody TpSigning5 jest dostępna:

• na stronie "Węzeł Krajowy - dokumentacja dotycząca integracji z Węzłem Krajowym" - https://mc.bip.gov.pl/interoperacyjnosc-mc/wezel-krajowy-dokumentacja-dotyczaca-integracji-z-wezlem-krajowym.html, w dokumencie "INSTRUKCJA DLA INTEGRATORA E-PODPIS" (https://mc.bip.gov.pl/fobjects/download/640820/zal-7-ep_instrukcja-dla-integratora-pdf.html).

• na stronie zatytułowanej "Integracja z podpisem zaufanym" https://mc.bip.gov.pl/integracja-z-podpisem-zaufanym/e-podpis-tps5-dokumentacja-dotyczaca-integracji-z-podpisem-zaufanym-oraz-podpisem-osobistym.html, w pdf-ie zatytułowanym identycznie, jak ten wspomniany wyżej (https://mc.bip.gov.pl/fobjects/download/1032554/instrukcja-dla-integratora-e-podpis-tps5-pdf.html).

Nie zdziwiłbym się, gdyby była zamieszczona jeszcze gdzieś indziej...

Wygląda na to, że obie wspomniane wyżej "INSTRUKCJE DLA INTEGRATORA E-PODPIS" opisują to samo API. Niemniej, ta ze strony "Węzeł Krajowy - dokumentacja dotycząca integracji z Węzłem Krajowym" ma wersję 1.0, zaś ta z "Integracja z podpisem zaufanym" wersję 0.9. Dodatkowo, w ciekawy sposób różnią się one, m.in., historiami zmian dokumentu.

Dla integracji z e-podpisem istnieje procedura nadawania dostępu do API, opisana w dokumencie "Procedura integracji systemów oraz wymiany certyfikatu do integracji systemów z podpisem zaufanym" (https://mc.bip.gov.pl/fobjects/download/1119900/procedura-integracji-systemow-z-profilem-zaufanym-pdf.html). Możemy w niej przeczytać, m.in:

Podmiot, który zamierza wykorzystywać usługi dostępne w Profilu Zaufanym, musi posiadać uprawnienia podmiotu publicznego, zgodnie z ustawą z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.

Czyli, jest to zgodne z tym, co napisał @Wiktor Zychla 1 post wyżej.

W punkcie 3.3 "Procedury integracji systemów oraz wymiany certyfikatu do integracji systemów z podpisem zaufanym" wymienione są elementy wniosku o dostęp do usług ePUAP. Wśród nich mamy, m.in:

• Adres zwrotny dla SSO (węzeł krajowy) - Adres zwrotny dla SSO, ustalany przy integracji z węzłem krajowym
• Issuer (węzeł krajowy) - Issuer ustalany przy integracji systemu z węzłem krajowym

Z czego wynika, że do podpisywania dokumentów trzeba być jednak zintegrowanym z WK. Albowiem: skąd inaczej weźmiemy ""adres zwrotny dla SSO" i "Issuera"?

Jak wygląda obecnie wnioskowanie do testowego/integracyjnego Węzła Krajowego? Czy mogę podobnie jak z TpSigning założyć testowe konto oraz złożyć wniosek do COI o przydzielenie certyfikatu? Czy też wnioskowanie jest bardziej skomplikowane?

EgzoT napisał(a):

Jak wygląda obecnie wnioskowanie do testowego/integracyjnego Węzła Krajowego? Czy mogę podobnie jak z TpSigning założyć testowe konto oraz złożyć wniosek do COI o przydzielenie certyfikatu? Czy też wnioskowanie jest bardziej skomplikowane?

Jeśli nic się nie zmieniło, to wniosek można złożyć tylko jako podmiot publiczny. Nawet do środowiska symulatora wniosek musiał mieć podkładkę. Ale to było jakiś czas temu i może jest inaczej. Na produkcję - raczej tylko podmiot publiczny.

Przy podpisywaniu i nadawaniu pisma z UPD (doręczyciel) wyskakuje mi taki błąd:

"Certyfikat niekwalifikowany, lub nieznany wystawca certyfikatu ### Status podpisu: 0 (Zgodny z dokumentem)., status certyfikatu: 3 (Nieznany wystawca) niekwalifikowany"

Co może być przyczyną? Przy wysyłaniu bez UPD oraz odbieraniu dokumentów nie ma takiego problemu. Certyfikat jest podpięty pod PZ.

Sasser napisał(a):

Przy podpisywaniu i nadawaniu pisma z UPD (doręczyciel) wyskakuje mi taki błąd:

"Certyfikat niekwalifikowany, lub nieznany wystawca certyfikatu ### Status podpisu: 0 (Zgodny z dokumentem)., status certyfikatu: 3 (Nieznany wystawca) niekwalifikowany"

Co może być przyczyną? Przy wysyłaniu bez UPD oraz odbieraniu dokumentów nie ma takiego problemu. Certyfikat jest podpięty pod PZ.

Nigdy nie mieliśmy case biznesowego żeby tej funkcji używać, ale jak używałem jej sam dla siebie, żeby spróbować czy działa, to przechodziły tylko dokumenty podpisane podpisem kwalifikowanym. W każdym innym przypadku był błąd. Czyli nie można było ani niepodpisanego wysłać, ani podpisanego Profilem Zaufanym (sic!), ani żadnym innym certyfikatem. W dodatku, to nie mógł być byle jaki podpis, nie wystarczał prosty XMLDSig, tylko dokument musiał być zgodny z XAdES (wystatczył najprostszy, XAdES-BES)

Nie wiem dlaczego to tak działa, dokumentacja jeśli dobrze pamiętam nic nie mówi o warunkach jakie musi spełniać podpis.

Chyba zgodnie z tym co zapowiadali odłączyli wczoraj Profil Zaufany i logowanie oraz tpsigning przestały działać...
Gdyby ktoś szukał ekspresowego supportu przy przejściu do wersji Węzła Krajowego w PHP proszę pisać na priv.

Udało nam się uzyskać certyfikat do starej PZ, jednak i tak musimy się przenieś na WK. @Wiktor Zychla @Bart Urbanczyk Nie wiecie czy teraz jest jakoś łatwiej? Chcemy zrobić osobny serwis do którego apki będą strzelać i on się będzie łączył z WK.

Jak obecnie wygląda sytuacja? Trzeba złożyć wniosek o przyłączenie? Czy wystarczy, że mam konto na https://cpa.gov.pl/ ?

@Wiktor Zychla:

Próbuję podpisać XML za pomocą certyfikatu dostępnego na Twoim repo (signature.p12). Jednak dostaję błąd
SignatureDescription could not be created for the signature algorithm supplied.

public static XmlElement SignXml(XmlDocument docXml, X509Certificate2 certificate)
    {
        try
        {
            var privateKey = certificate.GetECDsaPrivateKey();

            var signedXml = new SignedXml(docXml)
            {
                SigningKey = privateKey,
                SignedInfo =
                {
                    SignatureMethod = "http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256",
                    CanonicalizationMethod = "http://www.w3.org/2001/10/xml-exc-c14n#"
                }
            };

            var reference = new Reference { Uri = string.Empty };

            var enveloped = new XmlDsigEnvelopedSignatureTransform(true);
            reference.AddTransform(enveloped);

            var transform = new XmlDsigExcC14NTransform("ds saml2 saml2p xenc");
            reference.AddTransform(transform);

            signedXml.AddReference(reference);

            var cert = certificate.Export(X509ContentType.Cert);
            
            KeyInfoClause kic = new KeyInfoX509Data(cert);

            signedXml.KeyInfo.AddClause(kic);

            signedXml.ComputeSignature();

            return signedXml.GetXml();
        }
        catch (Exception e)
        {
            return null;
        }
    }

Kod jest roboczy.

Pracuje na MacOS. Czy to może być problem?

Widziałem na SO, że linkowałeś do rozwiązań opartym na czymś takim. Jednak to działa tylko na windowsie

var cspParams = new CspParameters(24) { KeyContainerName = "XML_DSIG_RSA_KEY" };
var key = new RSACryptoServiceProvider(cspParams);
key.FromXmlString(certificate.PrivateKey.ToXmlString(true));

Ten fix dotyczy RSA a kod masz na ECDA.

ECDA nie jest obsługiwane przez biblioteczny SignedXml w ogóle, nie ma znaczenia na jakim oesie

Po to w repo biblioteki do węzła nas GitHub mam setki linii robiących podpis na eliptycznych. Tak bijąc głową w mur centralnie go nie przebijesz ;)

I trochę nie wiem po co, repo jest na GitHub, licencja jest MIT to jaki jest cel? Szkoda czasu, to naprawdę jest żmudne!

Czy certy są tylko w tym formacie dostarczane? Czy też jest jakiś wybór?

Widzę tu wiele doświadczonych osób w nierównym boju z WK i ePUAP więc proszę o sprostowanie jeśli coś źle zrozumiałem:

Chcę podpisywać dokumenty profilem zaufanym (tzw. podpis zaufany). Tylko tyle i aż tyle. W tym celu muszę się zintegrować z ePUAP i korzystać z endpointa TPSigning5. Dlatego też potrzebuję wystąpić o certyfikat (jako podmiot publiczny) i nim podpisywać moje żądania - dzięki temu system rządowy rozpozna mój system i pozwoli wywoływać swoje końcówki.

Jednak sam podpis jest składany przez pojedyncze osoby, które mają założony profil zaufany, tzn. dokument podpisuje Jan Kowalski a nie system SuperFaktury3000. Nasuwa się zatem pytanie: jak obsłużyć autoryzację poszczególnych użytkowników? Do profilu zaufanego można logować się na wiele sposobów (w tym za pomocą bankowości elektronicznej) - przecież nie mogę prosić o takie dane żeby potem je przesyłać w kopercie do wsdla TPSigning5. Czy może jest to tak zaprojektowane, że wywołanie końcówki TPSigning5 zwraca urla do panelu logowania do profilu zaufanego i dopiero po zalogowaniu się przez usera dokument zostaje podpisany? Jeżeli tak jest, to czy nie oznacza to przypadkiem, że w takim scenariuszu nie muszę w ogóle integrować się z Węzłem Krajowym? Czy może nie ma żadnych linków do panelów logowania i autoryzację obsługuje WK i dlatego muszę jednak integrować się również z nim?

Moje pytanie jest niejako streszczeniem wszystkich 14 stron tego wątku - trwa on już kilka dobrych lat, wprowadzono wiele zmian zarówno w systemie jak i ścieżce prowadzącej do uzyskania dostępu do środowisk testowych, pytano o różne części systemu (WK, ePUAP itd.) dlatego nie ukrywam, że trochę się gubię a na pomoc od rządowych instytucji nie mam co liczyć.

Pozdrawiam i życzę wszystkim szybkiego nadejścia wiosny :)

Jest troche tak jak napisales, przy wywołaniu tpsigning5 jeśli użytkownik nie jest zalogowany PZ zawoła o logowanie.
Jeśli natomiast liczysz, że podpiszesz PDFa to niestety tak to nie działa. Tpsigning umożliwi jedynie podpisanie XMLa do którego załącznikiem jest PDF.
W teorii, aby posługiwać się tpsigning musisz też oferować logowanie przez WK

@Bart Urbanczyk: U nas podpis dokumentów jest realizowane przez zewnętrznego dostawcę. Nie mamy też logowanie przez WK(jeszcze). Podpis dokumentu, a WK to są kompletnie inne mechanizmy. Mimo, że tu i tu występuje etap logowania za pomocą węzła krajowego, to nie potrzebne są certyfikaty podmiotu publicznego.
@Wiktor Zychla: Wołam Ciebie, gdyż masz największą wiedzę odnośnie tego

Przy okazji, czy przy WK muszę sprawdzać czy sesja jest jeszcze aktywna? Czy i jak mogę sprawdzić czy ktoś nie wylogował się z WK? W dokumentacji nie znalazłem na ten temat nic. Jest tylko opis jak wylogować się/zakończyć sesję. Jednak nie ma nic, gdy chcemy sprawdzić czy ktoś nie zakończył sesji z poziomu innej apki.

Michalk001 napisał(a):

@Bart Urbanczyk: U nas podpis dokumentów jest realizowane przez zewnętrznego dostawcę. Nie mamy też logowanie przez WK(jeszcze). Podpis dokumentu, a WK to są kompletnie inne mechanizmy. Mimo, że tu i tu występuje etap logowania za pomocą węzła krajowego, to nie potrzebne są certyfikaty podmiotu publicznego.
@Wiktor Zychla: Wołam Ciebie, gdyż masz największą wiedzę odnośnie tego

Przy okazji, czy przy WK muszę sprawdzać czy sesja jest jeszcze aktywna? Czy i jak mogę sprawdzić czy ktoś nie wylogował się z WK? W dokumentacji nie znalazłem na ten temat nic. Jest tylko opis jak wylogować się/zakończyć sesję. Jednak nie ma nic, gdy chcemy sprawdzić czy ktoś nie zakończył sesji z poziomu innej apki.

Rozumiem, dzielę się tym co dostałem w zeszłym roku z supportu, potwierdzałem ją jeszcze dodatkowo aby się upewnić i takie było stanowisko:

Jednakże systemy z usługami online, które wnioskują o integrację z TPS, a nie mają usługi logowania wymagamy aby zintegrowali się z WK czyli muszą dostosować systemy aby przed podpisem nastąpiła identyfikacja osoby za pomocą WK. Odstępstwem od tej reguły są jedynie systemy, które są systemami wewnętrznymi dla urzędników (np. wewnętrzny obieg dokumentów z podpisem), w tym wypadku nie wymagamy aby zapewnili u siebie identyfikację przez WK.

Czy może jest to tak zaprojektowane, że wywołanie końcówki TPSigning5 zwraca urla do panelu logowania do profilu zaufanego i dopiero po zalogowaniu się przez usera dokument zostaje podpisany?

dokładnie to tak działa

Jeżeli tak jest, to czy nie oznacza to przypadkiem, że w takim scenariuszu nie muszę w ogóle integrować się z Węzłem Krajowym?

na poziomie technicznym nie. na poziomie organizacyjnym - z jakiegoś powodu jest tak że żeby dostać certyfikat do TPSigning trzeba się najpierw wykazać integracją logowania z WK. nie da się tego wytłumaczyć na poziomie technicznym, WK i TPSigning to dwie różne usługi. prawdopodobnie chodzi o jakieś względy biznesowe, ale nie wiadomo o jakie.

Jednakże systemy z usługami online, które wnioskują o integrację z TPS, a nie mają usługi logowania wymagamy aby zintegrowali się z WK czyli muszą dostosować systemy aby przed podpisem nastąpiła identyfikacja osoby za pomocą WK.

to jest niezrozumiałe - WK w trakcie procesu podpisywania dokumentu sam proponuje interfejs logowania, w którym do wyboru są trzy sposoby poświadczenia tożsamości

• profil zaufany
• e-dowód
• podpis kwalifikowany

nie wiadomo więc po co użytkownik miałby się "przed podpisem identyfikować za pomocą WK" skoro w trakcie podpisu może wykorzystać podpis kwalifikowany, jedną z trzech możliwości, której z kolei WK nie ma na liscie dostępnych uwierzytelnień (bo ma tylko profil zaufany albo e-dowód)

Przy okazji, czy przy WK muszę sprawdzać czy sesja jest jeszcze aktywna? Czy i jak mogę sprawdzić czy ktoś nie wylogował się z WK? W dokumentacji nie znalazłem na ten temat nic. Jest tylko opis jak wylogować się/zakończyć sesję.

SAML2 nie ma takiego czegoś jak "sprawdzenie", można wymusić wylogowanie i tyle.

ja z kolei mam inną zagwozdkę z TpSigning5.
przepływ jest taki

• użytkownika się przekierowuje na adres zwrócony z TpSigning5
• (*) użytkownik wybiera profil zaufany jako metodę logowania (bo może)
• podpisuje, aplikacja dostaje dokument, wszystko jest okej

ale TpSigning5 samo z siebie nie ma możliwości "wylogowania" użytkownika. w szczególności

• gdyby chcieć "oszukać" system i wykonać tylko wylogowanie z WK, to do tego potrzeby jest identyfikator sesji WK, a w TpSigning5 nie ma jak go wydobyć (w podpisanym dokumencie jest tylko IdentityIssuer i IdentiyIssueTimeStamp a nie ma żadnego "identyfikatora sesji", z resztą, byłoby to niepokojące gdyby w podpisanym dokumencie był)

• użytkownik mógł podpisać dokument podpisem kwalifikowanym, wtedy w ogóle nie ma sesji na WK

  efekt jest taki ze użytkownik pozostaje w tle zalogowany do WK (krok *) i nawet jak się wyloguje z naszego systemu, to nie ma jak zerwać sesji na WK (bo nie wiadomo czy ona jest czy nie).

  jeden z dużych klientów zgłosił to nam jako błąd krytyczny - nie wylogowanie się ze wszystkich podsystemów podczas wylogowania z systemu. sprawa toczy się

  • support epuap nie odpowiada na maile z opisem tego problemu
  • Klient uważa że ma inne systemy, w których to działa i odsyła nas do ich dostawców, pierwszy z listy uprzejmie odpowiedział że nie korzysta z TpSigning5 więc nie pomoże

to jest niezrozumiałe - WK w trakcie procesu podpisywania dokumentu sam proponuje interfejs logowania, w którym do wyboru są trzy sposoby poświadczenia tożsamości

profil zaufany
e-dowód
podpis kwalifikowany
nie wiadomo więc po co użytkownik miałby się "przed podpisem identyfikować za pomocą WK" skoro w trakcie podpisu może wykorzystać podpis kwalifikowany, jedną z trzech możliwości, której z kolei WK nie ma na liscie dostępnych uwierzytelnień (bo ma tylko profil zaufany albo e-dowód)

Też się zgadzam że to niezrozumiałe i nie ma za bardzo sensu bo nic nie zmienia, że zalogujemy użytkownika wcześniej skoro i tak musiałby się zalogować.

ale TpSigning5 samo z siebie nie ma możliwości "wylogowania" użytkownika. w szczególności

gdyby chcieć "oszukać" system i wykonać tylko wylogowanie z WK, to do tego potrzeby jest identyfikator sesji WK, a w TpSigning5 nie ma jak go wydobyć (w podpisanym dokumencie jest tylko IdentityIssuer i IdentiyIssueTimeStamp a nie ma żadnego "identyfikatora sesji", z resztą, byłoby to niepokojące gdyby w podpisanym dokumencie był)

użytkownik mógł podpisać dokument podpisem kwalifikowanym, wtedy w ogóle nie ma sesji na WK

efekt jest taki ze użytkownik pozostaje w tle zalogowany do WK (krok *) i nawet jak się wyloguje z naszego systemu, to nie ma jak zerwać sesji na WK (bo nie wiadomo czy ona jest czy nie).

jeden z dużych klientów zgłosił to nam jako błąd krytyczny - nie wylogowanie się ze wszystkich podsystemów podczas wylogowania z systemu. sprawa toczy się

support epuap nie odpowiada na maile z opisem tego problemu
Klient uważa że ma inne systemy, w których to działa i odsyła nas do ich dostawców, pierwszy z listy uprzejmie odpowiedział że nie korzysta z TpSigning5 więc nie pomoże

tpsigning jest usługą PZ ale logowanie przechodzi przez WK i tam sesja rzeczywiście zostanie. W takiej sytuacji nie ma możliwości wylogowania bo w dokumencie nie bedzie identyfikatora sesji. Jesteś w stanie wyjaśnić jaki może mieć to wpływ na bezpieczeństwo, że użytkownik nie zostaine wylogowany z WK po podpisaniu dokumentu?

Jesteś w stanie wyjaśnić jaki może mieć to wpływ na bezpieczeństwo, że użytkownik nie zostaine wylogowany z WK po podpisaniu dokumentu?

Klient jest trudny i trudno się z nim rozmawia na takim poziomie gdzie trzeba zejść na szczegół techniczny i umieć uzasadnić co można bo się ma nad tym kontrolę a czego nie można bo się nie ma. Klient patrzy na system "holistycznie", argumentuje od strony użytkownika słusznie, ze jak kliknął "wyloguj" to chce żeby wszystkie usługi biorące udział w sesji zostały wylogowane.

na poziomie technicznym wystarczyłoby zeby metoda addDocumentToSigning miała jeszcze jeden parametr, forceAuth (trochę jak SAML ma), żeby można było tam wstawić wymuszenie ponownej autentykacji za każdym razem. albo żeby w odpowiedzi zwracali identyfikator sesji WK, można by ją wtedy zamknąć tym żądaniem które się puszcza na serwer WK żeby wylogować sesję.

Akurat case wylogowania to rykoszet, natomiast kiedyś zgłaszali inny, sensowny case. system naborowy ma pozwolić podpisać dane wniosku obu opiekunom (nie wiadomo po co, wystarczyłby jeden, ale tak ma). i jakiś inny Klient zgłaszał jako problem, że

• opiekun 1 podpisuje wniosek
• opiekun 2 jak próbuje z tej samej przeglądarki (a nie że się zalogował osobno do systemu) podpisać wniosek, to trafia w sesję tamtego pierwszego - bo dokładnie tak samo nie da się wylogować pierwszego i sesja tam wisi

Sugestia była taka żeby jak już muszą korzystać z tej samej otwartej przeglądarki, to żeby chociaż na karcie inkognito czy coś. Ale to też nie brzmi poważnie jak tego typu wskazówki trzeba dawać użytkownikom.

Dziękuję wszystkim za wyjaśnienie zawiłości WK + ePUAP. Jeszcze jedna (krytyczna) sprawa:

Bart U napisał(a):

Jeśli natomiast liczysz, że podpiszesz PDFa to niestety tak to nie działa. Tpsigning umożliwi jedynie podpisanie XMLa do którego załącznikiem jest PDF.

Chcesz powiedzieć, że nie istnieje możliwość podpisania PDFa tak jak może to zrobić każdy po zalogowaniu się na swój profil zaufany?

Jedyne co oferuje rządowe api to podpisanie xmla który wskazuje na pdfy (ale które same w sobie podpisane nie będą)?

pytajnik2023 napisał(a):

Dziękuję wszystkim za wyjaśnienie zawiłości WK + ePUAP. Jeszcze jedna (krytyczna) sprawa:

Bart U napisał(a):

Jeśli natomiast liczysz, że podpiszesz PDFa to niestety tak to nie działa. Tpsigning umożliwi jedynie podpisanie XMLa do którego załącznikiem jest PDF.

Chcesz powiedzieć, że nie istnieje możliwość podpisania PDFa tak jak może to zrobić każdy po zalogowaniu się na swój profil zaufany?

Jedyne co oferuje rządowe api to podpisanie xmla który wskazuje na pdfy (ale które same w sobie podpisane nie będą)?

Niestety tak właśnie jest:
metoda addDocumentToSigning pa pole 'doc' zgodnie ze specyfikacją :

Dokument do podpisu w formacie XML, zakodowany w Base64; Maksymalna dopuszczalna wielkość dokumentu to 5 MB.

Podpisywaczka rządowa to extra osobna aplikacja która po prostu może więcej niż to API które jest wystawione.