Dieses Kapitel behandelt jene Authentifizierungsprotokolle die vom Modul MOA-ID-Auth unterstützt werden. Wobei die Verwendung der Protokolle PVP 2.1 oder OpenID Connect empfohlen wird. Das Protokoll SAML 1, welches bis zur MOA-ID Version 1.5.1 verwendet wurde, wird jedoch ab der Version 2.0 nur mehr aus Kompatibilitätsgründen angeboten und nicht mehr aktiv weiterentwickelt.
In diesem Abschnitt sind die Zugangspunkte der vom Modul MOA-ID-Auth unterstützten Protokolle kurz zusammengefasst. Eine detaillierte Beschreibung der einzelnen Protokolle finden Sie in den anschließenden Unterkapiteln.
| Protokoll | Requesttyp | URL |
|---|---|---|
| PVP 2.1 | Metadaten | https://<host>:<port>/moa-id-auth/pvp2/metadata |
| Authentifizierungsrequest POST Binding |
https://<host>:<port>/moa-id-auth/pvp2/post | |
| Authentifizierungsrequest Redirect Binding |
https://<host>:<port>/moa-id-auth/pvp2/redirect | |
| PVP 2.1 | Attribut Query für IDP Interfederation | https://<host>:<port>/moa-id-auth/pvp2/attributequery |
| PVP 2.1 | Single LogOut | https://<host>:<port>/moa-id-auth/pvp2/redirect |
| OpenID Connect | Authentifizierungsrequest (AuthCode-Request) |
https://<host>:<port>/moa-id-auth/oauth3/auth |
| OpenID Connect | AccessToken-Request |
https://<host>:<port>/moa-id-auth/oauth3/token |
| SAML 1 | Authentifizierungsrequest | https://<host>:<port>/moa-id-auth/StartAuthentication |
| SAML 1 | GetAuthenticationData |
https://<host>:<port>/moa-id-auth/services/GetAuthenticationData http://<host>:<port>/moa-id-auth/services/GetAuthenticationData |
| SSO LogOut | LogOut | https://<host>:<port>/moa-id-auth/LogOut http://<host>:<port>/moa-id-auth/LogOut |
| IDP Single LogOut | Single LogOut | https://<host>:<port>/moa-id-auth/idpSingleLogout http://<host>:<port>/moa-id-auth/idpSingleLogout |
Die nachfolgende Tabelle beinhaltet eine Liste aller Attribute die vom Modul MOA-ID-Auth an die Online-Applikation zurückgeliefert werden können, sofern diese nach der Authentifizierung zur Verfügung stehen. Alle Namen beziehen sich auf den Attributnamen im jeweiligen Protokoll. Detailinformationen zu den einzelnen Attributen finden Sie in der PVP 2.1 Spezifikation der der STORK Spezifikation.
| Protokolle | Beschreibung | |||
|---|---|---|---|---|
| PVP 2.1 | OpenID Connect | SAML 1 | ||
| Name | Profil | |||
| urn:oid:1.2.40.0.10.2.1.1.149 | BPK | eID | /saml:Assertion/saml:AttributeStatement/ saml:Subject/saml:NameIdentifier |
Bereichsspezifisches Personenkennzeichen (bPK / wbPK) Hinweis: Der Syntax für dieses Attribut bei den Protokollen PVP 2.1 und OpenID Connect ist bPK-value := (BEREICH ":" bPK/wbPK) wobei unter Bereich der öffentliche Bereich (Target) der Online-Applikation oder die Stammzahl des Auftraggebers bei Anwendungs-verantwortlichen aus der Privatwirtschaft angegeben wird. |
urn:oid:2.5.4.42 |
given_name | profile | <saml:Attribute AttributeName="PersonData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Vorname |
urn:oid:1.2.40.0.10.2.1.1.261.20 |
family_name | profile | <saml:Attribute AttributeName="PersonData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Familienname |
| urn:oid:1.2.40.0.10.2.1.1.55 | birthdate | profile | <saml:Attribute AttributeName="PersonData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Geburtsdatum im Format JJJJ-MM-TT |
| urn:oid:1.2.40.0.10.2.1.1.261.64 | EID-CCS-URL | eID | <saml:Attribute AttributeName="bkuURL" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#"> | URL auf die Bürgerkartenumgebung die für die Authentifizierung verwendet wurde. Im Falle einer Anmeldung mittels STORK steht dieses Attribut NICHT zur Verfügung. |
| urn:oid:1.2.40.0.10.2.1.1.261.94 | EID-CITIZEN-QAA-LEVEL | eID | Authentifizierungslevel des Bürgers | |
| urn:oid:1.2.40.0.10.2.1.1.261.32 | EID-ISSUING-NATION | eID | Landescode gem. ISO-3166 ALPHA-2 | |
| urn:oid:1.2.40.0.10.2.1.1.261.34 | EID-SECTOR-FOR-IDENTIFIER | eID | Bereich für den die bPK / wbPK berechnet wurde. | |
| urn:oid:1.2.40.0.10.2.1.1.261.62 | EID-AUTH-BLOCK | eID | /saml:Assertion/saml:AttributeStatement/ saml:Subject/saml:SubjectConfirmation/ saml:SubjectConfirmationData |
Base64 kodierte Signatur die während des Authentifizierungsvorgangs vom Benutzer erzeugt wurde. |
| urn:oid:1.2.40.0.10.2.1.1.261.66 | EID-SIGNER-CERTIFICATE | eID | <saml:Attribute AttributeName="SignerCertificate" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#"> | Base64 kodiertes Zertifikat, dass für die Anmeldung verwendet wurde. |
| urn:oid:1.2.40.0.10.2.1.1.261.36 | EID-SOURCE-PIN | eID_gov | <saml:Attribute AttributeName="PersonData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Stammzahl der natürlichen Person Hinweis: Dieses Attribut steht nur zur Verfügung wenn die Online-Applikation alle Anforderungen an eine Applikation aus dem öffentlichen Bereich erfüllt. |
| urn:oid: 1.2.40.0.10.2.1.1.261.104 | EID-SOURCE-PIN-TYPE | eID_gov | <saml:Attribute AttributeName="PersonData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Bereich der Stammzahl, wobei aktuell nur ein Bereich existiert. Hinweis: Dieses Attribut steht nur zur Verfügung wenn die Online-Applikation alle Anforderungen an eine Applikation aus dem öffentlichen Bereich erfüllt. |
| urn:oid:1.2.40.0.10.2.1.1.261.38 | EID-IDENTITY-LINK | eID_gov | /saml:Assertion/saml:AttributeStatement/ saml:Subject/saml:SubjectConfirmation/ saml:SubjectConfirmationData |
Gesamte Personenbindung in BASE64 kodiert. Hinweis: Im Falle einer privatwirtschaftlichen Applikation ist die Stammzahl durch die wbPK ersetzt. |
| urn:oid:1.2.40.0.10.2.1.1.261.106 | MANDATE-TYPE-OID | mandate | Bezeichnung als OID des verwendeten Vollmachten-Profils | |
| urn:oid:1.2.40.0.10.2.1.1.261.68 | MANDATE-TYPE | mandate | <saml:Attribute AttributeName="RepresentationType" AttributeNamespace="http://reference.e-government.gv.at/namespace/mandates/20040701#"> | Bezeichnung des verwendeten Vollmachten-Profils. |
| urn:oid:1.2.40.0.10.2.1.1.261.102 | MANDATOR-NATURAL-PERSON-SOURCE-PIN-TYPE | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Bereich der Stammzahl der vertretenen natürlichen Person, wobei aktuell nur ein Bereich existiert. |
| urn:oid:1.2.40.0.10.2.1.1.261.70 | 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. Vertretungsbefugnisse ausgeübt werden. |
| urn:oid:1.2.40.0.10.2.1.1.261.76 | MANDATOR-LEGAL-PERSON-SOURCE-PIN-TYPE | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Gibt an, um welche Art der Stammzahl einer vertretenen juristischen Person es sich handelt. |
| urn:oid:1.2.40.0.10.2.1.1.261.100 | MANDATOR-LEGAL-PERSON-SOURCE-PIN | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Stammzahl der juristischen Person, für die Vollmachts- bzw. Vertretungsbe-fugnisse ausgeübt werden. |
| urn:oid:1.2.40.0.10.2.1.1.261.98 | MANDATOR-NATURAL-PERSON-BPK | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Bereichsspezifisches Personenkennzeichen des Vollmachtgebers |
| urn:oid:1.2.40.0.10.2.1.1.261.78 | MANDATOR-NATURAL-PERSON-GIVEN-NAME | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Vorname(n) der natürlichen Person, die die Vollmacht erteilt hat, bzw. die vertreten wird. |
| urn:oid:1.2.40.0.10.2.1.1.261.80 | MANDATOR-NATURAL-PERSON-FAMILY-NAME | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Nachname der Person, die die Vollmacht erteilt hat, bzw. die vertreten wird. |
| urn:oid:1.2.40.0.10.2.1.1.261.82 | MANDATOR-NATURAL-PERSON-BIRTHDATE | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Geburtsdatum der Person, die die Vollmacht erteilt hat, bzw. die vertreten wird im Format JJJJ-MM-TT |
| urn:oid:1.2.40.0.10.2.1.1.261.84 | 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äß zugrundeliegendem Register. |
| urn:oid:1.2.40.0.10.2.1.1.261.86 | MANDATE-PROF-REP-OID | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Object Identifiern (OID) zur Kennzeichnung von berufsmäßigen ParteienvertreterInnen bzw. OrganwalterInnen. |
| urn:oid:1.2.40.0.10.2.1.1.261.88 | MANDATE-PROF-REP-DESCRIPTION | mandate | <saml:Attribute AttributeName="MandateData" AttributeNamespace="http://reference.e-government.gv.at/namespace/persondata/20020228#"> | Textuelle Beschreibung der Eigenschaft als berufsmäßiger ParteienvertreterIn. |
| urn:oid:1.2.40.0.10.2.1.1.261.90 | MANDATE-REFERENCE-VALUE | mandate | <saml:Attribute AttributeName="mandateReferenceValue" AttributeNamespace="http://reference.e-government.gv.at/namespace/moa/20020822#"> | Die im Rahmen einer elektronischen Vollmachtserstellung generierte Transaktionsnummer. |
| urn:oid:1.2.40.0.10.2.1.1.261.92 | MANDATE-FULL-MANDATE | mandate | <saml:Attribute AttributeName="Mandate" AttributeNamespace="http://reference.e-government.gv.at/namespace/mandates/20040701#"> | Base64 kodierte Vollmacht im XML Format gemäß Vollmachten-Spezifikation. |
| urn:oid:1.2.40.0.10.2.1.1.261.96 | EID-STORK-TOKEN | stork | Beinhaltet die komplette Response Message eines STORK Providers im Base64-Format. | |
| http://www.stork.gov.eu/1.0/ inheritedFamilyName |
inheritedFamilyName | stork | http://www.stork.gov.eu/1.0/ inheritedFamilyName |
Vererbter Familienname Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ adoptedFamilyName |
adoptedFamilyName | stork | http://www.stork.gov.eu/1.0/ adoptedFamilyName |
Angenommener Familienname Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ gender |
gender | stork | http://www.stork.gov.eu/1.0/ gender |
Geschlecht Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ countryCodeOfBirth |
countryCodeOfBirth | stork | http://www.stork.gov.eu/1.0/ countryCodeOfBirth |
Geburtsland Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ nationalityCode |
nationalityCode | stork | http://www.stork.gov.eu/1.0/ nationalityCode |
Nationalität Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ maritalStatus |
maritalStatus | stork | http://www.stork.gov.eu/1.0/ maritalStatus |
Familienstand Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ textResidenceAddress |
textResidenceAddress | stork | http://www.stork.gov.eu/1.0/ textResidenceAddress |
Wohnadresse in Textform Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ canonicalResidenceAddress |
canonicalResidenceAddress | stork | http://www.stork.gov.eu/1.0/ canonicalResidenceAddress |
Anerkannte Wohnadresse Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ title |
title | stork | http://www.stork.gov.eu/1.0/ title |
Titel Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ residencePermit |
residencePermit | stork | http://www.stork.gov.eu/1.0/ residencePermit |
Aufenthaltsbewilligung Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ pseudonym |
pseudonym | stork | http://www.stork.gov.eu/1.0/ pseudonym |
Pseudonym Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ age |
age | stork | http://www.stork.gov.eu/1.0/ age |
Alter Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ isAgeOver |
isAgeOver | stork | http://www.stork.gov.eu/1.0/ isAgeOver |
Mindestalter erreicht Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
| http://www.stork.gov.eu/1.0/ fiscalNumber |
fiscalNumber | stork | http://www.stork.gov.eu/1.0/ fiscalNumber |
Steuernummer Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung. |
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.
Alle Statuscodes beginnend mit der Zahl eins beschreiben Fehler welche während des Identifizierungs- und Authentifizierungsvorgangs aufgetreten sind.
| Statuscode | Beschreibung |
|---|---|
| 1000 | Anmeldung an der angeforderten Online-Applikation wird nicht unterstützt. |
| 1001 | Es ist bereits eine Anmeldung im Gange. |
| 1002 | Fehlerhafter Parameter |
| 1003 | Anfrage nur über https möglich |
| 1004 | Zertifikat konnte nicht ausgelesen werden |
| 1005 | Die Authentifizierung wurde durch den Benutzer abgebrochen |
| 1006 | Vollmachtsmodus für nicht-öffentlichen Bereich wird nicht unterstützt. |
| 1007 | Vollmachtsmodus für ausländische Personen wird nicht unterstützt. |
| 1008 | Es konnten nicht alle minimal erforderlichen Identifikations- oder Authentifikationsmerkmale ermittelt werden. |
| Statuscode | Beschreibung |
|---|---|
| 1100 | Ungültige MOA SessionID |
| 1101 | Fehler beim Parsen eines Parameters |
| 1102 | Fehler beim Validieren der Personenbindung |
| 1103 | Signatur ungültig |
| 1104 | Zertifikat der Personenbindung ungültig |
| 1105 | Zertifikat der Signatur ungültig |
| 1106 | Fehler beim Validieren des AuthBlocks |
| 1107 | Fehler beim Validieren eines SSL-Server-Endzertifikates |
| 1108 | Fehler beim Validieren der Online Vollmacht. |
| 1109 | Fehler beim Validieren der SZR-Gateway Response |
| 1110 | Ungültige Single Sign-On Session |
| Statuscode | Beschreibung |
|---|---|
| 1200 | Fehler beim Erstellen des STORK Authentifizierungsrequests |
| 1201 | Fehler beim Validieren der STORK Authentifizierungsresponse |
| 1202 | STORK Authentifizierungsresponse antwortet mit einem Fehler |
| 1203 | Fehler beim Sammeln von STORK Attributen |
| 1204 | Ein STORK Attribut weißt ein fehlerhaftes Format auf. |
| 1205 | Der geforderte QAA Level ist höher als der QAA Level der gewählten Authentifizierungsmethode |
| Statuscode | Beschreibung |
|---|---|
| 1300 | Fehler beim Erstellen des eIDAS Authentifizierungsrequests |
| 1301 | Fehler beim Validieren der eIDAS Authentifizierungsresponse |
| 1302 | Response vom eIDAS Node enthält einen Fehler |
| 1303 | eIDAS Response beinhaltet nicht alle minimal erforderlichen Attribute |
| 1304 | Der ausgewählte eIDAS Node existiert nicht oder ist nicht konfiguriert |
| 1305 | eIDAS Request konnte nicht gültig verarbeitet werden |
| 1306 | Generierung dereIDAS Metadaten fehlgeschlagen |
| 1399 | Interner Fehler in der eIDAS SAML-Engine |
Alles Statuscodes beginnend mit der Zahl vier beschreiben Fehler die während der Kommunikation mit externen Services aufgetreten sind.
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
{xxxx} .... Fehlercode der Bürgerkartenumgebung.
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 gemappten Fehlern aus dem Online-Vollmachen Service werden zusätzliche weitere Fehlercodes definiert.
| Statuscode | Beschreibung |
|---|---|
| 41000 | Das Online-Vollmachten Service ist nicht erreichbar |
| 41001 | Allgemeiner Fehler bei der Kommunikation mit dem Online-Vollmachten Service |
| Statuscode | Beschreibung |
|---|---|
| 4200 | Das SZR-Gateway Service ist nicht erreichbar |
| 4201 | Die Antragung in das SZR ist fehlgeschlagen |
| Statuscode | Beschreibung |
|---|---|
| 4300 | Fehler beim Aufruf von MOA SP/SS |
| Statuscode | Beschreibung |
|---|---|
| 4400 | Fehler beim Generieren der Anmeldedaten |
| 4401 | Die Verwendung des angeforderten federated IDP ist nicht erlaubt |
| Statuscode | Beschreibung |
|---|---|
| 4500 | Der Zugriff auf einen Attributprovider ist nicht erlaubt |
| 4501 | Die Requestgenerierung für den Zugriff auf den Attributprovider schlug fehl |
| 4502 | Die Response vom Attributeprovider ist ungültig oder nicht errlaubt |
| 4503 | Die Response vom Attributeprovider beinhaltet einen Fehlercode |
Alles Statuscodes beginnend mit der Zahl sechs beschreiben protokollspezifische Fehler die nicht durch das jeweilige Authentifizierungsprotokoll abgebildet werden.
| Statuscode | Beschreibung |
|---|---|
| 6000 | Das Authentifizierungsprotokoll wurde nicht erkannt oder wird nicht unterstützt |
| 6001 | Der STORK Request wurde nicht erkannt oder wird nicht unterstützt |
| Statuscode | Beschreibung |
|---|---|
| 6100 | Fehler beim Erstellen der PVP 2.1 Response |
| 6101 | Fehler beim Verschlüsseln der PVP 2.1 Assertion |
| 6102 | Authentifizierung entspricht nicht dem geforderten QAA Level |
| 6103 | Für die im Reqeust angegebene EntityID konnten keine gültigen Metadaten gefunden werden |
| 6104 | Die 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. |
| 6105 | Der Request konnte nicht gültig validiert werden. |
| Statuscode | Beschreibung |
|---|---|
| 6200 | Fehlerhafte redirect url |
| Statuscode | Beschreibung |
|---|---|
| 6300 | Fehlerhaftes SAML Artifact Format |
Alles Statuscodes beginnend mit der Zahl neun beschreiben interne Serverfehler.
| Statuscode | Beschreibung |
|---|---|
| 9000 | Fehlerhaftes BKU-Selection Template |
| 9001 | Fehlerhaftes Send-Assertion Template |
| 9002 | Fehlerhaftes SecurityLayer Template. |
| 9003 | Fehlerhafte STORK VIDP Konfiguration |
| 9004 | Fehlerhafte STORK Konfiguration |
| 9005 | Fehlerhafte OpenID Connect Konfiguration |
| 9006 | Es sind keine Vollmachtsprofile konfiguriert. |
| 9007 | Der SZR-Gateway Client konnte nicht initialisiert werden. |
| 9008 | Fehler beim Verarbeiten eines Konfigurationsparameters. |
| 9099 | Allgemeiner Konfigurationsfehler |
| Statuscode | Beschreibung |
|---|---|
| 9100 | Fehler beim Einlesen einer externen Ressource. |
| 9101 | Datenbankzugriffsfehler |
| 9102 | Fehler beim Erzeugen einer internen Datenstruktur |
| 9103 | Fehler bei der Verarbeitung eines Templates |
| 9104 | Fehler bei der Auswahl oder Initialisierung des gewünschten Anmeldeprozesses |
| 9105 | Fehler bei der Fortführung des Anmeldeprozesses |
| 9199 | Allgemeiner interner Fehler |
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.
Zusätzliche Informationen zur Konfiguration und die sich daraus ergebenden Anforderungen oder Einschränkungen finden sie hier.
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
bzw.
https://<host>:<port>/moa-id-auth/LogOut
| Name | Beispielwert | Beschreibung |
|---|---|---|
| redirect | 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. |
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.
Ab der Version 2.1 unterstützt das Modul MOA-ID-Auth Single LogOut (SLO) laut SAML2 Spezifikation. Die SLO Funktionaltität steht jedoch nur für Online-Applikationen zur Verfügung welche als Authentifizierungsprotokoll PVP 2.1 verwenden. Für alle anderen Authentifizierungsprotokolle steht aktuell kein SLO zur Verfügung.
Für Single LogOut stehen sowohl IDP initialisiertes SLO als auch Service Provider initialisiertes SLO zur Verfügung. Als Einsprungpunkt für IDP initialisiertes SLO stellt das Modul MOA-ID-Auth folgende Web Adressen zur Verfügung. Nach dem Aufruf dieses Services wird der Single LogOut Vorgang gestartet. Nach erfolgreicher Bearbeitung aller SLO Requests / Response erfolgt die Statusausgabe in den Browser.
https://<host>:<port>/moa-id-auth/idpSingleLogout
bzw.
http://<host>:<port>/moa-id-auth/idpSingleLogout
Die Endpunkte für Service Provider initialisietes SLO finden Sie in den PVP 2.1 Metadaten.
Hinweis: Wenn Single Sign-On mit Authentifizierungsprotokollen, welche kein SLO untersützen verwendet wurde, schlägt der Single LogOut Vorgang auf jeden Fall fehl, da der Benutzer an den jeweiligen Online-Applikationen nicht angemeldet werden kann. Die SSO Session am Identityprovider wird jedoch auf jeden Fall beendet
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.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| 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 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ü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). |
| useMandate=<true/false> | true / false | Optional: Gibt an ob eine Anmeldung im Online-Vollmachten-Modus durchgeführt werden soll (=true) oder nicht (=false); |
| CCC=<ccc> | BE, SI, | 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. |
Hinweis: Bei einer vollständigen Neukonfiguration ist der Legacy Modus standardmäßig für alle Protokolle deaktiviert.
Hinweis: Bei der Verwendung des Legacy Request für die Bürgerkartenauswahl ist jedoch zu beachten dass im Falle einer aktiven Single Sign-On Session, MOA-ID-Auth mit einer Abfrage zum SSO Anmeldevorgang antwortet.
Die PVP 2.1 Implementierung des Modules MOA-ID-Auth bezieht sich auf das S-Profil der PVP 2 Spezifikation. Das S - Profil von PVP 2 verwendet SAML WebSSO für die Authentifizierung von Benutzern mit Webbrowser. Dadurch wird die direkte Kommunikation des Browsers mit der Anwendung ermöglicht, was in Anwendungsfällen notwendig ist, wo Anwendungen nicht kompatibel mit dem Reverse - Proxy - Verfahren sind, datenschutzrechtliche Probleme bestehen oder SAML WebSSO als Industriestandard unterstützt werden soll.
Bevor PVP 2.1 als Authentifizierungsprotokoll verwendet werden kann muss das Modul MOA-ID-Auth entsprechend konfiguriert werden. Detailinformationen zur Konfiguration finden Sie hier.
Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels PVP 2.1 und des Modules MOA-ID-Auth als Identity Provider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.
Das Modul MOA-ID-Auth stellt für Service-Provider (Online-Applikationen) Metadaten bereit welche alle PVP 2.1 spezifischen Informationen der MOA-ID-Auth Instanz beinhalten. Diese Metadaten werden durch das Modul MOA-ID-Auth signiert, wodurch Service Provider die Authentizität der Metadaten verifizieren können. Ein Beispiel für Metadaten von MOA-ID-Auth finden sie hier. Die aktuellen Metadaten zu Ihrer MOA-ID-Auth Instanz können unter folgender URL abgerufen werden.
http://<host>:<port>/moa-id-auth/pvp2/metadata
bzw.
https://<host>:<port>/moa-id-auth/pvp2/metadata
Hinweis: Ist die deployed MOA-ID Instanz für mehrere virtuelle IDPs konfiguriert, so können die Metadaten für die jeweiligen virutellen Entities über den PublicURLPrefix der jeweiligen virtuellen Instanz abgerufen werden. Z.B. https://aaa.com/moa-id-auth/pvp2/metadata für virtuellen IDP aaa.com oder https://bbb.com/moa-id-auth/pvp2/metadata für virtuellen IDP bbb.com
Wollen Sie für Ihre Online-Applikation PVP 2.1 als Authentifizierungsprotokoll nutzen müssen für jede Online-Applikation Metadaten erstellt und durch den Service Provider signiert werden. Zusätzlich muss die URL auf die Metadaten und das entsprechende Signaturzertifikat zur Prüfung der Signatur in der online-applikationsspezifischen PVP 2.1 Konfiguration von MOA-ID-Auth hinterlegt sein. Ein Beispiel für online-applikationsspezifische Metadaten finden Sie hier.
Die nachfolgenden Anforderungen an die online-applikationsspezifischen Metadaten .
entityID im Element md:EntitiesDescriptor/md:EntityDescriptor (siehe Beispiel) den eindeutigen Identifier enthält der für diese Online-Applikation bei MOA-ID-Auth hinterlegt ist. md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor mit dem Attribut use="signing" vorhanden sein (siehe Beispiel).md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:AssertionConsumerService enthalten welches das gewünschte Binding und die URL zur Auslieferung der Assertion beinhaltet. md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:AttributeConsumingService zur Verfügung wobei die als Kindelemente md:RequestedAttribute die einzelnen benötigten Attribute definieren (siehe Beispiel).Zusätzlich unterstützt das Modul MOA-ID-Auth auch die Verschlüsselung PVP 2.1 Assertion mit einem vom Service-Provider definierten Zertifikat. Um diese Funktion zu nutzen muss in den Metadaten ein zweites XML Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor mit dem Attribut use="encryption" vorhanden sein (siehe Beispiel). In diesem Fall verwendet das Modul MOA-ID-Auth, dass in diesem Element hinterlegte Zertifikat zur Verschlüsselung der PVP 2.1 Assertion.
Hinweis: Fehlt im XML Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:KeyDescriptor das Attribut use wird das in diesem Element hinterlegte Zertifikat sowohl zur Prüfung der Signatur des Authentifizierungsrequest als auch zur Verschlüsselung der PVP 2.1 Assertion verwendet.
Für die Kommunikation zwischen Service Provider und dem Modul MOA-ID-Auth stellt MOA-ID-Auth aktuell zwei PVP 2.1 spezifische Zugangspunkte zur Verfügung. Detailinformationen zu den beiden Zugangspunkten (Bindings) entnehmen finden Sie in der SAML2 Spezifikation.
https://<host>:<port>/moa-id-auth/pvp2/post
https://<host>:<port>/moa-id-auth/pvp2/redirect
Hinweis: Die Zugangspunkte können auch direkt aus den von MOA-ID-Auth generierten Metadaten entnommen werden.
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.
| Name | saml2p:AuthnRequest/saml2:Issuer |
| Gebrauch | Ein Mal |
| Erläuterung | Der Wert dieses Elements muss den eindeutigen Identifier enthalten der für diese Online-Applikation bei MOA-ID-Auth hinterlegt ist (siehe Beispiel). |
| Name | /saml2p:AuthnRequest/@ID |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Attribut beinhaltet einen vom Service Provider generierten Identifikator für diesen Authentifizierungsrequest. |
Einen Beispielrequest finden Sie hier.
Hinweis: Detailinformationen finden Sie im Abschnitt Spezifikationen in der PVP 2.1 Spezifikation und der SAML2 Spezifikation.
Nach erfolgreicher Authentifizierung antwortet das Modul MOA-ID-Auth mit einer PVP 2.1 Assertion. Zur Übertragung der Assertion erfolgt an das in den Metadaten der Online-Applikation angegebene AssertionConsumerService (siehe Metadaten).
Aktuell werden vom Modul MOA-ID-Auth zwei Bindings zur Übertragung der Assertion unterstützt.
Der Inhalt der Assertion unterscheidet sich je nachdem welche Attribute in den Metadaten angefordert wurden und ob während des Anmeldevorgangs ein Fehler aufgetreten ist. Die nachfolgende Aufstellung gibt eine Übersicht über jede Elemente die in der Assertion enthalten sind, wenn keine zusätzlichen Attribute angefordert wurden. Diese Aufstellung beschreibt jedoch nur einige markante Elemente und ist somit nicht vollständig. Detailinformationen zu allen Elementen und Attributen finden Sie in der PVP 2.1 oder der SAML2 Spezifikation. Eine Beispielresponse finden Sie hier.
| Name | /saml2p:Response/ds:Signature |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Element enthält die Signatur, mit welchem die Assertion vom Modul MOA-ID-Auth unterschieben wurde. Das Zertifikat zur Prüfung der Signatur wird in den Metadaten des Modules MOA-ID-Auth bereitgestellt. |
| Name | /saml2p:Response/saml2p:Status/saml2p:StatusCode |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Element beinhaltet als Attribut den Status Code des Anmeldevorgangs. Nachfolgend die wichtigsten Statuscodes und eine kurze Beschreibung.
Hinweis: Eine vollständige Aufstellung aller möglichen SAML2 spezifischen Statuscodes finden Sie in der SAML2 Spezifikation. |
| Name | /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Element beinhaltet das bereichsspezifischen Personenkennzeichen (bPK / wbPK) der authentifizierten Person. |
| Name | /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/@NameQualifier |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Attribut beinhaltet den Bereich des bereichsspezifischen Personenkennzeichens (bPK / wbPK) |
| Name | /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/saml2:SubjectConfirmationData/@InResponseTo |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Attribut beinhaltet den vom Service Provider im Authentifizierungsrequest generierten Identifikator. |
| Name | /saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/saml2:SubjectConfirmationData/@NotOnOrAfter |
| Gebrauch | Ein Mal |
| Erläuterung | Dieses Attribut beinhaltet einen von MOA-ID-Auth ausgestellten Gültigkeitszeitraum für diese Assertion. Aktuell beträgt der Gültigkeitszeitraum fünf Minuten ab dem Ausstellzeitpunkt. |
OpenID Connect ist ein Authentifizierungsprotokoll welches auf dem OAuth 2.0 Protokoll aufbaut. Dieses Protokoll erlaubt Online-Applikationen die Identifizierung und Authentifizierung von Benutzern, mit Hilfe des Modules MOA-ID-Auth. Der Vorteil von OpenID Connect im Vergleich zu auf SAML basierten Protokollen (PVP 2.1, SAML 1) ist der einfachere Aufbau der einzelnen Protokollnachrichten. Zusätzlich existieren einige frei Verfügbare Bibliotheken für unterschiedliche Programmiersprachen, welche OpenID Connect implementieren.
Bevor OpenID Connect in Kombination mit dem Modul MOA-ID-Auth verwendet werden kann muss das Modul MOA-ID-Auth konfiguriert werden. Detailinformationen zur Allgemeinen Konfiguration und zur online-applikationsspezifischen Konfiguration finden Sie im jeweiligen Abschnitt des Kapitels Konfiguration.
Die nachfolgende Beschreibung gibt einen kurzen Überblick zur Verwendung des Protokolls OpenID Connect in Kombination mit dem Modul MOA-ID-Auth. Detailinformationen zu OpenID Connect entnehmen Sie bitte der aktuellen OpenID Connect Spezifikation
Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels OpenID Connect und des Modules MOA-ID-Auth als Identity Provider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.
Zur Verwendung von OpenID Connect stellt das Modul MOA-ID-Auth zwei Zugangspunkte zur Kommunikation mit der Online-Applikation zur Verfügung. Diese Zugangspunkte bezeichnen die URLs unter welchen das Modul MOA-ID-Auth die entsprechenden OpenID Connect Nachrichten entgegennimmt.
Dieser Abschnitt beschreibt die einzelnen OpenID Connect spezifischen Nachrichten, welche zwischen der Online-Applikation und dem Modul MOA-ID-Auth während eines Authentifizierungsvorgangs ausgetauscht werden. Hierbei wird auch auf das Sequenzdiagramm aus Abschnitt 3.1 Bezug genommen.
Der AuthCode Request ist die Authentifizierungsanfrage einer Online-Applikation für eine Benutzerin oder einen Benutzer. Folgende Parameter müssen mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| client_id | https://demo.egiz.gv.at/demoportal-openID_demo | Ist der eindeutige Identifikator für die Online-Applikation. Dieser MUSS mit dem Identifikator aus der Konfiguration identisch sein. |
| response_type | code | Rückgabewert des AuthCode Requests. Hinweis: Dieser Wert MUSS "code" sein. |
| redirect_uri | https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action | Die Callback-URI der Online-Applikation zu welcher die Callbacks der OAuth 2.0 Request gesendet werden. Dieser MUSS mit der Redirect URL aus der Konfiguration identisch sein. |
| state | 1425782214234 | Ein von der Online-Applikation generierter Wert welcher in beiden Requests (AuthCode und Token) gleich sein muss (ein CSRF Token) |
| scope | openID profile eID | Definiert welche Authentifizierungsinformationen an die Online-Applikation zurückgeliefert werden. Mögliche Werte sind: openId, profile, eID, eID_gov, mandate, stork wobei die Werte mittels Leerzeichen kombiniert werden können. Der Wert openID muss immer angegeben werden. Der Inhalt der einzelnen Profile, mit Ausnahme des Profiles openID, kann aus der Übersicht der möglichen Attribute entnommen werden.
|
Nachfolgend ein Beispiel für einen OpenID Connect Authentifizierungsrequest an das Modul MOA-ID-Auth.
<form method="get" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth3/auth"> <input type="hidden" value="code" name="response_type"> <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo" name="client_id"> <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action" name="redirect_uri"> <input type="hidden" value="profile eID eID_gov mandate" name="scope"> <input type="hidden" value="1152547590" name="state"> <input type="submit" value="OpenID Connect login"> </form>
Das Ergebnis des AuthCode Requests wird an die redirect_uri der Online-Applikation gesendet. Die nachfolgenden Parameter werden dabei übergeben.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| state | 1425782214234 | Der von der Online-Applikation generierte und im AuthCode Request übergebene CSRF Token. |
| code | 4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 | Ein vom Modul MOA-ID-Auth generierter Wert, welcher beim Abholen des AccessTokens (AccessToken Request) wieder an MOA-ID-Auth übergeben werden muss. |
Nachfolgend ein Beispiel für eine AuthCode Response.
https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action?state=1425782214234&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7
Mit dem AccessToken Request können vom Service Provider der Online-Applikation die Anmeldedaten an der MOA-ID-Auth Instanz abgeholt werden. Für die Abholung müssen folgende Parameter mit dem AccessToken Request an MOA-ID-Auth übertragen werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| grant_type | authorization_code | Dieser MUSS den Wert „authorization_code“ besitzen. |
| code | 4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 | Dieser Parameter wird in der AuthCode Response an die Online-Applikation (Service Provider) übertragen und muss in diesem Request wieder übermittelt werden. |
| redirect_uri | https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action | Die Callback-URI der Online-Applikation zu welcher die Callbacks der OAuth 2.0 Request gesendet werden. Dieser MUSS mit der Redirect URL aus der Konfiguration identisch sein. |
| client_id | https://demo.egiz.gv.at/demoportal-openID_demo | Ist der eindeutige Identifikator für die Online-Applikation. Dieser MUSS mit dem Identifikator aus der Konfiguration identisch sein. |
| client_secret | 0adf1ec7-c2a6-4fd3-897c-456d0fb7b5cc | Das Client Password der Online-Applikation. Dieses MUSS mit dem Client Password aus der Konfiguration identisch sein. |
Nachfolgend ein Beispiel für einen AccessToken Request
<form method="POST" action="https://demo.egiz.gv.at/demoportal_moaid-2.0/oauth3/token"> <input type="hidden" value="authorization_code" name="grant_type"> <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo" name="client_id"> <input type="hidden" value="https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action" name="redirect_uri"> <input type="hidden" value="0adf1ec7-c2a6-4fd3-897c-456d0fb7b5cc" name="client_secret"> <input type="hidden" value="4/P7q7W91a-oMsCeLvIaQm6bTrgtp7" name="code"> </form>
Die AccessToken Response beinhaltet ein signiertes JSON-Token welches alle angeforderten (Parameter scope im AuthCode Request) und vorhandenen Authentifizierungsdaten beinhaltet. Dieses JSON-Token ist mit einer JSON Web Signatur von MOA-ID-Auth signiert, wobei die Signatur alle angeforderten Daten einschließt. Details zur Konfiguration des Signatur Zertifikats finden Sie hier.
| Name | Beispielwert | Beschreibung |
|---|---|---|
| access_token | SlAV32hkKG | Ein AccessToken welches für eine anschließende Kommunikation mit MOA-ID-Auth verwendet werden kann. Hinweis: Diese Funktion wird jedoch aktuell nicht unterstützt. |
| token_type | Bearer | OpenID Connect spezifischer Parameter (Details entnehmen Sie bitte der OpenID Connect Spezifikation) |
| expires_in | 3600 | Gültigkeitszeitraum der Response |
| scope | openID profile eID | Die im AuthCode Request angeforderten Profile. |
| id_token | eyJhbGciOiJSU..... | Dieses Element beinhaltet die eigentlichen Authentifizierungsdaten und ist durch eine JSON Web Signatur signiert. |
Nachfolgend ein Beispiel für einen AccessToken Response
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "openid eID"
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh4LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}
Sollte während des Authentifizierungsvorgangs ein Fehler auftreten antwortet das Modul MOA-ID-Auth mit einer Error Response. Diese beinhaltet folgende Parameter
| Name | Beispielwert | Beschreibung |
|---|---|---|
| error | invalid_request_object | Fehlercode laut OpenID Connect Spezifikation |
| error_description | Der Request ist ungültig | Kurze textuelle Fehlerbeschreibung |
| error_uri | https://demo.egiz.gv.at/demoportal_moaid-2.0/moa_errorcodes.html#1000 | URL auf eine Seite mit zusätzlicher Fehlerbeschreibung |
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.
Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels SAML 1 und des Modules MOA-ID-Auth als Identity Provider. Hierbei wird die aus MOA-ID 1.5.1 bekannte Variante der Bürgerkartenauswahl beim Service Provider verwenden. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.
Zur Verwendung von SAML 1 stellt das Modul MOA-ID-Auth zwei Zugangspunkte zur Kommunikation mit der Online-Applikation (Service Provider) zur Verfügung. Diese Zugangspunkte bezeichnen die URLs unter welchen das Modul MOA-ID-Auth die entsprechenden SAML1 Nachrichten entgegennimmt.
MOA-ID-Auth wird immer durch eine andere (verweisende) Webseite aufgerufen. Diese Webseite kann z.B. Teil eines Portals sein. Der Aufruf erfolgt durch einen Verweis der Form, wobei die Parameter sowohl als http GET als auch als http POST an MOA-ID-Auth übergeben werden können.
<a href="https://<moa-id-server-und-pfad>/StartAuthentication ?Target=<geschäftsbereich> &OA=<oa-url> &bkuURI=<bku-url> &Template=<template-url> &useMandate=false &CCC=<ccc>">
| Name | Beispielwert | Beschreibung |
|---|---|---|
| <moa-id-server-und-pfad> | https://demo.egiz.gv.at/ demoportal_moaid-2.0/ |
Server und Pfad, wo MOA-ID-AUTH installiert ist |
| Target=<geschäftsbereich> | BF | Angabe, für welches Verfahren (öffentlicher Bereich) der Benutzer authentisiert werden soll. Dieser Parameter wird jedoch durch den in entsprechenden Parameter in der online-applikationsspezifischen Konfiguration überschrieben. |
| OA=<oa-url> | https://demo.egiz.gv.at/demoportal-demologin/securearea.action | Webseite, auf die der Browser nach erfolgter Authentisierung weitergeleitet werden soll |
| 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. 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ü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). |
| useMandate=<true/false> | true / false | Optional: Gibt an ob eine Anmeldung im Online-Vollmachten-Modus durchgeführt werden soll (=true) oder nicht (=false); |
| 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. |
| sourceID=<xxxxxxx> | abcdef141245 | Optional: Die sourceID fließt in die Generierung des SAML1 Artifacts, welches an den Service Provider returniert wird, ein. Detailinformationen zur Generierung des SAML1 Artifacts und zur sourceID finden Sie in der SAML1 Spezifikation. |
Nach erfolgter Authentisierung stehen in MOA-ID-AUTH Anmeldedaten zum Abholen bereit, und MOA-ID-AUTH veranlasst einen Redirect zur Online-Applikation (OA).
In diesem Redirect werden der Geschäftsbereich und ein SAML-Artifact als Parameter übergeben.
<a href="https://<oa-url>?Target=<geschäftsbereich>&SAMLArtifact=<saml-artifact>">
| oa-url> | URL, der beim Aufruf von MOA-ID-AUTH als Parameter "OA" übergeben wurde |
| Target=<geschäftsbereich> | Parameter, der beim Aufruf von MOA-ID-AUTH übergeben wurde |
| SAMLArtifact=<saml-artifact> | SAML-Artifact, das von MOA-ID-AUTH zu den Anmeldedaten erstellt wurde. Mithilfe dieses SAML-Artifacts kann die OA die Anmeldedaten von MOA-ID-AUTH abholen. |
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.
Sollte während des Anmeldevorgangs ein Fehler aufgetreten sein, antwortet 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.
| Spezifikation | Link |
|---|---|
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 |
| OpenID Connect | http://openid.net/connect/ |
| STORK 2 | @TODO Link |
| Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 | http://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.0 | http://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.1 | https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf |