From 409dfe5bb2ed9eff18d16e384497caf073fac866 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Fri, 16 May 2014 12:48:16 +0200 Subject: update default config and handbook --- id/server/doc/handbook/config/config.html | 12 +- id/server/doc/handbook/index.html | 4 +- .../handbook/interfederation/interfederation.html | 73 ++++ id/server/doc/handbook/intro/Blockdiagramm.png | Bin 84989 -> 201953 bytes id/server/doc/handbook/intro/anmeldeablauf.png | Bin 51580 -> 51158 bytes id/server/doc/handbook/intro/intro.html | 2 +- id/server/doc/handbook/protocol/protocol.html | 379 ++++++++++++++++++++- 7 files changed, 458 insertions(+), 12 deletions(-) create mode 100644 id/server/doc/handbook/interfederation/interfederation.html (limited to 'id/server/doc') diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index 57ed9a760..6a54d61c0 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -207,6 +207,16 @@

Hiermit kann die Sprache, welche für die Darstellung der Texte verwendet wird, festgelegt werden.

Hinweis: Aktuell wird nur Deutsch (de) oder Englisch (en) unterstützt.

+ + general.ssl.certstore + certs/certstore + Gibt den Pfadnamen zu einem Verzeichnis an, das als Zertifikatsspeicher im Zuge der TLS-Server-Zertifikatsüberprüfung verwendet wird. + + + general.ssl.truststore + certs/truststore + TrustedCACertificates enthält das Verzeichnis (relativ zur MOA-ID-Auth Basiskonfigurationsdatei), das jene Zertifikate enthält, die als vertrauenswürdig betrachtet werden. Im Zuge der Überprüfung der TLS-Serverzertifikate wird die Zertifikatspfaderstellung an einem dieser Zertifikate beendet. Dieses Verzeichnis wird zur Prüfung der SSL Serverzertifikate beim Download von PVP 2.1 Metadaten verwendet. + general.userrequests.cleanup.delay 18 @@ -1072,7 +1082,7 @@ Checking

TrustedCACertificates

certs/ca-certs - TrustedCACertificates enthält das Verzeichnis (relativ zur MOA-ID-Auth Basiskonfigurationsdatei), das jene Zertifikate enthält, die als vertrauenswürdig betrachtet werden. Im Zuge der Überprüfung der TLS-Serverzertifikate wird die Zertifikatspfaderstellung an einem dieser Zertifikate beendet. + TrustedCACertificates enthält das Verzeichnis (relativ zur MOA-ID-Auth Basiskonfigurationsdatei), das jene Zertifikate enthält, die als vertrauenswürdig betrachtet werden. Im Zuge der Überprüfung der TLS-Serverzertifikate wird die Zertifikatspfaderstellung an einem dieser Zertifikate beendet. Dieses Verzeichnis wird zur Prüfung der SSL Serverzertifikate für den Zugriff auf das Online-Vollmachten Service, den Stammzahlenregister Gateway und das abholen von PVP 2.1 Metadaten via SSL verwendet. ChainingMode diff --git a/id/server/doc/handbook/index.html b/id/server/doc/handbook/index.html index 2d694bfba..acab7517a 100644 --- a/id/server/doc/handbook/index.html +++ b/id/server/doc/handbook/index.html @@ -15,7 +15,7 @@

MOA-ID (Identifikation)

-

Übersicht zur Dokumentation der Version 2.0.2

+

Übersicht zur Dokumentation der Version 2.1.0

Einführung
@@ -26,6 +26,8 @@
Erläuterung aller Konfigurationsoptionen sowie Leitfaden für häufige Konfigurationsaufgaben.
Protokolle
Erläuterung der unterstützen Authentifizierungsprotokolle.
+
Interfederation
+
Dieser Abschnitt die Interfederation zwischen MOA-ID-Auth Services.
Anwendungen
Erläutert die Integration in bestehende Online-Applikationen und beschreibt die beigelegten Demo Applikationen
Zusatzinformationen
diff --git a/id/server/doc/handbook/interfederation/interfederation.html b/id/server/doc/handbook/interfederation/interfederation.html new file mode 100644 index 000000000..b67124806 --- /dev/null +++ b/id/server/doc/handbook/interfederation/interfederation.html @@ -0,0 +1,73 @@ + + + + + MOA-ID - Protokolle + + + + + + + + + +
Logo BKADokumentationLogo EGIZ
+
+

MOA-ID (Identifikation)

+

Interfederation

+
+

Inhalt

+
    +
  1. Allgemeines +
      +
    1. .
      2. +
    +
    2. +
+

 

+

Allgemeines

+

Ab der Version 2.0.2 des Modulepackets MOA-ID unterstützt das Modul MOA-ID-Auth Single Sign-On Interfederation zwischen Instanzen des Modules MOA-ID-Auth, welche bei unterschiedlichen Service Providern betrieben werden. Die nachfolgende Abbildung zeigt das Blockdiagramm einer solchen Systemkonfiguration und beschreibt die Funktionalität auf einer abstrakten Ebene.

+

 

+

 

+

 

+

 

+

A Referenzierte Spezifikation

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SpezifikationLink

Security Layer Spezifikation V1.2.0

http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/
PVP 2.1 S-Profil Spezifikationhttp://reference.e-government.gv.at/uploads/media/PVP2-S-Profil_2_0_0_a-2011-08-31.pdf
OpenID Connecthttp://openid.net/connect/
STORK 2@TODO Link
Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
+ + diff --git a/id/server/doc/handbook/intro/Blockdiagramm.png b/id/server/doc/handbook/intro/Blockdiagramm.png index f5bdb9e3a..1490530ea 100644 Binary files a/id/server/doc/handbook/intro/Blockdiagramm.png and b/id/server/doc/handbook/intro/Blockdiagramm.png differ diff --git a/id/server/doc/handbook/intro/anmeldeablauf.png b/id/server/doc/handbook/intro/anmeldeablauf.png index a6af21c5f..59bdefe62 100644 Binary files a/id/server/doc/handbook/intro/anmeldeablauf.png and b/id/server/doc/handbook/intro/anmeldeablauf.png differ diff --git a/id/server/doc/handbook/intro/intro.html b/id/server/doc/handbook/intro/intro.html index a95d8a01e..9b42c9e7a 100644 --- a/id/server/doc/handbook/intro/intro.html +++ b/id/server/doc/handbook/intro/intro.html @@ -41,7 +41,7 @@
  1. CORE LOGIC: Diese Komponente ist die zentrale Logik zur Steuerung der einzelnen Prozesse innerhalb MOA-ID 2.x.
  2. Protocol Adapter: Stellt die in MOA-ID 2.x unterstützten Authentifizierungsprotokolle für die Anbindung von Service Providern zur Verfügung.
    3. -
  3. Auth Sources: Stellt die von MOA-ID 2.x unterstützte Identifikationsmechanismen zur Verfügung. Dies sind die österreichische Bürgerkarte oder Handy-Signatur sowie die Anmeldung ausländischer Personen mit Hilfe des STORK Protokoll.
    4. +
  4. Auth Sources: Stellt die von MOA-ID 2.x unterstützte Identifikationsmechanismen zur Verfügung. Dies sind die österreichische Bürgerkarte oder Handy-Signatur, die Anmeldung ausländischer Personen mit Hilfe des STORK Protokoll oder mittels Single Sign-On von einem weiteren vertrauenswürdigen Identity Provider (Interfederation).
  5. Template Generator: Der Template Generator erzeugt für Service Provider die entsprechenden Login-Masken für die Integration in die eigene Web-Applikation.
  6. SSO Module: Das Single Sign-On (SSO) Modul verwaltet die zusätzlichen Operationen die sich aus der Umsetzung von SSO ergeben. Dies umfasst im Besonderen das SSO Session-Management.
  7. Statistic Module: Dieses Modul dient zur Generierung von anonymisierten Statistikdaten aus den Anmeldeinformationen.
    8. diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index 5055a4325..40277aa6b 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -23,6 +23,14 @@
    1. Übersicht der Zugangspunkte
    2. Übersicht der möglichen Attribute
      3. +
    3. Übersicht der möglichen MOA-ID spezifischen Statuscodes +
        +
      1. Statuscodes 1xxxx
        2. +
      2. Statuscodes 4xxxx
        3. +
      3. Statuscodes 6xxxx
        4. +
      4. Statuscodes 9xxxx
        5. +
      +
    4. Single Sign-On
    5. SSO Logout
    6. Legacy Request (Bürgerkartenauswahl beim Service Provider)
      7. @@ -35,7 +43,7 @@
    7. Zugangspunkte
      1. Authentifizierungsrequest
        2. -
      2. Authentifizierungsrespon
        3. +
      3. Authentifizierungsresponse
    @@ -50,6 +58,7 @@
  8. AuthCode Response
  9. AccessToken Request
  10. AccessToken Response
    11. +
  11. Error Response
@@ -486,7 +495,328 @@ Redirect Binding

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.

-

1.3 Single Sign-On

+

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.

+

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.

+

1.3.1.1 Authentifizierung (10xxx)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StatuscodeBeschreibung
1000Anmeldung an der angeforderten Online-Applikation wird nicht unterstützt.
1001Es ist bereits eine Anmeldung im Gange.
1002Fehlerhafter Parameter
1003Anfrage nur über https möglich
1004Zertifikat konnte nicht ausgelesen werden
1005Die Authentifizierung wurde durch den Benutzer abgebrochen
1006Vollmachtsmodus für nicht-öffentlichen Bereich wird nicht unterstützt.
1007Vollmachtsmodus für ausländische Personen wird nicht unterstützt.
+

1.3.1.2 Validierung (11xxx)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StatuscodeBeschreibung
1100Ungültige MOA SessionID
1101Fehler beim Parsen eines Parameters
1102Fehler beim Validieren der Personenbindung
1103Signatur ungültig
1104Zertifikat der Personenbindung ungültig
1105Zertifikat der Signature ungültig
1106Fehler beim Validieren des AuthBlocks
1107Fehler beim Validieren eines SSL-Server-Endzertifikates
1108Fehler beim Validieren der Online Vollmacht.
1109Fehler beim validieren der SZR-Gateway Response
+

1.3.1.3 STORK (12xxx)

+ + + + + + + + + + + + + + + + + + + + + +
StatuscodeBeschreibung
1200Fehler beim erstellen des STORK Authentifizierungsrequests
1201Fehler beim validieren der STORK Authentifizierungsresponse
1202STORK Authentifizierungsresponse antwortet mit einem Fehler
1203Fehler beim Sammeln von STORK Attributen
+

1.3.2 Statuscodes 4xxxx

+

Alles Statuscodes beginnent 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).

+

{40}{xxxxx}

+
+

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

+

{xxxx} .... Fehlercode der Bürgerkartenumgebung.

+
+

1.3.2.2 MIS (41xxxx)

+

Tritt während der Kommunikation mit dem Online-Vollmachten Service oder der Vollmachtsauswahl 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 Fehler aus dem Online-Vollmachten Service weißt das folgende zweiteilige Format auf. Der erste Teil, bestehend aus drei Dezimalstellen, kennzeichnet den Fehler als Fehler als Online-Vollmachten Service Fehler. Der zweite Teil, bestehend aus drei Dezimalstellen bezeichnet den eindeutigen Identifikator des Fehlers aus dem Online-Vollmachten Service (siehe Online-Vollmachten Spezifikation).

+

{411}{xxxx}

+
+

{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.

+ + + + + + + + + + + + + +
StatuscodeBeschreibung
41000Das Online-Vollmachten Service ist nicht erreichbar
41001Allgemeiner Fehler bei der Kommunikation mit dem Online-Vollmachten Service
+

1.3.2.3 SZR-Gateway (42xxx)

+ + + + + + + + + + + + + +
StatuscodeBeschreibung
4200Das SZR-Gateway Service ist nicht erreichbar
4201Die Antragung in das SZR ist fehlgeschlagen
+

1.3.2.4 MOA SP/SS(43xxx)

+ + + + + + + + + +
StatuscodeBeschreibung
4300Fehler beim Aufruf von MOA SP/SS
+

1.3.2.5 Interfederation (44xxx)

+ + + + + + + + + +
StatuscodeBeschreibung
4400Fehler 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.

+

1.3.3.1 Allgemein (61xxx)

+ + + + + + + + + + + + + +
StatuscodeBeschreibung
6000Das Authentifizierungsprotokoll wurde nicht erkannt oder wird nicht unterstüzt
6001Der STORK Request wurde nicht erkannt oder wird nicht unterstüzt
+

1.3.3.2 PVP 2.1 (61xxx)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StatuscodeBeschreibung
6100Fehler beim erstellen der PVP 2.1 Response
6101Fehler beim verschlüsseln der PVP 2.1 Assertion
6102Authentifizierung entspricht nicht dem geforderten QAA Level
6103Für die im Requst angegebene EnityID konnten keine gültigen Metadaten gefunden werden
6104Die Signatur des Requests konnte nicht gültig validiert werden. Entweder ist die Signatur ungültig oder das Signaturzertifikat stimmt nicht mit dem in den Metadaten hinterlegten Zertifikat überein.
6105Der Request konnte nicht gültig validiert werden.
+

1.3.3.3 OpenID Connect (62xxx)

+ + + + + + + + + +
StatuscodeBeschreibung
6200Fehlerhafte redirect url
+

1.3.3.4 SAML 1(63xxx)

+ + + + + + + + + +
StatuscodeBeschreibung
6300Fehlerhaftes SAML Artifact Format
+

1.3.4 Statuscodes 9xxxx

+

Alles Statuscodes beginnent mit der Zahl neun beschreiben interne Serverfehler.

+

1.3.4.1 Konfigurationsfehler (90xxx)

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StatuscodeBeschreibung
9000Fehlerhaftes BKU-Selection Template
9001Fehlerhaftes Send-Assertion Template
9002Fehlerhaftes SecurityLayer Template.
9003Fehlerhafte STORK VIDP Konfiguration
9004Fehlerhafte STORK Konfiguration
9005Fehlerhafte OpenID Connect Konfiguration
9006Es sind keine Vollmachtsprofile konfiguriert.
9007Der SZR-Gateway Client konnte nicht initialisiert werden.
+

1.3.4.2 Interne Fehler (91xxx)

+ + + + + + + + + + + + + + + + + + + + + + + + + +
StatuscodeBeschreibung
9100Fehler beim einlesen einer externen Resource.
9101Datenbankzugriffsfehler
9102Fehler beim Erzeugen einer internen Datenstruktur
9103Fehler bei der Verarbeitung eines Templates
9199Allgemeiner interner Fehler
+

 

+

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 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

@@ -515,7 +845,7 @@ Redirect Binding
  • 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.4 SSO Logout

    +

    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 SSO Logout Service steht unter folgender URL zur Verfügung und benötigt einen http GET Parameter:

    http://<host>:<port>/moa-id-auth/LogOut
@@ -543,7 +873,7 @@ https://<host>:<port>/moa-id-auth/LogOut
 
    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.
    
-
    1.5 Legacy Request (Bürgerkartenauswahl beim Service Provider)
    
+
    1.6 Legacy Request (Bürgerkartenauswahl beim Service Provider)
    
 
    Soll die Bürgerkartenauswahl jedoch weiterhin, wie aus MOA-ID 1.5.1 bekannt direkt in der Online-Applikation des Service Providers erfolgen muss für das jeweilige Protokoll der Legacy Modus aktiviert werden. Wird der Legacy Modus verwendet muss jedoch zusätzlich zu den protokollspezifischen Parametern mindestens der Parameter bkuURI, welcher die gewählte Bürgerkartenumgebung enthält, im Authentifizierungsrequest an MOA-ID-Auth übergeben werden (siehe Protokoll SAML 1). Die folgenden Parameter stehen bei Verwendung des Legacy Modus unabhängig vom verwendeten Protokoll zur Verfügung und bilden den gesamten Umfang der Bürgerkartenauswahl, wie aus MOA-ID 1.5.1 bekannt, ab.
    
 
@@ -713,10 +1043,11 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
     
+        
  • urn:oasis:names:tc:SAML:2.0:status:Requester: Der Authentifizierungsrequest konnte nicht erfolgreich validiert werden.
    • 
+      
+    
    Hinweis: Eine vollständige Aufstellung aller mögtlichen SAML2 spezifischen Statuscodes fnden Sie in der SAML2 Spezifikation.
    
   
    Dieses Element beinhaltet als Attribut den Status Code des Anmeldevorgangs. Nochfolgend die wichtigsten Statuscodes und eine kurze Beschreibung.
    
       
      
         
    • urn:oasis:names:tc:SAML:2.0:status:Success: Der Anmeldevorgang konnte Erfolgreich durchgeführt werden. 
      • 
-        
    • MOA-ID-Auth Fehlercode: Währenddes Anmeldevorgangs ist ein Fehler aufgetreten wobei für diesen Fehler in  Fehlercode existiert. Zusätzlich beinhaltet der Wert dieses Elements eine kurze Fehlerbeschreibung.
      • 
-        
    • urn:oasis:names:tc:SAML:2.0:status:Responder: Während des Anmeldevorgangs ist ein Fehler aufgetreten wobei diesem Fehler kein Fehlercode zugeordnet ist (Allgemeiner Fehler). Zusätzlich beinhaltet der Wert dieses Elements jedoch eine kurze Fehlerbeschreibung.
      • 
+        
    • urn:oasis:names:tc:SAML:2.0:status:Responder: Während des Anmeldevorgangs ist ein Fehler aufgetreten. Das Element /saml2p:Response/saml2p:Status/saml2p:StatusCode/saml2p:StatusCode  beinhaltet einen MOA-ID-Auth Fehlercode (siehe Kapitel 1.3). Zusätzlich beinhaltet der Wert dieses Elements jedoch eine kurze Fehlerbeschreibung.
      • 
         
    • urn:oasis:names:tc:SAML:2.0:status:NoPassive: Die BenutzerIn oder der Benutzer ist aktuell keine aktive und gültige Single Sign-On Session mit MOA-ID-Auth. Nähere Details zum isPassiv Authentifizierungsrequest finden Sie in der PVP 2.1 oder der SAML2 Spezifikation.
      • 
-    
    		
   
    
 
    
 
@@ -1002,6 +1333,31 @@ Folgende Parameter m
                XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
 } 
 
