From f8bb5fa2b930d258d5c92733088bc1332159066a Mon Sep 17 00:00:00 2001 From: Klaus Stranacher Date: Mon, 26 May 2014 14:47:12 +0200 Subject: Update MOA-ID handbook (Typos, etc.) --- id/server/doc/handbook/protocol/protocol.html | 132 +++++++++++++------------- 1 file changed, 66 insertions(+), 66 deletions(-) (limited to 'id/server/doc/handbook/protocol') diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index 03a31a2bf..4e02a559c 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -219,7 +219,7 @@ Redirect Binding

/saml:Assertion/saml:AttributeStatement/

saml:Subject/saml:SubjectConfirmation/

saml:SubjectConfirmationData

- Base64 kodierte Signatur die während des Authentifizierungsdaten vom Benutzer erzeugt wurde. + Base64 kodierte Signatur die während des Authentifizierungsvorgangs vom Benutzer erzeugt wurde. urn:oid:1.2.40.0.10.2.1.1.261.66 @@ -273,7 +273,7 @@ Redirect Binding MANDATOR-NATURAL-PERSON-SOURCE-PIN mandate <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> - Stammzahl der natürlichen Person, für die Vollmachts- bzw. Vertretungsbe-fugnisse ausgeübt werden. + Stammzahl der natürlichen Person, für die Vollmachts- bzw. Vertretungsbefugnisse ausgeübt werden. urn:oid:1.2.40.0.10.2.1.1.261.76 @@ -322,7 +322,7 @@ Redirect Binding MANDATOR-LEGAL-PERSON-FULL-NAME mandate <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> - Name der juristischen Person bzw. Personenmehrheit gemäß zugrundelie-gendem Register. + Name der juristischen Person bzw. Personenmehrheit gemäß zugrundeliegendem Register. urn:oid:1.2.40.0.10.2.1.1.261.86 @@ -501,10 +501,10 @@ Redirect Binding

1.3 Übersicht der möglichen MOA-ID spezifischen Statuscodes

-

Vom Modul MOA-ID-Auth werden verschiedene Authentifizierungsprotololle wobei diese Protokolle die Fehlerrückgabe unterschiedlich spezifizieren. Zusätzlich zu den protokolabhängigen Statuscodes (siehe Spezifikation des jeweiligen Protokolls) werden zusätzliche protokollunabhängige Statuscodes an den Service Provider zurückgeliefert, wobei sich das Format der Fehlerrückgabe jedoch weiterhin protokolspezifisch ist.

+

Vom Modul MOA-ID-Auth werden verschiedene Authentifizierungsprotokolle wobei diese Protokolle die Fehlerrückgabe unterschiedlich spezifizieren. Zusätzlich zu den protokollabhängigen Statuscodes (siehe Spezifikation des jeweiligen Protokolls) werden zusätzliche protokollunabhängige Statuscodes an den Service Provider zurückgeliefert, wobei sich das Format der Fehlerrückgabe jedoch weiterhin protokollspezifisch ist.

Die nachfolgende Tabelle zeigt alle protokollunabhängigen Statuscodes welche vom Modul MOA-ID-Auth zurückgeliefert werden können.

1.3.1 Statuscodes 1xxxx

-

Alle Statuscodes beginnent mit der Zahl eins beschreiben Fehler welche während des Identifizerungs- und Authentifizierungsvorgangs aufgetreten sind.

+

Alle Statuscodes beginnend mit der Zahl eins beschreiben Fehler welche während des Identifizierungs- und Authentifizierungsvorgangs aufgetreten sind.

1.3.1.1 Authentifizierung (10xxx)

@@ -572,7 +572,7 @@ Redirect Binding - + @@ -588,7 +588,7 @@ Redirect Binding - +
1105Zertifikat der Signature ungültigZertifikat der Signatur ungültig
1106
1109Fehler beim validieren der SZR-Gateway ResponseFehler beim Validieren der SZR-Gateway Response

1.3.1.3 STORK (12xxx)

@@ -599,11 +599,11 @@ Redirect Binding 1200 - Fehler beim erstellen des STORK Authentifizierungsrequests + Fehler beim Erstellen des STORK Authentifizierungsrequests 1201 - Fehler beim validieren der STORK Authentifizierungsresponse + Fehler beim Validieren der STORK Authentifizierungsresponse 1202 @@ -615,9 +615,9 @@ Redirect Binding

1.3.2 Statuscodes 4xxxx

-

Alles Statuscodes beginnent mit der Zahl vier beschreiben Fehler die während der Kommunikation mit externen Services aufgetreten sind.

+

Alles Statuscodes beginnend mit der Zahl vier beschreiben Fehler die während der Kommunikation mit externen Services aufgetreten sind.

1.3.2.1 BKU (40xxxx)

-

Tritt während des Anmeldevorgangs in der Bürgerkartenumgebung ein Fehler auf so wird der entsprechende Fehlercode an den Service Provider weitergereicht. Der der durch das Modul MOA-ID-Auth weitergereichte Statuscode für Bürgerkartenumgebungsfehler weißt das folgende zweiteilige Format auf. Der erste Teil, bestehend aus zwei Dezimalstellen, kennzeichnet den Fehler als Fehler als Bürgerkartenumgebungsfehler. Der zweite Teil, bestehend aus vier Dezimalstellen bezeichnet den eindeutigen Identifikator des Fehers aus der Bürgerkartenumgebung (siehe SecurityLayer Spezifikation).

+

Tritt während des Anmeldevorgangs in der Bürgerkartenumgebung ein Fehler auf so wird der entsprechende Fehlercode an den Service Provider weitergereicht. Der der durch das Modul MOA-ID-Auth weitergereichte Statuscode für Bürgerkartenumgebungsfehler weißt das folgende zweiteilige Format auf. Der erste Teil, bestehend aus zwei Dezimalstellen, kennzeichnet den Fehler als Fehler als Bürgerkartenumgebungsfehler. Der zweite Teil, bestehend aus vier Dezimalstellen bezeichnet den eindeutigen Identifikator des Fehlers aus der Bürgerkartenumgebung (siehe SecurityLayer Spezifikation).

{40}{xxxxx}

{40} ... MOA-ID Statuscode für Fehler aus der Bürgerkartenumgebung

@@ -630,7 +630,7 @@ Redirect Binding

{411} ... MOA-ID Statuscode für Fehler aus dem Online-Vollmachten Service.

{xxx} .... Fehlercode des Online-Vollmachten Service.

-

Zusätzlich zu den gemappeden Fehlern aus dem Online-Vollmachen Service werden zusätzliche weitere Fehlercodes definiert.

+

Zusätzlich zu den gemappten Fehlern aus dem Online-Vollmachen Service werden zusätzliche weitere Fehlercodes definiert.

@@ -679,11 +679,11 @@ Redirect Binding - +
Statuscode
4400Fehler beim generieren der AnmeldedatenFehler beim Generieren der Anmeldedaten

1.3.3 Statuscodes 6xxxx

-

Alles Statuscodes beginnent mit der Zahl sechs beschreiben protokolspezifische Fehler die nicht durch das jeweilige Authentifizierungsprotokoll abgebildet werden.

+

Alles Statuscodes beginnend mit der Zahl sechs beschreiben protokollspezifische Fehler die nicht durch das jeweilige Authentifizierungsprotokoll abgebildet werden.

1.3.3.1 Allgemein (61xxx)

@@ -692,11 +692,11 @@ Redirect Binding - + - +
6000Das Authentifizierungsprotokoll wurde nicht erkannt oder wird nicht unterstüztDas Authentifizierungsprotokoll wurde nicht erkannt oder wird nicht unterstützt
6001Der STORK Request wurde nicht erkannt oder wird nicht unterstüztDer STORK Request wurde nicht erkannt oder wird nicht unterstützt

1.3.3.2 PVP 2.1 (61xxx)

