From b0b70fbb35a06c947371121c7e753090ebe06827 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Wed, 5 Mar 2014 19:10:28 +0100 Subject: finalize moa-id handbook for 2.0 RC1 --- id/server/doc/handbook/protocol/Assertion.xml | 14 +- id/server/doc/handbook/protocol/AuthRequest.xml | 8 +- id/server/doc/handbook/protocol/protocol.html | 569 ++++++++++++++++++--- id/server/doc/handbook/protocol/pvp21_sequence.png | Bin 0 -> 38601 bytes id/server/doc/handbook/protocol/saml1_sequence.png | Bin 0 -> 32752 bytes id/server/doc/handbook/protocol/sso_sequence.png | Bin 0 -> 56152 bytes 6 files changed, 502 insertions(+), 89 deletions(-) create mode 100644 id/server/doc/handbook/protocol/pvp21_sequence.png create mode 100644 id/server/doc/handbook/protocol/saml1_sequence.png create mode 100644 id/server/doc/handbook/protocol/sso_sequence.png (limited to 'id/server/doc/handbook/protocol') diff --git a/id/server/doc/handbook/protocol/Assertion.xml b/id/server/doc/handbook/protocol/Assertion.xml index 6be5c7384..b6db5f088 100644 --- a/id/server/doc/handbook/protocol/Assertion.xml +++ b/id/server/doc/handbook/protocol/Assertion.xml @@ -1,5 +1,5 @@ - + https://demo.egiz.gv.at/demoportal_moaid-2.0 @@ -13,10 +13,10 @@ - kvUKbjEOo7lVsclpkgHFkkbJ5bErwG/bu6KzGoJzLZs= + fCE31ZeXZybQLOuNQBePLjFrCtKdvCmeyJ1tUW/ghtA= - bNS+LN4YNeqKR05F+Y9YbRkPEJ87rhEK+Prk3pEnMBZT8VKWwP/ki4TdrupkFX3YjJvINXk2NFJxcB5GEbHxJjnpF8+K4gH2cPRyzDdS72mlO70mKg9Aa2chP/35c9kyGaHfzrw7Y4MzKjrkXfl76ekdL8UzHFYVFE4oUwtJXvrsg78RZNcy4aCuUvzsJbYwfriAjT7Cp93F5aum6oJ6kXk8XSHmh+yVzFSzYL+WkbIV+x7OOXVnoAWSY5d3tPGlr2LhjTf53q0pn+cggJ6jPfAVmwuxJTwe2C7xPlkylsQkswORMwXovGr+KqrcOpimxgeukvlJD+7YUHsi8uJMvg== + vUFR3YPk5wiBJnrLh6Er7V46FNDMuB5Jcu73Rw7tipgr+bnV0reRNcZ5TGT+VMjNhtKJMcqgjrQWJ6tACe1r0mzhpRSVQkw7yFkTvIhQHX1a08yqJ4yy3qiN13ctDo4VgP9qHUim7b797oOKNhRXFk+2GJA5hRcpRliUjhBlzTYrxpkY5NcYDRhDPlvMx+l11oa1iDGuAylN+ty4h3P4fIoIgL9Tz1m3l65LqkV5RBc6avSeHw9OASMigPsjd5b0IBvhvJ611xLgzC1BOtJshiw1k/p8alv8TaUmYZ/kJbRN1tuTBL129edbS0Rz0faT0tniF42QHteJ214brK3rCg== @@ -33,20 +33,20 @@ nibdIyU5+AmfFzDaMwNocJEANoXrjLTpduCHvT0Qt/wH+7rVdgjX1djMrBhyMWs7GQyIBRfuf58m - + https://demo.egiz.gv.at/demoportal_moaid-2.0 QVGm48cqcM4UcyhDTNGYmVdrIoY= - + - + https://demo.egiz.gv.at/demoportal_demologin/ - + http://www.stork.gov.eu/1.0/citizenQAALevel/4 diff --git a/id/server/doc/handbook/protocol/AuthRequest.xml b/id/server/doc/handbook/protocol/AuthRequest.xml index 9a5c5f481..f9de11c4c 100644 --- a/id/server/doc/handbook/protocol/AuthRequest.xml +++ b/id/server/doc/handbook/protocol/AuthRequest.xml @@ -1,20 +1,20 @@ - + https://demo.egiz.gv.at/demoportal_demologin/ - + - 6azvvz1bk4wlcEoCEq3DgwYE/FU= + sBVJQf9b+QIxRfH8YuTbF6hBrf4= - J+en/LY0okRfEW9KEX4sj6TydwHFrtY4PbS1wDvdpAr9v6qY4+PvKHIhfTY/D/DBMJq/bVMJj+y+LgXzyHbLitqEvJkgYeFBrfFLu/6I7zuqucHbip4YAd63Vrg6f5buxrY0S4uJniRGtEhkZDcGJ0Y9Bu3obWXMk7oK/tHtsrvejd27bQOzdZv1ESWiBorlTVPzkfvS13jNsIyeWOuQ/Zv0FKn9RenqvbIVWnG3xKiSEcKT4VaosDdvZX35wxEYh3Rk84ZySDdp502vCvpOjSkc64s6ZiqZcmwwpSNb3+uMwvUNF+gH7mAYs1FXit9/UaGyL30qXgEc+TUZd2o/iA== + JK68H5XqmD2OEA8O/UCZFenVj0TrvauPhaKJt73pbHbi//hO1hBcRQbV2Qg3gQ11EcJ9Q+TM3TCe9nT6tdU/z7ry3qdZvlOfrkMF13fY4HOIuvB9AcySdxq2yKA3V5O9sLhf5S9qCyx9lMnTARC7wkVs4j2Pv00R6P/iROOHD5ryGF2J0FdtMp9VqhvQJ9yRGM2lTduF98MqxWA2EMk6AMo7qij0Bvha1B2OyFSU9HM3fyfRQpXDeiLnKHcjLpzu5TDNkKrP75c7vv85DDr7s2I0p74nAOVLMuLau5tEQ91Crk9QoqoqqEecKWcNJDXTO9MahCQw77hUDL1WOEMFFg== diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index f75888f22..450df0aad 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -2,7 +2,7 @@ - MOA-ID - Einführung + MOA-ID - Protokolle @@ -17,23 +17,61 @@

MOA-ID (Identifikation)

Protokolle

-

Inhalt

+

Inhalt

    -
  1. Allgemeines
    2. -
  2. PVP 2.1
    3. -
  3. OpenID Connect
    4. -
  4. SAML 1
    5. -
-
    +
  1. Allgemeines +
      +
    1. Übersicht der Zugangspunkte
      2. +
    2. Übersicht der möglichen Attribute
      3. +
    3. Single Sign-On
      4. +
    4. SSO Logout
      5. +
    5. Legacy Request (Bürgerkartenauswahl beim Service Provider)
      6. +
    +
    2. +
  2. PVP 2.1 +
      +
    1. Ablauf einer Anmeldung mittels PVP 2.1
      2. +
    2. Metadaten
      3. +
    3. Zugangspunkte +
        +
      1. Authentifizierungsrequest
        2. +
      2. Authentifizierungsrespon
        3. +
      +
      4. +
    +
    3. +
  3. OpenID Connect +
      +
    1. Ablauf einer Anmeldung mittels OpenID Connect
      2. +
    2. Zugangspunkte
      3. +
    3. Beschreibung der Nachrichten +
        +
      1. AuthCode Request
        2. +
      2. AuthCode Response
        3. +
      3. AccessToken Request
        4. +
      4. AccessToken Response
        5. +
      +
      4. +
    +
    4. +
  4. SAML 1 +
      +
    1. Ablauf einer Anmeldung mittels SAML 1
      2. +
    2. Zugangspunkte
      3. +
    3. StartAuthentication Request
      4. +
    4. GetAuthenticationData Request
      5. +
    +
    5. +
  5. Referenzierte Spezifikation
    6. -
