From 8b8e4c9c3c9ff5e3855be8b177b58387ee6b625c Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Mon, 3 Mar 2014 07:05:02 +0100 Subject: Handbook: add protocol chapter --- id/server/doc/handbook/protocol/protocol.html | 114 ++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 id/server/doc/handbook/protocol/protocol.html (limited to 'id/server/doc/handbook/protocol/protocol.html') diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html new file mode 100644 index 000000000..bd6893af0 --- /dev/null +++ b/id/server/doc/handbook/protocol/protocol.html @@ -0,0 +1,114 @@ + + + + + MOA-ID - Einführung + + + + + + + + + +
Logo BKADokumentationLogo EGIZ
+
+

MOA-ID (Identifikation)

+

Protokolle

+
+

Inhalt

+
    +
  1. Allgemeines
    2. +
  2. PVP 2.1
    3. +
  3. OpenID Connect
    4. +
  4. SAML 1
    5. +
+
    +
  1. Referenzierte Spezifikation
    2. +
+
+

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.

+ +

2 PVP 2.1

+ + +

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!

+

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.

+ +

TODO:

+ +

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.

+ + +

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.

+ +

3.2.1 AuthCode Request

+

Der AuthCode Request ist die Authentifizierungsanfrage einer Online-Applikation für eine BenutzerIn oder einen Benutzer. +Folgende Parameter müssen oder können mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

+ + +

3.2.2 AuthCode Response

+ +

3.2.3 AccessToken Request

+ +

3.2.4 AccessToken Response

+ + + +

 

+ +

3 SAML 1

+ +

A Referenzierte Spezifikation

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

Security Layer Spezifikation V1.2.0

http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20140114/
PVP 2.1 S-Profil Spezifikationhttp://reference.e-government.gv.at/uploads/media/PVP2-S-Profil_2_0_0_a-2011-08-31.pdf
OpenID Connecthttp://openid.net/connect/
STORK 2@TODO Link
Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V1.1https://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf
+ + -- cgit v1.2.3 From 05fbf84d2f1af1e9920b4bde23ae3a730cf96b35 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Tue, 4 Mar 2014 15:56:59 +0100 Subject: Handbook protocoll update --- id/server/doc/handbook/protocol/protocol.html | 650 +++++++++++++++++++++++++- 1 file changed, 640 insertions(+), 10 deletions(-) (limited to 'id/server/doc/handbook/protocol/protocol.html') diff --git a/id/server/doc/handbook/protocol/protocol.html b/id/server/doc/handbook/protocol/protocol.html index bd6893af0..f75888f22 100644 --- a/id/server/doc/handbook/protocol/protocol.html +++ b/id/server/doc/handbook/protocol/protocol.html @@ -32,10 +32,447 @@

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ProtokollRequesttypURL
PVP 2.1Metadatenhttps://<host>:<port>/moa-id-auth/pvp2/metadata

PVP 2.1

Authentifizierungsrequest
+ POST Binding		https://<host>:<port>/moa-id-auth/pvp2/post

PVP 2.1

Authentifizierungsrequest
+Redirect Binding		https://<host>:<port>/moa-id-auth/pvp2/redirect
OpenID ConnectAuthentifizierungsrequest
+ (AuthCode-Request)		https://<host>:<port>/moa-id-auth/oauth2/auth
OpenID Connect

AccessToken-Request

https://<host>:<port>/moa-id-auth/oauth2/token
SAML 1Authentifizierungsrequest

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

+

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ProtokolleBeschreibung
PVP 2.1OpenID ConnectSAML 1
NameProfil
urn:oid:1.2.40.0.10.2.1.1.149BPKeID 

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

urn:oid:1.2.40.0.10.2.1.1.261.20