@@ -707,11 +707,11 @@ Redirect Binding 6100 - Fehler beim erstellen der PVP 2.1 Response + Fehler beim Erstellen der PVP 2.1 Response 6101 - Fehler beim verschlüsseln der PVP 2.1 Assertion + Fehler beim Verschlüsseln der PVP 2.1 Assertion 6102 @@ -719,7 +719,7 @@ Redirect Binding 6103 - Für die im Requst angegebene EnityID konnten keine gültigen Metadaten gefunden werden + Für die im Reqeust angegebene EntityID konnten keine gültigen Metadaten gefunden werden 6104 @@ -753,7 +753,7 @@ Redirect Binding

1.3.4 Statuscodes 9xxxx

-

Alles Statuscodes beginnent mit der Zahl neun beschreiben interne Serverfehler.

+

Alles Statuscodes beginnend mit der Zahl neun beschreiben interne Serverfehler.

1.3.4.1 Konfigurationsfehler (90xxx)

@@ -801,7 +801,7 @@ Redirect Binding - + @@ -822,36 +822,36 @@ Redirect Binding
9100Fehler beim einlesen einer externen Resource.Fehler beim Einlesen einer externen Ressource.
9101

 

1.4 Single Sign-On

-

Das Modul MOA-ID-Auth unterstützt ab der Version 2.0 Single Sign-On (SSO), wobei diese Funktionalität unabhängig vom verwendeten Protokoll ist. Bei Verwendung von SSO muss sich der Benutzer nur ein Mal bei MOA-ID-Auth authentifizieren und danach steht die authentifizierte Session für die BenutzerIn oder den Benutzer für weitere Anmeldevorgänge ohne weitere Authentifizierung mittels Bürgerkarte, Handy-Signatur oder STORK zur Verfügung. Die SSO Session kann danach durch die BenutzerIn oder den Benutzer beendet werden, oder sie wird von MOA-ID-Auth nach der maximal erlaubten Sessionzeit serverseitig beendet.

+

Das Modul MOA-ID-Auth unterstützt ab der Version 2.0 Single Sign-On (SSO), wobei diese Funktionalität unabhängig vom verwendeten Protokoll ist. Bei Verwendung von SSO muss sich der Benutzer nur ein Mal bei MOA-ID-Auth authentifizieren und danach steht die authentifizierte Session für die Benutzerin oder den Benutzer für weitere Anmeldevorgänge ohne weitere Authentifizierung mittels Bürgerkarte, Handy-Signatur oder STORK zur Verfügung. Die SSO Session kann danach durch die Benutzerin oder den Benutzer beendet werden, oder sie wird von MOA-ID-Auth nach der maximal erlaubten Sessionzeit serverseitig beendet.

Das nachfolgende Sequenzdiagramm zeigt eine Anmeldung mittels Single Sign-On an zwei Online-Applikationen unter Verwendung von PVP 2.1. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung, die Vollmachten-Auswahl oder den Metadatenaustausch betreffen bewusst nicht berücksichtigt.