+

1 Allgemeines

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.

-

1.1 Übersicht der Zugangspunkte

-

In diesem Abschnitt sind die Zugangspunkte der vom Modul MOA-ID-Auth unterstützten Protokolle kurz zusammengefasst. Eine detailierte Beschreibung der einzelnen Protokolle finden Sie in den anschließenden Unterkapiteln.

+

1.1 Übersicht der Zugangspunkte

+

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.

@@ -79,57 +117,64 @@ Redirect Binding + + + + +
Protokoll

https://<host>:<port>/moa-id-auth/services/GetAuthenticationData

http://<host>:<port>/moa-id-auth/services/GetAuthenticationData
SSO LogoutLogOut

https://<host>:<port>/moa-id-auth/LogOut

+

http://<host>:<port>/moa-id-auth/LogOut

1.2 Übersicht der möglichen Attribute

-

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.

- +

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.

+
- + - + - + - + - + +

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.

- + - + - + - + @@ -157,21 +202,23 @@ Redirect Binding - + - + - + @@ -179,7 +226,7 @@ Redirect Binding - + @@ -187,7 +234,9 @@ Redirect Binding - + @@ -195,98 +244,98 @@ Redirect Binding - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -301,7 +350,8 @@ Redirect Binding inheritedFamilyName - + @@ -310,7 +360,8 @@ Redirect Binding adoptedFamilyName - + @@ -319,7 +370,8 @@ Redirect Binding gender - + @@ -328,7 +380,8 @@ Redirect Binding countryCodeOfBirth - + @@ -337,7 +390,8 @@ Redirect Binding nationalityCode - + @@ -346,7 +400,8 @@ Redirect Binding maritalStatus - + @@ -355,7 +410,8 @@ Redirect Binding textResidenceAddress - + @@ -364,7 +420,8 @@ Redirect Binding canonicalResidenceAddress - + @@ -373,7 +430,8 @@ Redirect Binding title - + @@ -382,7 +440,8 @@ Redirect Binding residencePermit - + @@ -391,7 +450,8 @@ Redirect Binding pseudonym - + @@ -400,7 +460,8 @@ Redirect Binding age - + @@ -409,7 +470,8 @@ Redirect Binding isAgeOver - + @@ -418,19 +480,128 @@ Redirect Binding fiscalNumber - +
ProtokolleBeschreibungBeschreibung
PVP 2.1PVP 2.1 OpenID ConnectSAML 1SAML 1
NameName 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 ist bPK-value := (BEREICH ":" bPK) 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.62 EID-AUTH-BLOCK eID 

/saml:Assertion/saml:AttributeStatement/

+

saml:Subject/saml:SubjectConfirmation/

+

saml:SubjectConfirmationData

 Base64 kodierte Signatur die während des Authentifizierungsdaten 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.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. Vertretungsbe-fugnisse 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äß zugrundelie-gendem 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.
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.
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.
gender stork http://www.stork.gov.eu/1.0/
+ gender

Geschlecht

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
countryCodeOfBirth stork http://www.stork.gov.eu/1.0/
+ countryCodeOfBirth

Geburtsland

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
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.
maritalStatus stork http://www.stork.gov.eu/1.0/
+ maritalStatus

Familienstand

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
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.
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.
title stork http://www.stork.gov.eu/1.0/
+ title

Titel

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
residencePermit stork http://www.stork.gov.eu/1.0/
+ residencePermit

Aufenthaltsbewilligung

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
pseudonym stork http://www.stork.gov.eu/1.0/
+ pseudonym

Pseudonym

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
age stork http://www.stork.gov.eu/1.0/
+ age

Alter

Hinweis: Dieses Attribut steht nur bei einer Anmeldung mittels STORK zur Verfügung.
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.
fiscalNumber stork http://www.stork.gov.eu/1.0/
+ fiscalNumber

Steuernummer

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

 

- +

1.3 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