family_nameprofile Familienname
urn:oid:1.2.40.0.10.2.1.1.55birthdateprofile Geburtsdatum im Format JJJJ-MM-TT
urn:oid:1.2.40.0.10.2.1.1.261.64EID-CCS-URLeID 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.94EID-CITIZEN-QAA-LEVELeID Authentifizierungslevel des Bürgers
urn:oid:1.2.40.0.10.2.1.1.261.32EID-ISSUING-NATIONeID Landescode gem. ISO-3166 ALPHA-2
urn:oid:1.2.40.0.10.2.1.1.261.34EID-SECTOR-FOR-IDENTIFIEReID Bereich für den die bPK / wbPK berechnet wurde.
urn:oid:1.2.40.0.10.2.1.1.261.62EID-AUTH-BLOCKeID Base64 kodierte Signatur die während des Authentifizierungsdaten vom Benutzer erzeugt wurde.
urn:oid:1.2.40.0.10.2.1.1.261.66EID-SIGNER-CERTIFICATEeID Base64 kodiertes Zertifikat, dass für die Anmeldung verwendet wurde.
urn:oid:1.2.40.0.10.2.1.1.261.36EID-SOURCE-PINeID_gov 

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.104EID-SOURCE-PIN-TYPEeID_gov 

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.38EID-IDENTITY-LINKeID_gov 

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.68MANDATE-TYPEmandate Bezeichnung des verwendeten Vollmachten-Profils.
urn:oid:1.2.40.0.10.2.1.1.261.102MANDATOR-NATURAL-PERSON-SOURCE-PIN-TYPEmandate 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.70MANDATOR-NATURAL-PERSON-SOURCE-PINmandate 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.76MANDATOR-LEGAL-PERSON-SOURCE-PIN-TYPEmandate 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.100MANDATOR-LEGAL-PERSON-SOURCE-PINmandate 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.98MANDATOR-NATURAL-PERSON-BPKmandate Bereichsspezifisches Personenkennzeichen des Vollmachtgebers
urn:oid:1.2.40.0.10.2.1.1.261.78MANDATOR-NATURAL-PERSON-GIVEN-NAMEmandate 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.80MANDATOR-NATURAL-PERSON-FAMILY-NAMEmandate Nachname der Person, die die Vollmacht erteilt hat, bzw. die vertreten wird.
urn:oid:1.2.40.0.10.2.1.1.261.82MANDATOR-NATURAL-PERSON-BIRTHDATEmandate 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.84MANDATOR-LEGAL-PERSON-FULL-NAMEmandate Name der juristischen Person bzw. Personenmehrheit gemäß zugrundelie-gendem Register.
urn:oid:1.2.40.0.10.2.1.1.261.86MANDATE-PROF-REP-OIDmandate Object Identifiern (OID) zur Kennzeichnung von berufsmäßigen ParteienvertreterInnen bzw. OrganwalterInnen.
urn:oid:1.2.40.0.10.2.1.1.261.88MANDATE-PROF-REP-DESCRIPTIONmandate Textuelle Beschreibung der Eigenschaft als berufsmäßiger ParteienvertreterIn.
urn:oid:1.2.40.0.10.2.1.1.261.90MANDATE-REFERENCE-VALUEmandate Die im Rahmen einer elektronischen Vollmachtserstellung generierte Transaktionsnummer.
urn:oid:1.2.40.0.10.2.1.1.261.92MANDATE-FULL-MANDATEmandate Base64 kodierte Vollmacht im XML Format gemäß Vollmachten-Spezifikation.
urn:oid:1.2.40.0.10.2.1.1.261.96EID-STORK-TOKENstork Beinhaltet die komplette Response Message eines STORK Providers im Base64-Format.
http://www.stork.gov.eu/1.0/
+ inheritedFamilyName		inheritedFamilyNamestork 

Vererbter Familienname

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

Angenommener Familienname

+

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

http://www.stork.gov.eu/1.0/
+ gender		genderstork 

Geschlecht

+

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

http://www.stork.gov.eu/1.0/
+ countryCodeOfBirth		countryCodeOfBirthstork 

Geburtsland

+

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

http://www.stork.gov.eu/1.0/
+ nationalityCode		nationalityCodestork 

Nationalität

+

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

http://www.stork.gov.eu/1.0/
+ maritalStatus		maritalStatusstork 

Familienstand

+

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

http://www.stork.gov.eu/1.0/
+ textResidenceAddress		textResidenceAddressstork 

Wohnadresse in Textform

+

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

http://www.stork.gov.eu/1.0/
+ canonicalResidenceAddress		canonicalResidenceAddressstork 

Anerkannte Wohnadresse

+

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

http://www.stork.gov.eu/1.0/
+ title		titlestork 

Titel

+

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

http://www.stork.gov.eu/1.0/
+ residencePermit		residencePermitstork 

Aufenthaltsbewilligung

+

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

http://www.stork.gov.eu/1.0/
+ pseudonym		pseudonymstork 

Pseudonym

+

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

http://www.stork.gov.eu/1.0/
+ age		agestork 

Alter

+

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

http://www.stork.gov.eu/1.0/
+ isAgeOver		isAgeOverstork 

Mindestalter erreicht

+

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

http://www.stork.gov.eu/1.0/
+ fiscalNumber		fiscalNumberstork 

Steuernummer

+

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

+

 

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.

+

 

+

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

bzw.

+
+https://<host>:<port>/moa-id-auth/pvp2/metadata
+
+

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 .

+ +

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.

+

2.3 Zugangspunkte

+

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.

+

2.3.1 Authentifizierungsrequest

+

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.