Sequenzdiagramm einer Anmeldung mittels Single Sign-On

    -
  1. Die BenutzerIn oder der Benutzer verbindet sich zu einem Web-Portal (Service Provider 1) über das die Online-Applikation 1 erreichbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang ausgelöst.
    2. +
  2. Die Benutzerin oder der Benutzer verbindet sich zu einem Web-Portal (Service Provider 1) über das die Online-Applikation 1 erreichbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang ausgelöst.
  3. Der Service Provider 1 generiert einen Authentifizierungsrequest und sendet diesen über den Browser an das Modul MOA-ID-Auth.
    4. -
  4. MOA-ID-Auth leitet die BenutzerIn oder den Benutzer zur Bürgerkartenauswahl. +
  5. MOA-ID-Auth leitet die Benutzerin oder den Benutzer zur Bürgerkartenauswahl.
      -
    1. Die BenutzerIn oder der Benutzer Authentifiziert sich mit der gewählten Methode.
      2. +
    2. Die Benutzerin oder der Benutzer Authentifiziert sich mit der gewählten Methode.
    6. -
  6. War die Authentifizierung der BenutzerIn oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers für die Online-Applikation 1.
    7. +
  7. War die Authentifizierung der Benutzerin oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers für die Online-Applikation 1.
  8. MOA-ID-Auth senden die Assertion und ein SSO Token an den Browser des Benutzers, wobei das SSO Token (http Cookie) im Browser des Benutzers gespeichert wird.
  9. Die Assertion (ohne SSO Token!) wird an den Service Provider 1 weitergeleitet.
    10. -
  10. Ist die Validierung der Assertion erfolgreich wird die BenutzerIn oder der Benutzer an der Online-Applikation 1 angemeldet.
    11. -
  11. Die BenutzerIn oder der Benutzer verbindet sich zu einem weiteren Web-Portal (Service Provider 2) über das die Online-Applikation 2 erreichbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang für die Online-Applikation 2 ausgelöst.
    12. +
  12. Ist die Validierung der Assertion erfolgreich wird die Benutzerin oder der Benutzer an der Online-Applikation 1 angemeldet.
    13. +
  13. Die Benutzerin oder der Benutzer verbindet sich zu einem weiteren Web-Portal (Service Provider 2) über das die Online-Applikation 2 erreichbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang für die Online-Applikation 2 ausgelöst.
  14. Der Service Provider 2 generiert einen Authentifizierungsrequest und sendet diesen über den Browser.
  15. Der Browser sendet den Authentifizierungsrequest und das gespeicherte SSO Token an das Modul MOA-ID-Auth.
    16. -
  16. MOA-ID-Auth validiert das SSO Token. Hierbei wird geprüft ob das Token zu einer aktiven SSO Session gehört und ob das Token bereits verwendet wurde. Jedes vergebene SSO Token ist nur für einen weiteren Anmeldevorgang gültig und wird anschließend durch ein neues ersetzt. Ist das Token abgelaufen oder wurde es bereits verwendet wird die korrespondierende SSO Session beendet und die BenutzerIn oder der Benutzer müssen sich erneut Authentifizieren.
    17. -
  17. Bei einem gültigen SSO Token antwortet MOA-ID-Auth mit einem Abfrage zum SSO Anmeldevorgang, welche der BenutzerIn oder dem Benutzer im Browser dargestellt wird. Diese Abfrage beinhaltet den Namen der Online-Applikation 2 und eine einfache JA / NEIN Abfrage ob die Anmeldung mittels SSO an der Online-Applikation 2 fortgesetzt werden soll.
    +
  18. MOA-ID-Auth validiert das SSO Token. Hierbei wird geprüft ob das Token zu einer aktiven SSO Session gehört und ob das Token bereits verwendet wurde. Jedes vergebene SSO Token ist nur für einen weiteren Anmeldevorgang gültig und wird anschließend durch ein neues ersetzt. Ist das Token abgelaufen oder wurde es bereits verwendet wird die korrespondierende SSO Session beendet und die Benutzerin oder der Benutzer müssen sich erneut Authentifizieren.
    19. +
  19. Bei einem gültigen SSO Token antwortet MOA-ID-Auth mit einem Abfrage zum SSO Anmeldevorgang, welche der Benutzerin oder dem Benutzer im Browser dargestellt wird. Diese Abfrage beinhaltet den Namen der Online-Applikation 2 und eine einfache JA / NEIN Abfrage ob die Anmeldung mittels SSO an der Online-Applikation 2 fortgesetzt werden soll.
    Hinweis: Diese Abfrage kann jedoch für Online-Applikationen deaktiviert werden. Näheres hierzu finden Sie hier.
    20. -
  20. Die Antwort der BenutzerIn oder dem Benutzer wird an MOA-ID-Auth übermittelt. Antwort die BenutzerIn oder der Benutzer mit NEIN wird der Anmeldevorgang abgebrochen.
    21. +
  21. Die Antwort der Benutzerin oder dem Benutzer wird an MOA-ID-Auth übermittelt. Antwort die Benutzerin oder der Benutzer mit NEIN wird der Anmeldevorgang abgebrochen.
  22. Soll der Anmeldevorgang vorgesetzt werden generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers für die Online-Applikation 2.
  23. MOA-ID-Auth senden die Assertion und ein neues SSO Token an den Browser des Benutzers, wobei das SSO Token (http Cookie) im Browser des Benutzers gespeichert wird.
  24. Die Assertion (ohne SSO Token!) wird an den Service Provider 2 weitergeleitet.
    25. -
  25. Ist die Validierung der Assertion erfolgreich wird die BenutzerIn oder der Benutzer an der Online-Applikation 2 angemeldet
    26. +
  26. Ist die Validierung der Assertion erfolgreich wird die Benutzerin oder der Benutzer an der Online-Applikation 2 angemeldet

Zusätzliche Informationen zur Konfiguration und die sich daraus ergebenden Anforderungen oder Einschränkungen finden sie hier.

1.5 SSO Logout

-

Das Modul MOA-ID-Auth stellt ein einfaches Service zur Beendigung einer bestehenden Single Sign-On Session zur Verfügung. Nach dem Aufruf dieses Service aus dem Browser des Users wird eine bestehende SSO Session beendet und anschließend wird die BenutzerIn oder der Benutzer an eine im LogOut Request angegebene URL weitergeleitet.

+

Das Modul MOA-ID-Auth stellt ein einfaches Service zur Beendigung einer bestehenden Single Sign-On Session zur Verfügung. Nach dem Aufruf dieses Service aus dem Browser des Users wird eine bestehende SSO Session beendet und anschließend wird die Benutzerin oder der Benutzer an eine im LogOut Request angegebene URL weitergeleitet.

Das SSO Logout Service steht unter folgender URL zur Verfügung und benötigt einen http GET Parameter:

http://<host>:<port>/moa-id-auth/LogOut
@@ -870,11 +870,11 @@ https://<host>:<port>/moa-id-auth/LogOut https://demo.egiz.gv.at/demoportal-openID_demo

Nach Beendigung des Logout Vorgangs erfolgt ein Redirect auf die in diesem Parameter angegebene URL. Wird kein Parameter angegeben wird der Benutzer an die MOA-ID-Auth Instanz weitergeleitet.

- Hinweis:Wird eine URL angeben muss diese als Prefix identisch mit dem eindeutigen Identifier der jeweiligen Online-Applikation sein,

+ Hinweis: Wird eine URL angeben muss diese als Prefix identisch mit dem eindeutigen Identifier der jeweiligen Online-Applikation sein,

 

-

Nachstehend ein Beispiel zur Verwendung dieses Services:s

+

Nachstehend ein Beispiel zur Verwendung dieses Services:

https://demo.egiz.gv.at/moa-id-auth/LogOut?redirect=https://demo.egiz.gv.at/demoportal-openID_demo

Hinweis: Dieses Service bietet jedoch NICHT eine vollständige Single Log-Out Funktionalität wie sie im SAML 2 Protokoll vorgesehen ist, sondern beendet ausschließlich die SSO Session in der MOA-ID-Auth Instanz.

@@ -890,13 +890,13 @@ https://<host>:<port>/moa-id-auth/LogOut bkuURI=<bku-url> https://127.0.0.1:3496/https-security-layer-request -

URL auf die Bürgerkartenumgebung, welche für die Authentifizierung der BenutzerIn oder des Benutzers verwendet werden soll. Für den Anmeldevorgang sind jedoch nur jene URLs auf Bürgerkartenumgebungen erlaubt die auch in der online-applikationsspezifischen Konfiguration als zu verwendente BKUs eingetragen sind.

+

URL auf die Bürgerkartenumgebung, welche für die Authentifizierung der Benutzerin oder des Benutzers verwendet werden soll. Für den Anmeldevorgang sind jedoch nur jene URLs auf Bürgerkartenumgebungen erlaubt die auch in der online-applikationsspezifischen Konfiguration als zu verwendende BKUs eingetragen sind.