+
    +
  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. Der Service Provider 1 generiert einen Authentifizierungsrequest und sendet diesen über den Browser an das Modul MOA-ID-Auth.
    3. +
  3. 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. +
    +
    4. +
  4. 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.
    5. +
  5. 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.
    6. +
  6. Die Assertion (ohne SSO Token!) wird an den Service Provider 1 weitergeleitet.
    7. +
  7. Ist die Validierung der Assertion erfolgreich wird die BenutzerIn oder der Benutzer an der Online-Applikation 1 angemeldet.
    8. +
  8. 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.
    9. +
  9. Der Service Provider 2 generiert einen Authentifizierungsrequest und sendet diesen über den Browser.
    10. +
  10. Der Browser sendet den Authentifizierungsrequest und das gespeicherte SSO Token an das Modul MOA-ID-Auth.
    11. +
  11. 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.
    12. +
  12. 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.
    13. +
  13. 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.
    14. +
  14. Soll der Anmeldevorgang vorgesetzt werden generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers für die Online-Applikation 2.
    15. +
  15. 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.
    16. +
  16. Die Assertion (ohne SSO Token!) wird an den Service Provider 2 weitergeleitet.
    17. +
  17. Ist die Validierung der Assertion erfolgreich wird die BenutzerIn oder der Benutzer an der Online-Applikation 2 angemeldet
    18. +
+

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

+

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

bzw.

+
+https://<host>:<port>/moa-id-auth/LogOut
+
+ + + + + + + + + + + +
NameBeispielwertBeschreibung
redirecthttps://demo.egiz.gv.at/demoportal-openID_demoNach 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.

+

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameBeispielwertBeschreibung
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.

+

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.htmlOptional: 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).
+ 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 / falseOptional: 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.
+

 

+

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.

2 PVP 2.1

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.

2.1 Ablauf einer Anmeldung mittels PVP 2.1

-

Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels PVP 2.1 und des Modules MOA-ID-Auth als Identityprovider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.

-

 

+

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.

+

Sequenzdiagramm PVP 2.1

+
    +
  1. Der Benutzer verbindet sich zu einem Web-Portal (Service Provider) über das die Online-Applikation erreichbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang ausgelöst.
    2. +
  2. Der Service Provider holt die Metadaten des Identity Providers am Modul MOA-ID-Auth ab und validiert die Signatur der Metadaten mit dem am Service Provider hinterlegten Zertifikat. Ist die Validierung erfolgt wird der Anmeldevorgang fortgesetzt.
    3. +
  3. Der Service Provider extrahiert Informationen aus den Metadaten und generiert einen Authentifizierungsrequest und sendet diesen über den Browser an das Modul MOA-ID-Auth.
    4. +
  4. 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.
    5. +
  5. MOA-ID-Auth validiert den Authentifizierungsrequest mit den Informationen aus dem Metadaten des Service Providers. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
    6. +
  6. 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. +
    +
    7. +
  7. War die Authentifizierung der BenutzerIn oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers.
    8. +
  8. MOA-ID-Auth senden die Assertion über den Browser an den Service Provider.
    9. +
  9. 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. +
    +
    10. +

2.2 Metadaten

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
@@ -447,7 +618,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
   
  • Die Metadaten müssen mindestens ein XML Element
    
 md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:AssertionConsumerService enthalten welches das gewünschte Binding und die URL zur Auslieferung der Assertion beinhaltet. 
    • 
   
  • Werden zusätzlich zum bereichsspezifischen Personenkennzeichen (bPK / wbPK) weitere Attribute durch den Service Provider benötigt müssen diese über die Metadaten angefordert werden. 
    
-  Hierfür steht das Element md:EntitiesDescriptor/md:EntityDescriptormd:SPSSODescriptor/md:AttributeConsumingService zur Verfügung wobie die als Kindelemente  md:RequestedAttribute die einzelnen benötigten Attribute definieren (siehe Beispiel).
    • 
+  Hierfür steht das Element 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.
    