+ +

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

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!

@@ -44,13 +481,40 @@

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.

-

TODO:

- +

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 Service Provider generiert den AuchCode Request und sendet diesen über den Browser an das Modul MOA-ID-Auth.
    3. +
  3. MOA-ID-Auth validiert den AuthCode Request.
    4. +
  4. 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. +
    +
    5. +
  5. Nach erfolgreicher Authentifizierung erzeugt MOA-ID-Auth die AuthCode Response. +
      +
    1. Die AuthCode Response wird mittels Redirect an den Service Provider retourniert.
      2. +
    +
    6. +
  6. Der Service Provider validiert die AuthCode Response.
    7. +
  7. Der Service Provider generiert den AccessToken Request und sendet diesen an MOA-ID-Auth zum Abholen der Benutzerdaten.
    8. +
  8. MOA-ID-Auth validiert den AccessToken Request
    9. +
  9. MOA-ID-Auth generiert die AccessToken Response +
      +
    1. Retournierung der AccessToken Response an den Service Provider
      2. +
    +
    10. +
  10. Validieren der AccessToken Response +
      +
    1. Wird die Validierung gültig abgeschlossen kann die BenutzerIn oder der Benutzer am Service Provider angemeldet werden.
      2. +
    +
    11. +

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.

3.3 Beschreibung der Nachrichten

@@ -58,18 +522,184 @@

3.2.1 AuthCode Request

Der AuthCode Request ist die Authentifizierungsanfrage einer Online-Applikation für eine BenutzerIn oder einen Benutzer. -Folgende Parameter müssen oder können mit dem AuthCode-Request mitgesendet werden, wobei für die Übertragung der Parameter sowohl http GET als auch http POST verwendet werden kann.

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameBeispielwertBeschreibung
client_idhttps://demo.egiz.gv.at/demoportal-openID_demoIst der eindeutige Identifikatior für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
response_typecode

Rückgabewert des AuthCode Requests.

+ Hinweis: Dieser Wert MUSS "code" sein.
redirect_urihttps://demo.egiz.gv.at/demoportal-openID_demo/securearea.actionDie Callback-URI der Online-Applikation zu welcher die Callbacks der OAuth 2.0 Request gesendet werden. Dieser MUSS mit der Redirct URL aus der Konfiguration identisch sein.
state1425782214234Ein von der Online-Applikation generierter Wert welcher in beiden Requests (AuthCode und Token) gleich sein muss (ein CSRF Token)
scopeopenID 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.

+
    +
  • openID: +
      +
    • bpk --> Bereichsspezifisches Kennzeichen (bPK / wbPK)
      • +
    • iss --> Public URP Prefix der MOA-ID Instanz
      • +
    • exp --> Zeitliche Gültigkeit
      • +
    • iat --> Ausstellungszeitpunkt
      • +
    • auth_time --> Authentifizierungszeitpunkt
      • +
    +
    • +
+

 

+

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

3.2.2 AuthCode Response

- +

Das Ergebnis des AuthCode Requests wird an die redirect_uri der Online-Applikation gesendet. Die nachfolgenden Parameter werden dabei übergeben.

+ + + + + + + + + + + + + + + + +
NameBeispielwertBeschreibung
state1425782214234Der von der Online-Applikation generierte und im AuthCode Request übergebene CSRF Token.
code4/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.

+

 

+

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameBeispielwertBeschreibung
grant_typeauthorization_codeDieser MUSS den Wert „authorization_code“ besitzen.
code4/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_urihttps://demo.egiz.gv.at/demoportal-openID_demo/securearea.actionDie Callback-URI der Online-Applikation zu welcher die Callbacks der OAuth 2.0 Request gesendet werden. Dieser MUSS mit der Redirct URL aus der Konfiguration identisch sein.
client_idhttps://demo.egiz.gv.at/demoportal-openID_demoIst der eindeutige Identifikatior für die Online-Applikation. Dieser MUSS mit dem Identifikatior aus der Konfiguration identisch sein.
client_secret0adf1ec7-c2a6-4fd3-897c-456d0fb7b5ccDas 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/oauth2/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>

3.2.4 AccessToken Response

+

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameBeispielwertBeschreibung
access_tokenSlAV32hkKG

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_typeBearer

OpenID Connect spezifischer Parameter (Details entnehmen Sie bitte der OpenID Connect Spezifikation)

expires_in3600Gültigkeitszeitraum der Response (TODO)
scopeopenID profile eIDDie im AuthCode Request angeforderten Profile.
id_tokeneyJhbGciOiJSU.....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-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
+               NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
+               QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
+               K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
+               XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
+}

3 SAML 1

-- cgit v1.2.3