Hinweis: Wird dieser Parameter nicht übertragen, antwortet das Modul MOA-ID-Auth mit einem bei MOA-ID-Auth hinterlegten Bürgerkartentemplate.

Template=<template-url> https://demo.egiz.gv.at/moa-id-auth/template_onlineBKU.html - Optional: URL auf die HTML Vorlage für den Security-Layer Request, welcher für die Kommunikation mit der Bürgerkartenumgebumg verwendet wird. Die URL muss in der online-applikationsspezifischen Konfiguration von MOA-ID-Auth hinterlegt werden (siehe Parameter SecurityLayerTemplates).
+ Optional: URL auf die HTML Vorlage für den Security-Layer Request, welcher für die Kommunikation mit der Bürgerkartenumgebung verwendet wird. Die URL muss in der online-applikationsspezifischen Konfiguration von MOA-ID-Auth hinterlegt werden (siehe Parameter SecurityLayerTemplates).
Ist dieser Parameter nicht vorhanden, verwendet MOA-ID-Auth das für diese Online-Applikation hinterlegten Security-Layer Template (siehe Parameter SecurityLayerTemplates). @@ -907,7 +907,7 @@ https://<host>:<port>/moa-id-auth/LogOut CCC=<ccc> BE, SI, - Optional: Gibt an ob die Anmeldung mittels STORK im angegebenen Land erfolgen soll. Die Angabe erfolgt mit dem Ländercode (Bsp: PT, LU, ES, ...) des jeweiligen Landes. + Optional: Gibt an ob die Anmeldung mittels STORK im angegebenen Land erfolgen soll. Die Angabe erfolgt mit dem Ländercode (z.B.: PT, LU, ES, ...) des jeweiligen Landes. @@ -926,16 +926,16 @@ https://<host>:<port>/moa-id-auth/LogOut
  • Der Service Provider extrahiert Informationen aus den Metadaten und generiert einen Authentifizierungsrequest und sendet diesen über den Browser an das Modul MOA-ID-Auth.
  • MOA-ID Auth holt die Metadaten des Service Providers und validiert die Signatur der Metadaten mit dem in der MOA-ID-Auth Konfiguration für diesen Service Provider (Online-Applikation) hinterlegten Zertifikat. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
  • MOA-ID-Auth validiert den Authentifizierungsrequest mit den Informationen aus dem Metadaten des Service Providers. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
    • -
  • MOA-ID-Auth leitet die BenutzerIn oder den Benutzer zur Bürgerkartenauswahl. +
  • MOA-ID-Auth leitet die Benutzerin oder den Benutzer zur Bürgerkartenauswahl.
      -
    1. Die BenutzerIn oder der Benutzer Authentifiziert sich mit der gewählten Methode.
      2. +
    2. Die Benutzerin oder der Benutzer Authentifiziert sich mit der gewählten Methode.
    • -
  • War die Authentifizierung der BenutzerIn oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers.
    • +
  • War die Authentifizierung der Benutzerin oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers.
  • MOA-ID-Auth senden die Assertion über den Browser an den Service Provider.
  • Der Service Provider validiert die Assertion mit den Informationen aus den Metadaten des Modules MOA-ID-Auth.
      -
    1. Ist die Validierung erfolgreich wird die BenutzerIn oder der Benutzer an der Online-Applikation angemeldet.
      2. +
    2. Ist die Validierung erfolgreich wird die Benutzerin oder der Benutzer an der Online-Applikation angemeldet.
    • @@ -974,7 +974,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata

    Der Authentifizierungsrequest wird vom Service Provider erstellt und an das Modul MOA-ID-Auth übermittelt. Zur Übertragung, muss je nach verwendetem Binding, einer der beiden Zugangspunkte und die entsprechende Kodierung der Parameter verwendet werden.

    Folgende Minimalanforderungen an den Authentifizierungsrequest müssen erfüllt sein.