+
    3.2.5 Error Response
    
+
    Sollte während des Authentifizierungsvorgangs ein Fehler auftreten antwortet das Modul MOA-ID-Auth mit einer Error Response. Diese beinhaltet folgende Parameter
    
+
    
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+  
+    
+    
+    
+  
+
    NameBeispielwertBeschreibung
    errorinvalid_request_object
    Fehlercode laut OpenID Connect Spezifikation
    error_descriptionDer Request ist ungültig
    Kurze textuelle Fehlerbeschreibung
    error_urihttps://demo.egiz.gv.at/demoportal_moaid-2.0/moa_errorcodes.html#1000URL auf eine Seite mit zusätzlicher Fehlerbeschreibung
    
+
     
    
 
    3 SAML 1
    
 
    SAML 1 wird durch MOA-ID-Auth 2.0 auch weiterhin, aus Gründen der Abwärtskompatibilität, als Authentifizierungsprotokoll unterstützt. Es wird jedoch der Umstieg auf ein aktuelles Authentifizierungsprotokoll wie PVP 2.1 oder OpenID Connect empfohlen.
    
 
    Die nachfolgenden   Abschnitte beschreiben den Anmeldevorgang unter Verwendung von SAML1 wobei die Funktionalität, wie sie aus MOA-ID <= 1.5.1 bekannt ist, auch weiterhin unterstützt wird (Bürgerkartenauswahl auf Seiten des Service Provider). Zusätzlich steht für SAML 1 jedoch auch die Funktionalität der automatischen Generierung der Bürgerkartenauswahl durch das Modul MOA-ID-Auth zur Verfügung.
    