@@ -467,23 +638,152 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
 
    Folgende Minimalanforderungen an den Authentifizierungsrequest müssen erfüllt sein.
    
 
      
   
    • Der Request muss durch den Service Provider signiert sein (sie Beispiel). Die Signatur wird durch das Modul MOA-ID-Auth mit Hilfe des in den Metadaten hinterlegten Zertifikats validiert. Schlägt die Signaturprüfung fehl oder ist keine Signatur vorhanden wird der Request abgewiesen und MOA-ID-Auth antwortet mit http Code 400 und der Fehlermeldung NO valid protocol request received!.
      • 
-  
    • Das der Wert des XML Element saml2p:AuthnRequest/saml2:Issuer muss den eindeutigen Identifier enthalten der für diese Online-Applikation bei MOA-ID-Auth hinterlegt ist (sie Beispiel).
      • 
+  
    • 
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    
      Namesaml2p:AuthnRequest/saml2:Issuer
       GebrauchEin Mal
      Erläuterung
      Der Wert dieses Elements muss den eindeutigen Identifier enthalten der für diese Online-Applikation bei MOA-ID-Auth hinterlegt ist (sie Beispiel).
      
+  
      • 
+  
    • 
+    
+      
+        
+        
+      
+      
+        
+        
+      
+      
+        
+        
+      
+    
      Name/saml2p:AuthnRequest/@ID
       GebrauchEin 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.
    
 
    2.3.2 Authentifizierungsresponse
    
-
    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). 
    
+
    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.
    
+
      
+  
    • POST Binding: In diesem Fall erfolgt die Übertragung mittels eines http POST Formulars welches aus dem Browser der BenutzerIn oder des Benutzers an den Service Provider gesendet wird..
      • 
+
    
+
      
+  
    • Redirect Binding: In diesem Fall erfolgt die Übertragung mittels eines Redirects wobei die Daten als GET Parameter in der URL enthalten sind.
      • 
+
    
+
    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.
    
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
    Name/saml2p:Response/ds:Signature
     GebrauchEin 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
     GebrauchEin Mal
    Erläuterung
    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: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.
      • 
+    
    
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
    Name/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID
     GebrauchEin Mal
    Erläuterung
    Dieses Element beinhaltet das bereichsspezifischen Personenkennzeichen (bPK / wbPK) der authentifizierten Person.
    
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
    Name/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:NameID/@NameQualifier
     GebrauchEin Mal
    Erläuterung
    Dieses Attribut beinhaltet den Bereich des bereichsspezifikschen Personkennzeichens (bPK / wbPK)
    
+
+  
+    
+    
+  
+  
+    
+    
+  
+  
+    
+    
+  
+
    Name/saml2p:Response/saml2:Assertion/saml2:Subject/saml2:SubjectConfirmation/saml2:SubjectConfirmationData/@InResponseTo
     GebrauchEin 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
     GebrauchEin 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.
    
 
    3 OpenID Connect 
    
