Signatur

Prozessfluss für die Erstellung einer qualifizierten Signatur (App mit Backend)

Dieser Anwendungsfall beschreibt den Prozessfluss für die Signaturerstellung für eine Service Provider App mit Backend, wie in Abbildung 1 dargestellt. Der Prozess wird mit einem initialen Request an den Identity Provider (IdP) aus der App gestartet.

Abbildung 1: Beispiel Verwendung SL2.0 mit Redirect
  1. Der IdP schickt ein signiertes Security Layer Kommando zur Erstellung einer CADES Signatur an den VDA:
    {"v":"10","reqID":"79728758-5d1a-4235-a5b1-ea7192a27e21","signedPayload":"eyJhbGciOiJSUz…. "}
    signedPayload = {"alg":"RS256","cty":"application/sl2.0;command","x5c":"MIIC9zCCAd8CB….}{"name":"qualifiedeID","params":{"authBlockTemplateID":"authblock_DE","dataUrl":"http://localhost:8080/idp/dataurl","attributes":[{"SP-FRIENDLYNAME":"http://localhost:8080/idp"},{"MANDATE-REFERENCE-VALUE":"da421273-c830-4a3d-a527-324046686d49"}]}}{xxxxxxxx}
  2. Der VDA Antwortet mit einem Redirect-Kommando, das den Benutzer zur Authentifizierung zum VDA weiterleitet:
    {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_12113241243124nnn123n4234"}]}},"url":"APICALL://call.vda.in.app","IPCRedirect":true}},"url":"http://localhost:8080/vda/generic/redirect","IPCRedirect":true}}}
  3. Danach folgt eine Auswertung des Redirect Kommandos und Response je nach Client-Typ:
    • Native Client = http Code 200 + Kommando für native Clients:
      {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_12113241243124nnn123n4234"}]}},"url":"APICALL://call.vda.in.app","IPCRedirect":true}}}
    • Kein nativer Client = http Code 307 + Kommando:
      http://localhost:9080/vda/generic/redirect?slcommand= %7B%22v%22%3A%2210%22%2C%22reqID%22%3A%223d6a5260-270b-4a9e-bb83-d491110e35a0%22%2C%22transactionID%22%3A%2210e574bd-a525-4952-9972-26b12b4c0ff5%22%2C%22payload%22%3A%7B%22name%22%3A%22redirect%22%2C%22params%22%3A%7B%22command%22%3A%7B%22name%22%3A%22call%22%2C%22params%22%3A%7B%22url%22%3A%22http%3A%2F%2Flocalhost%3A8080%2Fvda%2Fauth%2Finitial%22%2C%22method%22%3A%22get%22%2C%22includeTransactionID%22%3Atrue%2C%22reqParams%22%3A%5B%7B%22pendingId%22%3A%22testId_vda_12113241243124nnn123n4234%22%7D%5D%7D%7D%2C%22url%22%3A%22APICALL%3A%2F%2Fcall.vda.in.app%22%2C%22IPCRedirect%22%3Atrue%7D%7D%7D

      Kommando unverschlüsselt:

      {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_12113241243124nnn123n4234"}]}},"url":"APICALL://call.vda.in.app","IPCRedirect":true}}}
  4. Die Service Provider App wertet das Redirect Kommando aus und ruft die VDA App per Interprozesskommunikation inklusive Rückruf-URL Parameter (slIPCReturnUrl = APICALL://call.sp.in.app) auf:
    {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_12113241243124nnn123n4234"}]}}}
  5. Die VDA App wertet das erhaltene Kommando weiter aus und sendet einen Call an die angegebene Adresse:
    http://localhost:8080/vda/auth/initial?pendingId=testId_vda_12113241243124nnn123n4234&slTransactionID=10e574bd-a525-4952-9972-26b12b4c0ff5
  6. In diesem Schritt wird die Authentifizierung mit dem Benutzer durchgeführt. Hier sind beliebig viele Zwischenschritte möglich.
  7. Der VDA antwortet dem IdP:
    {"v":"10","respID":"f3902aaf-f029-4e41-80b3-e6576ef60db6","inResponseTo":"79728758-5d1a-4235-a5b1-ea7192a27e21","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","signedPayload":"eyJhbGciOiJSUzI1Ni….."}
    signedPayload = {"alg":"RS256","cty":"application/sl2.0;command","x5c":"MIIC9zCCAd8CBFr....."}{"name":"CADES","encryptedResult":"eyJhbGciOiJ…."}{xxxxxxxx}
    encryptedResult = {"alg":"RSA-OAEP","enc":"A128CBC-HS256","cty":"application/sl2.0;result","x5t#S256":"IwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJvN3l1pjzlnmoW"}{…..}
  8. Der IdP antwortet dem VDA mit folgendem Kommando:
    {"v":"10","reqID":"82298f55-f793-432c-83f1-755799b8e193","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/idp/resumeAuth","method":"get","includeTransactionID":false,"reqParams":[{"pendingId":"testId_idp_13324432242134nn123n4234"}]}},"url":"APICALL://call.sp.in.app","IPCRedirect":true}},"url":"http://localhost:8080/idp/resumeAuth","IPCRedirect":true}}}
  9. Abschließend wird ein Redirect übermittelt, der den Benutzer zurück zum IdP leitet:
    • VDA an VDA App:
      {"v":"10","reqID":"82298f55-f793-432c-83f1-755799b8e193","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/idp/resumeAuth","method":"get","includeTransactionID":false,"reqParams":[{"pendingId":"testId_idp_13324432242134nn123n4234"}]}},"url":"APICALL://call.sp.in.app","IPCRedirect":true}}}
    • VDA App an Service Provider App:
      {"v":"10","reqID":"82298f55-f793-432c-83f1-755799b8e193","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"call","params":{"url":"http://localhost:8080/idp/resumeAuth","method":"get","includeTransactionID":false,"reqParams":[{"pendingId":"testId_idp_13324432242134nn123n4234"}]}}
    • Die Service Provider App sendet einen Call an den IdP an folgende Adresse:
      http://localhost:8080/idp/resumeAuth?pendingId=testId_idp_13324432242134nn123n4234

Prozessfluss für die Erstellung einer qualifizierten Signatur (Standalone App)

Dieser Anwendungsfall beschreibt den Prozessfluss für die Signaturerstellung für eine Standalone- Service Provider App ohne Backend, wie in Abbildung 2 dargestellt.

Abbildung 2: Routing bei Standalone App
  1. Die Service Provider App sendet folgendes Kommando an den VDA:
    {"v":"10","reqID":"79728758-5d1a-4235-a5b1-ea7192a27e21","payload":{name=createCAdES, params={"keyId":"21242jkj", "content":" JVBERi0xLjUNJeLjz9MN…", "mimeType":"application/xhtml+xml","padesCompatibility": "false", "excludedByteRange":[[20,50], [100,150]], "cAdESlevel":"cAdES"}}}
  2. Der VDA antwortet mit einem Redirect-Kommando, das den Benutzer zur Authentifizierung zum VDA weiterleitet:
    {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_12113241243124nnn123n4234"}]}},"url":"APICALL://call.vda.in.app","IPCRedirect":true}},"url":"http://localhost:8080/vda/generic/redirect","IPCRedirect":true}}}
  3. Danach folgt eine Auswertung des Redirect Kommandos und der Aufruf der VDA App inklusive Rückruf-URL Parameter (slIPCReturnUrl = APICALL://call.sp.in.app):
    {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_12113241243124nnn123n4234"}]}}}
  4. Die VDA App wertet das erhaltene Kommando weiter aus und sendet einen Call an die angegebene Adresse:
    http://localhost:8080/vda/auth/initial?pendingId=testId_vda_12113241243124nnn123n4234&slTransactionID=10e574bd-a525-4952-9972-26b12b4c0ff5
  5. In diesem Schritt wird die Authentifizierung mit dem Benutzer durchgeführt. Hier sind beliebig viele Zwischenschritte möglich.
  6. Der VDA antwortet der VDA App mit folgendem Kommando:
    {"v":"10","reqID":"82298f55-f793-432c-83f1-755799b8e193","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5", "inResponseTo":"79728758-5d1a-4235-a5b1-ea7192a27e21" ,"payload":{"name":"redirect","params":
    {"command":{name=createCAdES, result={"signature":" MIICQjCCAa2gAwIBAgIBAjALBgkqhkiG9w0BAQQwaDEWMBQGA1UEAxMNR2Vyb2…"}}
    ,"url":"APICALL://call.sp.in.app","IPCRedirect":true}}}
    
  7. Die VDA App wertet das Kommando aus und ruft die Service Provider App auf:
    {"v":"10","respID":"82298f55-f793-432c-83f1-755799b8e193","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5", "inResponseTo":"79728758-5d1a-4235-a5b1-ea7192a27e21", "payload":{name=createCAdES, result={"signature":" MIICQjCCAa2gAwIBAgIBAjALBgkqhkiG9w0BAQQwaDEWMBQGA1UEAxMNR2Vyb2…"}}}

Prozessfluss für die Erstellung einer qualifizierten Signatur (Android)

Dieser Prozessfluss repräsentiert einen weiteren möglichen Anwendungsfalls zur Erstellung einer qualifizierten Signatur. Der Prozess wird anhand eines Beispiel-Anwendung mit PDF-AS beschrieben und ist in Abbildung 3 dargestellt.

Abbildung 3: Prozessfluss zur Erstellung einer qualifizierten Signatur (PDF)
  1. Die Service Provider (SP) App sendet einen PDF-AS Signatur Request zu einem Beispiel-Service mit der Adresse:
    https://demo.egiz.gv.at/babypointSPDemo/services/submitRegistrationCard
  2. Die Applikation des Service Providers erzeugt ein zu signierendes PDF und schickt dieses an PDF-AS, um es mit einer qualifizierten Signatur zu versehen. PDF-AS startet den Signaturvorgang mit dem VDA, der mit einer Weiterleitung (Security Layer 2.0 Kommando) zur Identifikation und Authentifizierung des Benutzers am VDA antwortet. Diese Weiterleitung wird über die Applikation des Service Providers an die Service App weitergereicht.

    Beispiel für Security Layer 2.0 Kommando für die Umleitung des Benutzers zum VDA zur Authentifizierung:

    {"v":"10","reqID":"3d6a5260-270b-4a9e-bb83-d491110e35a0","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5", "payload":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"http://localhost:8080/vda/auth/initial","method":"get","includeTransactionID":true,"reqParams":[{"pendingId":"testId_vda_121132412..."}]}},"url":"APICALL://call.vda.in.app","IPCRedirect":true}}}
    

    Die Service App empfängt den Response und übergibt ihn an das E-ID Client Plugin. Der http Response des Service enthält das Security Layer (SL) 2.0 Kommando, welches alle Informationen für eine Weiterleitung an das VDA Plugin beinhaltet. Dieses Kommando ist wie folgt aufgebaut:

    {"v":10,"reqID":"n5z1IMRSRi7m3PpxvDxk","payload":{"name":"redirect","params":{"url":"vdaapp://vda.app","command":{"name":"call","params":{"url":"https://www.handy-signatur.at/Securitylayer2/",
    "method":"get","includeTransactionID":false,"reqParams":[{"commandtoken":"SL2CT-DOSUGK..."}]}},"IPCRedirect":true}}
    
  3. Das E-ID Service erkennt, dass es sich um SL 2.0 Kommando handelt und wertet dieses aus. Anschließend wird das SL-Kommando und die Rückruf-URL der Service App per Interprozesskommunikation (IPC) an die E-ID App weitergeleitet.
  4. Die E-ID App empfängt den IPC-Call direkt über das E-ID Service, das Requests mit dem Scheme "at.gv.oe.app" empfängt:
    
    

    Der E-ID Service empfängt den Intent und extrahiert das SL 2.0 Kommando, bzw. den JSON Container. Anhand des Kommandos selektiert das E-ID Service das zuständige Plugin und reicht das Kommando an das VDA Plugin weiter.

  5. Das VDA Plugin übergibt das Security Layer 2.0 Kommando an die VDA-Komponente, die das Kommando auflöst und den Identifikations- und Authentifizierungsvorgang des Benutzers mit dem VDA startet. Hierfür wird das Signaturpasswort und der Fingerabdruck des Benutzer gefordert. Nach erfolgreicher Validierung wird die Signatur generiert und anschließend an PDF-AS ausgeliefert. Danach wird der Benutzer via Security Layer 2.0 Authentication-Response Redirect Kommando an PDF-AS zurückgeleitet.
  6. Beispiel für ein Security Layer 2.0 Authentication-Response Redirect Kommando:

    {"v":"10","reqID":"4iFEqvsk0O3rMD7vkWEB","transactionID":"10e574bd-a525-4952-9972-26b12b4c0ff5","payload":{"name":"redirect","params":{"command":{"name":"call","params":{"url":"https://demo.egiz.gv.at/demoportal-pdf_as/ProvidePDF;jsessionid=85BDBE54134E7505C8B767A4A4E2159D","method":"get","includeTransactionID":false,"reqParams":[{"pendingId":"testId_idp_13324432242134nn123n4234"}]}},"url":"APICALL://call.sp.in.app","IPCRedirect":true}}}
    
  7. Das VDA-Plugin leitet den SL 2.0 Redirect an das E-ID Service in der E-ID App weiter.
  8. Danach wird der SL 2.0 Redirect vom E-ID Service aufgelöst und die Response per IPC an die Service Provider App weiterleitet. Die Rückgabe-URL zur Service App wurde initial als "returnUrl" mitgegeben. In diesem Beispiel wird das Scheme mit "serviceapp" festgelegt. Diese Scheme wird von der jeweiligen Sevice Provider App angegeben. Im dargestellten Beispiel wird der nachfolgende Intent-Filter implementiert:
        
    
  9. Die Service App empfängt die SL 2.0 Response und löst das erhaltene SL 2.0 Kommando auf. Die SL 2.0 Response enthält eine URL, über welche das signierte PDF abgeholt werden kann.
    Beispiel für eine SL 2.0 Response:

    {"v":10,"reqID":"4iFEqvsk0O3rMD7vkWEB","payload":{"name":"call","params":{"url":"https://demo.egiz.gv.at/demoportal-pdf_as/ProvidePDF;jsessionid=85BDBE54134E7505C8B767A4A4E2159D","method":"get","includeTransactionID":false}}}