@@ -1116,13 +1472,14 @@ In diesem Redirect werden der Geschäftsbereich und ein SAML-Artifact als Pa
 
    Der Service Provider kann anschließend die Assertion, welche die Anmeldedaten oder eine Fehlermeldung beinhaltet, unter Verwendung des SAMLArtifact, am Modul MOA-ID-Auth abholen.
    
 
    Das MOA-ID-AUTH Web Service wird über einen <samlp:Request> aufgerufen.    Der <samlp:Request> enthält in einem <samlp:AssertionArtifact> das von MOA-ID-AUTH übergebene SAML-Artifact. 
    
   
    
-MOA-ID-AUTH liefert als Antwort einen <samlp:Response>. Die   Anmeldedaten sind im <samlp:Response> in Form einer   <saml:Assertion> enthalten. 
    
+MOA-ID-AUTH liefert als Antwort einen <samlp:Response>. Die   Anmeldedaten sind im <samlp:Response> in Form einer   <saml:Assertion> enthalten. 
    
+Sollte während des Anmeldevorgangs ein Fehler aufgetreten sein, antworted das Modul MOA-ID-Auth mit einer Fehlerbeschreibung in der SAML Response. Das Element /samlp:Response/samlp:Status/samlp:StatusCode/ beinhaltet auf jeden Fall einen allgemeinen Fehlercode laut SAML1 Spezifikation. Zusätzlich kann das Element /samlp:Response/samlp:Status/samlp:StatusCode/samlp:StatusCode/einen MOA-ID-Auth Fehlercode (siehe Kapitel 1.3) beinhalten.  Außerdem erfolgt eine kurze textuelle Fehlerbeschreibung im Element /samlp:Response/samlp:Status/samlp:StatusMessage/.
    
 
-
    Der detaillierte Aufbau der <saml:Assertion> zu den Anmeldedaten ist in der Spezifikation MOA-ID 1.4 beschrieben. 
    
+
    Der detaillierte Aufbau der <saml:Assertion> zu den Anmeldedaten ist in der Spezifikation MOA-ID 1.4 beschrieben.
    
 
    A Referenzierte Spezifikation
    
 
@@ -1134,6 +1491,10 @@ MOA-ID-AUTH liefert als Antwort einen <samlp:Response>. Die   Anmeldedaten
       
+    
+      
+      
+    
-- 
cgit v1.2.3


    
   
    Security Layer Spezifikation V1.2.0
    		
       http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/
     
    Online-Vollmachten Spezifikation http://reference.e-government.gv.at/AG-II-Architektur-mis-1-1-0.2890.0.html
    
     
    
       PVP 2.1 S-Profil Spezifikation
       http://reference.e-government.gv.at/uploads/media/PVP2-S-Profil_2_0_0_a-2011-08-31.pdf