-
    OpenID Connect ist ein Authentifizierungsprotkoll 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 Protkollen (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. TODO!
    
+
    OpenID Connect ist ein Authentifizierungsprotkoll 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 Protkolls OpenID Connect in Kombination mit dem Modul MOA-ID-Auth. Detailinformationen zu OpenID Connect entnehmen Sie bitte der aktuellen OpenID Connect Spezifikation
    
 
 
    3.1 Ablauf einer Anmeldung mittels OpenID Connect
    
-
    Die nachfolgende Abbildung zeigt das Sequenzdiagramm eines Anmeldevorgangs mittels OpenID Connect und des Modules MOA-ID-Auth als Identityprovider. Aus Gründen der Übersichtlichkeit wurden die Teile welche die Kommunikation mit der Bürgerkartenumgebung oder die Vollmachten-Auswahl betreffen bewusst nicht berücksichtigt.
    
+
    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.
    
 
 
    Sequenzdiagramm OpenID Connect
    
 
      
-  
    1. Der Benutzer verbindet sich zu einem Web-Portal (Service Provider) über das die Online-Applikation erreichtbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang ausgelöst.
      2. 
+  
    2. Der Benutzer verbindet sich zu einem Web-Portal (Service Provider) über das die Online-Applikation erreichbar ist. Nach der Betätigung eines Login-Buttons wird der Anmeldevorgang ausgelöst.
      3. 
   
    3. Der Service Provider generiert den AuchCode Request und sendet diesen über den Browser an das Modul MOA-ID-Auth.
      4. 
   
    4. MOA-ID-Auth validiert den AuthCode Request.
      5. 
   
    5. MOA-ID-Auth leitet die BenutzerIn oder den Benutzer zur Bürgerkartenauswahl
@@ -492,7 +792,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
     
    
   
   
  • Nach erfolgreicher Authentifizierung erzeugt MOA-ID-Auth die AuthCode Response.
-
      
+    
        
       
      1. Die AuthCode Response wird mittels Redirect an den Service Provider retourniert.
        2. 
     
      
   
@@ -500,7 +800,7 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
   
    1. Der Service Provider generiert den AccessToken Request und sendet diesen an MOA-ID-Auth zum Abholen der Benutzerdaten.
      2. 
   
    2. MOA-ID-Auth validiert den AccessToken Request
      3. 
   
    3. MOA-ID-Auth generiert die AccessToken Response
-
        
+    
          
       
        1. Retournierung der AccessToken Response an den Service Provider
          2. 
     
        
   
@@ -513,10 +813,9 @@ https://<host>:<port>/moa-id-auth/pvp2/metadata
 
        3.2 Zugangspunkte
        
 
        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.
        
 
          
-
        • AuthCode-Request: https://<host>:<port>/moa-id-auth/oauth2/auth
           Unter dieser URL wird der Authn Request entgegengenommen. Dieser Request startet den Authentifizierungsvorgang an der Online-Applikation. Hier finden Sie Detailinformationen zum  Request und zur Response.
          • 
-
        • AccessToken-Request: https://<host>:<port>/moa-id-auth/oauth2/token
           Unter dieser URL können nach erfolgreicher Authentifizierung die eigentlichen Authentifizierungsdaten am Modul MOA-ID-Auth abgeholt werden. Hier finden Sie Detailinformationen zum  Request und zur Response.
          • 
+  
        • AuthCode-Request: https://<host>:<port>/moa-id-auth/oauth2/auth
           Unter dieser URL wird der Authn Request entgegengenommen. Dieser Request startet den Authentifizierungsvorgang an der Online-Applikation. Hier finden Sie Detailinformationen zum  Request und zur Response.
          • 
+  
        • AccessToken-Request: https://<host>:<port>/moa-id-auth/oauth2/token
           Unter dieser URL können nach erfolgreicher Authentifizierung die eigentlichen Authentifizierungsdaten am Modul MOA-ID-Auth abgeholt werden. Hier finden Sie Detailinformationen zum  Request und zur Response.
          • 
 
        
-
 
        3.3 Beschreibung der Nachrichten
        
 
        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.
        
 
@@ -532,7 +831,7 @@ Folgende Parameter m
   
     client_id
     https://demo.egiz.gv.at/demoportal-openID_demo
-    Ist der eindeutige Identifikatior für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
+    Ist der eindeutige Identifikator für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
   
   
     response_type
@@ -598,7 +897,7 @@ Folgende Parameter m
   
 
 
         
        
-
        Nochfolgend ein Beispiel für eine AuthCode Response.
        
+
        Nachfolgend ein Beispiel für eine AuthCode Response.
        
 
        https://demo.egiz.gv.at/demoportal-openID_demo/securearea.action?state=1425782214234&code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7 
        
 
        3.2.3 AccessToken Request
        
 
        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.
        
@@ -626,7 +925,7 @@ Folgende Parameter m
   
     client_id
     https://demo.egiz.gv.at/demoportal-openID_demo
-    Ist der eindeutige Identifikatior für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
+    Ist der eindeutige Identifikator für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
   
   
     client_secret
@@ -669,7 +968,7 @@ Folgende Parameter m
   
     expires_in
     3600
-    Gültigkeitszeitraum der Response (TODO)
+    Gültigkeitszeitraum der Response
   
   
     scope
@@ -701,8 +1000,122 @@ Folgende Parameter m
                XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
 }
    • -

    3 SAML 1

    - +

    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.

    +

    3.1 Ablauf einer Anmeldung mittels SAML 1

    +

    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.

    +

    Sequenzdiagramm für SAML 1

    +
      +
    1. Der Benutzer verbindet sich zu einem Web-Portal (Service Provider) über das die Online-Applikation erreichbar ist.
      2. +
    2. Der Service Provider antwortet mit einer öffentlichen Portalseite welche einen Login Bereich mit Bürgerkartenauswahl beinhaltet.
      3. +
    3. Nach Auswahl der gewünschten Authentifizierungsmethode (Bürgerkarte oder Handy-Signatur) wird der Anmeldevorgang ausgelöst und der StartAuthentication Request wird an das Modul MOA-ID-Auth gesendet.
      4. +
    4. MOA-ID-Auth validiert den StartAuthentication Request. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
      5. +
    5. Die BenutzerIn oder der Benutzer wird zur gewählten Bürgerkartenumgebung weitergeleitet. +
        +
      1. Die BenutzerIn oder der Benutzer Authentifiziert sich mit der gewählten Methode.
        2. +
      +
      6. +
    6. War die Authentifizierung der BenutzerIn oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers.
      7. +
    7. MOA-ID-Auth senden das SAML 1 Artifact, welches zur Abholung der Assertion verwendet werden kann, über den Browser an den Service Provider.
      8. +
    8. Der Service Provider stellt einen GetAuthenticationData Request an MOA-ID-Auth unter Verwendung des zuvor übermittelten Artifacts.
      9. +
    9. MOA-ID-Auth validiert das Artifact. Ist die Validierung erfolgreich antwortet MOA-ID-Auth mit der SAML 1 Assertion, welche die Anmeldedaten beinhaltet.
      10. +
    10. Der Service Provider verarbeitet die Assertion und danach ist der Benutzer an der Online-Applikation angemeldet.
      11. +
    +

    3.2 Zugangspunkte

    +

    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.

    +
      +
    • StartAuthentication Request: https://<host>:<port>/moa-id-auth/StartAuthentication
      + Unter dieser URL wird der Authn Request entgegengenommen. Dieser Request startet den Authentifizierungsvorgang an der Online-Applikation.
      • +
    • GetAuthenticationData: http(s)://<host>:<port>/moa-id-auth/services/GetAuthenticationData
      + Unter dieser URL können nach erfolgreicher Authentifizierung die eigentlichen Authentifizierungsdaten am Modul MOA-ID-Auth abgeholt werden.
      • +
    +

    3.3 StartAuthentication Request

    +

    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>">
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    <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.actionWebseite, 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.htmlOptional: 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 / falseOptional: 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.
    +

    3.4 GetAuthenticationData Request

    +

    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.

    + +

    Der detaillierte Aufbau der <saml:Assertion> zu den Anmeldedaten ist in der Spezifikation MOA-ID 1.4 beschrieben.

    A Referenzierte Spezifikation

    diff --git a/id/server/doc/handbook/protocol/pvp21_sequence.png b/id/server/doc/handbook/protocol/pvp21_sequence.png new file mode 100644 index 000000000..c915531cc Binary files /dev/null and b/id/server/doc/handbook/protocol/pvp21_sequence.png differ diff --git a/id/server/doc/handbook/protocol/saml1_sequence.png b/id/server/doc/handbook/protocol/saml1_sequence.png new file mode 100644 index 000000000..e863d74c1 Binary files /dev/null and b/id/server/doc/handbook/protocol/saml1_sequence.png differ diff --git a/id/server/doc/handbook/protocol/sso_sequence.png b/id/server/doc/handbook/protocol/sso_sequence.png new file mode 100644 index 000000000..19e50100d Binary files /dev/null and b/id/server/doc/handbook/protocol/sso_sequence.png differ -- cgit v1.2.3