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/additional/additional.html | 199 +++++++ .../doc/handbook/application/application.html | 213 ++++++++ id/server/doc/handbook/application/iframe.png | Bin 0 -> 86175 bytes .../doc/handbook/application/login_button.PNG | Bin 0 -> 70066 bytes id/server/doc/handbook/application/mainframe.PNG | Bin 0 -> 59073 bytes .../doc/handbook/application/sso_sendassertion.PNG | Bin 0 -> 6041 bytes id/server/doc/handbook/config/config.html | 53 +- id/server/doc/handbook/faq/faq.html | 125 ----- id/server/doc/handbook/index.html | 9 +- id/server/doc/handbook/install/install.html | 18 +- id/server/doc/handbook/intro/intro.html | 28 +- 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 id/server/doc/handbook/spec/MOA ID 1.x.wsdl | 41 ++ .../doc/handbook/spec/MOA_ID_1.2_20040315.pdf | Bin 0 -> 577309 bytes .../doc/handbook/spec/MOA_ID_1.3_20060315.pdf | Bin 0 -> 355156 bytes .../doc/handbook/spec/MOA_ID_1.4_20070802.pdf | Bin 0 -> 239502 bytes id/server/doc/handbook/spec/MOA_ID_1.4_Anhang.pdf | Bin 0 -> 286834 bytes id/server/doc/handbook/spec/MOA_ID_1.5_Anhang.pdf | Bin 0 -> 134176 bytes id/server/doc/handbook/spec/OID-1-0-3.pdf | Bin 0 -> 347041 bytes .../handbook/spec/cs-sstc-schema-assertion-01.xsd | 194 +++++++ .../handbook/spec/cs-sstc-schema-protocol-01.xsd | 127 +++++ 26 files changed, 1347 insertions(+), 251 deletions(-) create mode 100644 id/server/doc/handbook/additional/additional.html create mode 100644 id/server/doc/handbook/application/application.html create mode 100644 id/server/doc/handbook/application/iframe.png create mode 100644 id/server/doc/handbook/application/login_button.PNG create mode 100644 id/server/doc/handbook/application/mainframe.PNG create mode 100644 id/server/doc/handbook/application/sso_sendassertion.PNG delete mode 100644 id/server/doc/handbook/faq/faq.html 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 create mode 100644 id/server/doc/handbook/spec/MOA ID 1.x.wsdl create mode 100644 id/server/doc/handbook/spec/MOA_ID_1.2_20040315.pdf create mode 100644 id/server/doc/handbook/spec/MOA_ID_1.3_20060315.pdf create mode 100644 id/server/doc/handbook/spec/MOA_ID_1.4_20070802.pdf create mode 100644 id/server/doc/handbook/spec/MOA_ID_1.4_Anhang.pdf create mode 100644 id/server/doc/handbook/spec/MOA_ID_1.5_Anhang.pdf create mode 100644 id/server/doc/handbook/spec/OID-1-0-3.pdf create mode 100644 id/server/doc/handbook/spec/cs-sstc-schema-assertion-01.xsd create mode 100644 id/server/doc/handbook/spec/cs-sstc-schema-protocol-01.xsd (limited to 'id/server/doc/handbook') diff --git a/id/server/doc/handbook/additional/additional.html b/id/server/doc/handbook/additional/additional.html new file mode 100644 index 000000000..25da0e095 --- /dev/null +++ b/id/server/doc/handbook/additional/additional.html @@ -0,0 +1,199 @@ + + + + + MOA-ID - Zusatzinformationen + + + + + + + + + +

Dokumentation

MOA-ID (Identifikation)

Zusatzinformationen

Inhalt

Datenmanagement +
1. Sessiondaten +
  1. Allgemein
  2. Single Sign-On
  +
2. Logging von Statistikdaten
+

1 Datenmanagement

Dieser Abschnitt spezifiziert jene Datensätze die während eines Anmeldevorgangs durch das Modul MOA-ID-Auth temporär oder permanent gespeichert werden. Hierbei handelt es sich sowohl um temporäre Sessiondaten als auch um dauerhaft gespeicherte Statistikdaten.

1.1 Sessiondaten

Dieser Abschnitt behandelt jene Informationen die das Modul MOA-ID-Auth während eines Authentifizierungsvorgangs oder während einer aktiven Single Sign-On Session im Speicher hält. Diese Datensätze werden nach Beendigung des Anmeldevorgangs, bei einfacher Anmeldung, oder nach Beendigung der Single Sign-On Session gelöscht. Die nachfolgenden Unterkapitel geben eine Aufstellung jener Daten die von MOA-ID im jeweiligen Falle gespeichert werden.

1.1.1 Allgemein

Folgende Daten müssen mindestens von MOA-ID gecached werden um einen korrekten Anmeldevorgang zu ermöglichen.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Element	Beschreibung
Authentication Request	Dieser wird von der Online-Applikation als Start des Anmeldevorgangs übertragen.
Session ID	Wird von MOA-ID generiert und dient zur Identifikation von Datensätzen.
Personenbindung	Die Personenbindung der BenutzerIn oder des Benutzers.
AuthBlock	Der Authentifizierungsblock, welcher im Rahmen des Anmeldevorgangs vom der BenutzerIn oder dem Benutzer signiert wird.
Signaturzertifikat	Das Signaturzertifikat, welches zur Signierung des Authentifizierungsblocks verwendet wurde.
Vollmacht	Die Online-Vollmacht, welche bei einer Anmeldung in Vertretung ausgewählt wurde.
STORK	Alle Attribute, welche bei einer Anmeldung mittels STORK übertragen werden.
AuthTimeStamp	Zeitpunkt an dem sich die BenutzerIn oder der Benutzer an MOA-ID-Auth authentifiziert hat.

1.1.2 Single Sign-On

Im Falle einer Anmeldung mit Single Sign-In werden zusätzlich zu den oben genannten Elementen noch weitere Datensätze gecached.

+ + + + + + + + + + + + + + + + + + + + + +

Element	Beschreibung
SSO Session Token	Das SSO Session Token dient zur Identifizierung einer aktuell bestehenden Single Sign-On Session.
UpdateTimeStamp	Zeitpunkt des letzten Zugriffs der BenutzerIn oder des Benutzers mittels SSO.
Liste: ungültige SSO Token	Eine Liste aller in dieser Single Sign-On Session bereits vergebenen und verwendeten SSO Session Token.
Liste: Online-Applikationen	Eine Liste aller Onlineapplikationen an denen im Rahmen dieser SSO Session eine Anmeldung stattgefunden hat.

1.2 Logging von Statistikdaten

Zusätzlich zu den Daten aus den temporären Sessiondaten werden vom Modul MOA-ID-Auth auch Logging- und Statistikdaten generiert, welche nicht automatisiert gelöscht werden. Diese Daten dienen der Statuskontrolle und zur Protokollierung von Anmeldevorgängen an MOA-ID-Auth. Von MOA-ID-Auth werden folgende Statistikdaten je Anmeldevorgang gespeichert, wobei je nach Art der Anmeldung nicht alle Datenelemente gefüllt werden. Die nachstehende Tabelle beschreibt den maximalen Umfang der Loggingdaten, wobei keine Informationen zur anmeldenden Person gespeichert werden.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Element	Beschreibung
timestamp	Datum und Uhrzeit des Eintrags.
OAID	Eindeutige Datenbank ID der Online-Applikation.
OAURLPrefix	Publik URL Prefix der Online-Applikation
OAFriendlyName	Bezeichnung der Online-Applikation
isBusinessService	„True“ wenn die Online-Applikation aus dem privatwirtschaftlichen Bereich stammt.
OATarget	Bereichskennzeichen der Online-Applikation (Target oder privatwirtschaftlicher Bereich)
BKUType	Art der Bürgerkartenumgebung die für den Anmeldevorgang verwendet wurde. (online, local, handy)
BKUURL	URL der verwendeten Bürgerkartenumgebung
isSSOLogin	„True“ wenn die die Anmeldung als Teil einer SSO Anmeldung erfolgt ist.
isMandateLogin	„True“ wenn die Anmeldung in Vertretung erfolgt ist.
MandateType	Art der verwendeten Vollmacht (Einzelprofile des Vollmachtenservice oder OID des Organwalters / berufsmäßigen Parteienvertreters)
MandatorType	„jur“ / „nat“ je nach Art der vertretenen juristischen oder natürlichen Person
isPV	„True“ wenn die Anmeldung in Vertretung durch einen Organwalter oder berufsmäßigen Parteienvertreter erfolgt ist.
PVOID	OID des Organwalter oder berufsmäßigen Parteienvertreter
ProtocolType	Type des für die Anmeldung verwendeten Authentifizierungsprotokolls. (PVP21, OpenID, SAML1)
ProtocolSubType	Nähere Spezifizierung des Protokolltypes. (Im Falle von PVP 2.1: POST oder Redirect)
ExceptionType	Typ des Fehlers der während des Anmeldevorgangs aufgetreten ist. Aktuell werden folgende Typen unterschieden: + + bku: Fehler während der Kommunikation mit der Bürgerkartenumgebung. + moa-sp: Fehler bei der Kommunikation mit MOA-SP oder der Signaturprüfung. + mandate: Fehler beim Zugriff auf das Online-Vollmachten Service. + moa-id: Fehler während des Authentifizierungsvorgangs. + unknown: für allgemeine Fehler die keinem der oben genannten Typen entsprechen. +
ExceptionCode	Fehlercode des aufgetretenen Fehlers falls vorhanden.
ExceptionMessage	Fehlermeldung in textueller Form (max. 255 Zeichen lang)

+ + diff --git a/id/server/doc/handbook/application/application.html b/id/server/doc/handbook/application/application.html new file mode 100644 index 000000000..0b39077f7 --- /dev/null +++ b/id/server/doc/handbook/application/application.html @@ -0,0 +1,213 @@ + + + + + MOA-ID - Anwendungen + + + + + + + + + +

Dokumentation

MOA-ID (Identifikation)

Anwendungen

Inhalt

Allgemeines
Integration in bestehende Online-Applikationen +
1. Bürgerkartenauswahl +
  1. Request aus einem iFrame
  2. Request aus dem Hauptframe
  +
2. Single Sign-On Anmeldeabfrage
+
Demo Applikationen +
1. PVP 2.1 Demo +
  +
+

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 Integration in bestehende Online-Applikationen

Ab MOA-ID 2.0 wird die Bürgerkartenauswahl und die Single Sign-On Anmeldeabfrage standardmäßig vom Modul MOA-ID-Auth bereitgestellt und muss nicht mehr durch den Service Provider implementiert werden.

Die im Modul MOA-ID-Auth hinterlegten Standard Templates (Bürgerkartenauswahl, Single Sign-On Anmeldeabfrage) unterstützt Responsive Design und passen sich somit in einem weiten Bereich an die aktuelle Fenstergröße an, wodurch eine individuelle Integration der von MOA-ID-Auth erzeugten Formulare möglich ist. Zusätzlich bietet das Konfigurationstool die Möglichkeit der online-applikationsspezifischen Anpassung der Standard Templates. Mit dieser Funktion können einzelne Parameter der Standard Templates an die Online-Applikation angepasst werden um die Integration weiter zu verfeinern.

Hinweis: Es besteht jedoch auch die Möglichkeit der Hinterlegung von vollständig benutzerdefinierten online-applikationsspezifischen Templates für die Bürgerkartenauswahl und die Single Sign-On Anmeldeabfrage, wobei die Verwendung der Standard Templates empfohlen wird (siehe hier).

2.1 Bürgerkartenauswahl

Die Bürgerkartenauswahl wird ab MOA-ID 2.0 standardmäßig von MOA-ID-Auth bereitgestellt. Dem zu Folge müssen die aus MOA-ID 1.5.1 bekannten Parameter (target, bkuURL, template, usemandate) nicht mehr im Authentifizierungsrequest an MOA-ID-Auth übergeben werden und es kann ein standardkonformer Protokollrequest verwendet werden. Die aus MOA-ID 1.5.1 bekannte Variante der Bürgerkartenauswahl steht jedoch weiterhin als Legacy Variante zur Verfügung. Detail hierzu finden Sie hier.

Die Integration der von MOA-ID-Auth bereitgestellten Bürgerkartenauswahl in einer bestehende Online-Applikation kann auf zwei Arten erfolgen, wobei bei beiden Varianten der Login Vorgang (senden des Authentifizierungsrequests an MOA-ID-Auth) durch den Klick auf einen Login Button ausgelöst wird. Das Sequenzdiagramm eines solchen Anmeldevorgangs finden Sie hier und die nachfolgende Grafik zeigt ein Beispiel zur Integration eines Login Buttons.

Integration Login Button

2.1.1 Request aus einem iFrame

Bei dieser Variante wird der Authentifizierungsrequests aus einem iFrame, welcher in die Online-Applikation eingebunden ist, abgesetzt. MOA-ID-Auth antwortet auf diesen Request mit der konfigurierten Bürgerkartenauswahl welche, durch Verwendung des iFrame, in die aktuelle Seite der Online-Applikation eingebunden werden kann. Die nachfolgende Grafik zeigt ein Beispiel für die von MOA-ID-Auth bereitgestellte Bürgerkartenauswahl, welche nach Betätigung des Login Buttons im iFrame dargestellt wird.

Bürgerkartenauswahl im iFrame

Hinweis: Bei dieser Variante wird die Assertion ebenfalls an den iFrame ausgeliefert wodurch der authentifizierte Bereich der Online-Applikation im iFrame dargestellt wird. Dieses Verhalten kann durch eine online-applikationsspezifischen Anpassung der Standard Templates und dem Parameter Targetparameter unterbunden werden.

2.1.2 Request aus dem Hauptframe

Bei dieser Variante wird der Authentifizierungsrequests direkt aus dem aktuell offenen Browserfenster, an MOA-ID-Auth gesendet. In diesem Fall wird die Bürgerkartenauswahl fensterfüllend im Browser dargestellt und die BenutzerIn oder der Benutzer befindet sich nicht mehr in der Domain der Online-Applikation (des Service Providers). Nach erfolgreicher Authentifizierung wird die BenutzerIn oder der Benutzer an die Online-Applikation zurückgeleitet. Die nachfolgende Grafik zeigt die Bürgerkartenauswahl im seitenfüllenden Layout.

Bürgerkartenauswahl im seitenfüllenden Layout

2.2 Single Sign-On Anmeldeabfrage

Wird für die Integration in die Online-Applikation die Variante mit dem Login Button und der von MOA-ID-Auth bereitgestellten Bürgerkartenauswahl verwendet (iFrame oder Hauptframe), ergeben sich für die Single Sign-On Anmeldeabfrage keine zusätzlichen Anforderungen. Im Falle einer aktiven Single Sign-On Session, würde MOA-ID-Auth mit der Single Sign-On Anmeldeabfrage anstatt der Bürgerkartenauswahl antworten. Auch in diesem Fall stehen beide Möglichkeiten der Integration, identisch zur Bürgerkartenauswahl zur Verfügung. Die nachfolgende Grafik zeigt eine Single Sign-On Abfrage, welche je nach verwendeter Variante die Bürgerkartenauswahl, in den zuvor gezeigten Beispielen, ersetzen würde.

Single Sign-On Anmeldeabfrage

Hinweis: Wird für die Integration der Bürgerkartenauswahl jedoch die Legacy Variante verwendet (direkte Integration der Bürgerkartenauswahl in die Online-Applikation) kann es zu Inkompatibilitäten mit der Single Sign-On Anmeldeabfrage kommen, da diese Abfrage immer von MOA-ID-Auth generiert wird und eine direkte Integration in eine Online-Applikation nicht möglich ist.

3 Demo Applikationen

Diese Abschnitt behandelt die Konfiguration und Verwendung der bei MOA-ID beigelegten Demo Applikationen.

3.1 PVP 2.1 Demo

Die PVP 2.1 Demo stellt das Minimalbeispiel einer Online-Applikation dar, welche zur Authentifizierung das Protokoll PVP 2.1 verwendet. Die nachfolgenden Abschnitte beschreiben die Installation, Konfiguration und Verwendung der PVP 2.1 Demo Applikation.

3.1.1 Installation

Für die Installation der Demo Applikation wird ein Apache Tomcat benötigt. Die Konfiguration dieser Tomcat Instanz ist identisch zur Konfiguration der Tomcat Instanz der Module MOA-ID-Auth und MOA-ID-Configuration.

3.1.1.1 Einsatz der Demo Applikation in Tomcat

Die Datei $MOA_ID_AUTH_INST/moa-id_oa.war enthält das einsatzfertige Webarchiv der Demo Applikation und muss ins Verzeichnis $CATALINA_HOME/webapps kopiert werden. Dort wird sie beim ersten Start von Tomcat automatisch ins Verzeichnis $CATALINA_HOME/webapps/moa-id-oa entpackt.
Die Konfigurationsdatei mit der Basiskonfiguration für die Demo Applikation und die zugehörigen Verzeichnisse müssen in ein beliebiges Verzeichnis im Dateisystem kopiert werden (z.B. $CATALINA_HOME/conf/moa-id-oa). Eine funktionsfähige Konfiguration, die als Ausgangspunkt für die Basiskonfiguration der Demo Applikation dienen kann, finden Sie hier.
+
Die Dateien xalan.jar, xercesImpl.jar, serializer.jar und xml-apis.jar aus dem Verzeichnis $MOA_ID_AUTH_INST/endorsed müssen in das Tomcat-Verzeichnis $CATALINA_HOME/endorsed (bzw. $CATALINA_HOME/common/endorsed bis Apache Tomcat Version 5.5) kopiert werden. Sind gleichnamige Dateien dort bereits vorhanden, müssen sie überschrieben werden. Die ggf. in diesem Verzeichnis vorhandene Datei xmlParserAPIs.jar muss gelöscht werden. Sollte das Verzeichnis endorsed nicht vorhanden sein, dann muss dieses zuerst erstellt werden.
Folgende System Properties können gesetzt werden (wird beim Starten von Tomcat der Java Virtual Machine in der Umgebungsvariablen CATALINA_OPTS in der Form -D<name>=<wert> übergeben): +
- moa.id.demoOA: Pfad und Name der Basiskonfigurationsdatei für die Demo Applikation. Eine beispielhafte Konfigurationsdatei fnden Sie hier. Wird ein relativer Pfad angegeben, wird dieser relativ zum Startverzeichnis der Java Virtual Machine interpretiert.
- log4j.configuration: URL der Log4j Konfigurationsdatei. Eine beispielhafte Log4j-Konfiguration finden Sie hier. Wird eine relative URL angegeben, wird diese als File-URL relativ zum Startverzeichnis der Java Virtual Machine interpretiert. Ist diese System Property nicht gesetzt, wird automatisch eine im Webarchiv unter WEB-INF/classes enthaltene Default-Konfiguration herangezogen.
- javax.net.ssl.trustStore: Pfad und Dateiname des Truststores für vertrauenswürdige SSL Client-Zertifikate (optional; nur, wenn SSL Client-Authentisierung durchgeführt werden soll). Ein relativer Pfad werden relativ zum Startverzeichnis der Java Virtual Machine interpretiert.
- javax.net.ssl.trustStorePassword: Passwort für den Truststore (optional; nur, wenn SSL Client-Authentisierung durchgeführt werden soll).
- javax.net.ssl.trustStoreType: Truststore-Typ (optional; nur, wenn SSL Client-Authentisierung durchgeführt werden soll). Je nach verwendetem Keystore-Typ muss jks (Java Key Store) oder pkcs12 (PKCS#12-Datei) angegeben werden.
+

3.1.1.2 Einsatz der Demo Applikation in Tomcat

Das starten und stoppen der Demo Applikation erfolgt identisch zur Beschreibung für die Module MOA-ID-Auth und MOA-ID-Configuration.

Ein erfolgreicher Start der Demo Applikation ist an folgender Log-Meldung ersichtlich:

INFO at.gv.egovernment.moa.id.demoOA.Configuration  - Demo Application initializaten finished.

Nach dem Starten von Tomcat steht die Demo Applikation zur Verfügung.

http://<host>:<port>/moa-id-oa/

bzw.

+https://<host>:<port>/moa-id-oa/
+

3.1.2 Konfiguration Demo Applikation

Die zentrale Konfigurationsdatei für die Demo Applikation wird der Java Virtual Machine, in der die Demo Applikation läuft, durch eine System Property mitgeteilt (wird beim Starten der Java Virtual Machine in der Form -D<name>=<wert> gemacht). Der Name der System Property lautet moa.id.demoOA als Wert der System Property ist der Pfad sowie der Name der Konfigurationsdatei im Dateisystem anzugeben, z.B.

moa.id.demoOA=C:/Programme/apache/tomcat-4.1.30/conf/moa-id-oa/oa.properties

Dieses Konfigurationsdatei beinhaltet folgende Parameter.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name	Beispielwert	Beschreibung
general.login.pvp2.idp.metadata.url	https://demo.egiz.gv.at/moa-id-auth/ + pvp2/metadata	URL unter der die PVP2.1 Metadaten des IDP abgeholt werden können.
general.login.pvp2.idp.metadata.certificate	keys/metadata.crt	Zertifikat mit dem die PVP2.1 Metadaten des IDP signiert sind. Dieser Zertifikat wird zur Prüfung der IDP Metadaten verwendet.
general.login.pvp2.idp.metadata.entityID	https://demo.egiz.gv.at/moa-id-auth/	EntityID des IDP in den Metadaten (Details siehe PVP2.1 Spezifikation)
general.login.pvp2.idp.sso.logout.url	https://demo.egiz.gv.at/moa-id-auth/LogOut?redirect= + https://demo.egiz.gv.at/moa-id-oa	URL zum Single Log-Out (SLO) Service des IDP. Details zum SLO Service von MOA-ID-Auth finden Sie hier.
general.login.pvp2.metadata.entities.name	PVP 2.1 Demo	Name der Applikation, welcher in den Metadaten der Applikation angegeben wird
general.login.pvp2.keystore.url	keys/moa_idp.p12	Keystore mit Schlüssel und Zertifikaten welche für das signieren und verschlüsseln der PVP2.1 Nachrichten verwendet werden sollen.
general.login.pvp2.keystore.password	123456	Passwort des Keystores
general.login.pvp2.keystore.type	PKCS12	Type des Keystores. Aktuell werden folgene Keystore Typen unterstützt + + PKCS12: PKCS12 Keystor + JKS: Java-Keystore +
general.login.pvp2.keystore.metadata.key.alias	metadata	Name des Schlüssels der zum Signieren der Metadaten des Modules MOA-ID-Configuration verwendet werden soll
general.login.pvp2.keystore.metadata.key.password	123456	Passwort des Schlüssels der zum Signieren der Metadaten verwendet werden soll.
general.login.pvp2.keystore.authrequest.encryption.key.alias	encryption	Name des Schlüssels der zum Verschlüsseln der Anmeldeinformation, welche vom IDP an das Konfigurationstool übermittelt, verwendet werden soll
general.login.pvp2.keystore.authrequest.encryption.key.password	123456	Passwort des Schlüssels zum Verschlüsseln der Anmeldeinformation.
general.login.pvp2.keystore.authrequest.key.alias	authrequest	Name des Schlüssels zum Signieren des Authentifizierungsrequests der an den IDP gestellt wird.
general.login.pvp2.keystore.authrequest.key.password	123456	Passwort des Schlüssels zum Signieren des Authentifizierungsrequests.

Die Metadaten des Modules MOA-ID-Configuration werden dynamisch erstellt und stehen unter folgender URL zum Download bereit.

+http://<host>:<port>/moa-id-oa/servlet/metadata

bzw.

+https://<host>:<port>/moa-id-oa/servlet/metadata

Nach erfolgreicher Konfiguration muss die Tomcat Instanz neu gestartet werden.

3.1.3 Konfiguration von MOA-ID-Auth

Bevor ein Anmeldevorgang gestartet werden kann muss die Demo Applikation auch als Online-Applikation für das Modul MOA-ID-Auth konfiguriert werden. Hierfür kann das Konfigurationstool (Modul MOA-ID-Configuration) verwendet werden. Tragen Sie die Demo Applikation als Online-Applikation bei Ihrer MOA-ID-Auth Instanz ein. Eine Beschreibung der einzelnen Konfigurationsparameter finden Sie hier.

3.1.4 Anwendung

Nach dem Starten von Tomcat steht die Demo Applikation zur Verfügung.

http://<host>:<port>/moa-id-oa/

bzw.

+https://<host>:<port>/moa-id-oa/
+

Die Startseite der Demo Applikation beinhaltet einen kurzen Beschreibungstext und den Login Button zum Start des Anmeldevorgangs. Für die Integration der Bürgerkartenumgebung verwenden die Demo die im Kapitel 2.1.1 beschriebenen iFrame Variante. Nach Betätigung des Login Buttons wird der Anmeldevorgang gestartet. Der Protokollablauf identisch zu dem im Kapitel Protokolle beschiebenen Ablauf für das PVP 2.1 Protokoll.

Konnten die Metadaten und der Authentifizierungsrequest erfolgreich verifiziert werden, wird anschließend die Bürgerkartenauswahl in der Hauptseite der Demo Applikation dargestellt. Wählen Sie nur die gewünschte Authentifizierungsvariante. Nur erfolgt die Authentifizierung mittels der gewählten Variante.

Nach erfolgreicher Authentifizierung werden sie an die Demo Applikation zurückgeleite und die Demo Applikation stellt einige Basisdaten aus Authentifizierungsinformationen dar. Zusätzlich kann die gesamte übertragene PVP 2.1 Assertion dargestellt werden.

Wurde der Anmeldevorgang durch einen Fehler abgebrochen werden Sie ebenfalls an die Demo Applikation zurückgeleitet. In diesem Fall wird eine kurze Fehlerbeschreibung dargestellt. Eine ausführliche Fehlerbeschreibung kann der PVP 2.1 Assertion entnommen werden.

+ + diff --git a/id/server/doc/handbook/application/iframe.png b/id/server/doc/handbook/application/iframe.png new file mode 100644 index 000000000..dcc6a932d Binary files /dev/null and b/id/server/doc/handbook/application/iframe.png differ diff --git a/id/server/doc/handbook/application/login_button.PNG b/id/server/doc/handbook/application/login_button.PNG new file mode 100644 index 000000000..36d8921ce Binary files /dev/null and b/id/server/doc/handbook/application/login_button.PNG differ diff --git a/id/server/doc/handbook/application/mainframe.PNG b/id/server/doc/handbook/application/mainframe.PNG new file mode 100644 index 000000000..0e597d3fc Binary files /dev/null and b/id/server/doc/handbook/application/mainframe.PNG differ diff --git a/id/server/doc/handbook/application/sso_sendassertion.PNG b/id/server/doc/handbook/application/sso_sendassertion.PNG new file mode 100644 index 000000000..1a2ca6a67 Binary files /dev/null and b/id/server/doc/handbook/application/sso_sendassertion.PNG differ diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index b3bea08cb..3565de210 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -145,10 +145,12 @@

Security-Layer Request

Konfiguration von MOA-SP

Tomcat Security Manager

Referenzierte Spezifikation

1 Übersicht

Dieses Handbuch beschreibt detailliert die Konfigurationsmöglichkeiten für die Module MOA-ID-Auth und MOA-ID-Configuration. Wobei das zentrale Einsatzgebiet des Modules MOA-ID-Configuration die Konfiguration des Modules MOA-ID-Auth darstellt.

@@ -270,7 +272,7 @@ general.login.pvp2.idp.sso.logout.url https://demo.egiz.gv.at/moa-id-auth/LogOut?redirect=
https://demo.egiz.gv.at/moa-id-configuration - URL zum Single Log-Out (SLO) Service des IDP. Details zum SLO Service von MOA-ID-Auth finden Sie hier. + URL zum Single Log-Out (SLO) Service des IDP. Details zum SLO Service von MOA-ID-Auth finden Sie hier. general.login.pvp2.metadata.entities.name @@ -606,7 +608,7 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet service.moasp.acceptedServerCertificates certs/moa-sp-server/ - Hier kann ein Verzeichnisname (relativ zur MOA-ID Konfigurationsdatei) angegeben werden, in dem die akzeptierten Zertifikate der TLS-Verbindung hinterlegt sind. In diesem Verzeichnis werden nur Serverzertifikate abgelegt. Fehlt dieser Parameter wird lediglich überprüft ob ein Zertifikatspfad zu den im Element <TrustedCACertificates> TODO!! angegebenen Zertifikaten erstellt werden kann. + Hier kann ein Verzeichnisname (relativ zur MOA-ID Konfigurationsdatei) angegeben werden, in dem die akzeptierten Zertifikate der TLS-Verbindung hinterlegt sind. In diesem Verzeichnis werden nur Serverzertifikate abgelegt. Fehlt dieser Parameter wird lediglich überprüft ob ein Zertifikatspfad zu den im Element <TrustedCACertificates> (siehe Kapitel 3.1.4) angegebenen Zertifikaten erstellt werden kann.

@@ -872,7 +874,7 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet

3.1.2 Default BKUs

Hiermit werden die URLs zu den Default Bürgerkartenumgebungen (BKUs) definiert die von MOA-ID-Auth für einen Anmeldevorgang verwendet werden, wenn die Bürgerkartenauswahl nicht bereits auf Seiten der Online-Applikation erfolgt ist (siehe Protokolle: TODO) oder in der Online-Applikationskonfiguration keine BKU URLs konfiguriert wurden (siehe Kapitel 3.2.2).

Hiermit werden die URLs zu den Default Bürgerkartenumgebungen (BKUs) definiert die von MOA-ID-Auth für einen Anmeldevorgang verwendet werden, wenn die Bürgerkartenauswahl nicht bereits auf Seiten der Online-Applikation erfolgt ist (siehe Legacy Request) oder in der Online-Applikationskonfiguration keine BKU URLs konfiguriert wurden (siehe Kapitel 3.2.2).

@@ -975,7 +977,7 @@ Checking

Name

3.1.6 MOA-SP

Der Abschnitt MOA-SP Konfiguration enthält Parameter zur Nutzung von MOA-SP. MOA-SP wird für die Überprüfung der Signatur der Personenbindung und des AUTH-Blocks verwendet.

MOA-SP muss entsprechend konfiguriert werden - siehe hierzu Abschnitt TODO: Konfiguration von MOA-SP. Alle Details zur Konfiguration von MOA-SP finden sie in der Distribution von MOA-SP/SS beiliegenden Dokumentation im Abschnitt 'Konfiguration'.

MOA-SP muss entsprechend konfiguriert werden - siehe hierzu Abschnitt Konfiguration von MOA-SP. Alle Details zur Konfiguration von MOA-SP finden sie in der Distribution von MOA-SP/SS beiliegenden Dokumentation im Abschnitt 'Konfiguration'.

@@ -1120,7 +1122,7 @@ Checking

In diesem Abschnitt können die einzelnen von MOA-ID-Auth unterstützen Authentifizierungsprotokolle aktiviert oder deaktiviert werden. Diese Einstellung gilt für die gesamte MOA-ID-Auth Instanz.

3.1.10.2 Legacy Modus

Ab der Version 2.0 des Modules MOA-ID-Auth wird die Bürgerkartenauswahl standardmäßig von MOA-ID-Auth bereitgestellt und erfolgt im Kontext von MOA-ID-Auth. Dem zu Folge müssen die aus MOA-ID 1.5.1 bekannten StartAuthentication Parameter (target, bkuURL, template, usemandate) nicht mehr im StartAuthentication Request übergeben werden.

-Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der Online-Applikation erfolgen muss für das jeweilige Protokoll der Legacy Modus aktiviert werden. Wird der Legacy Modus verwendet müssen jedoch die bkuURL, das Security-Layer Template und der Target mit den bei MOA-ID-Auth hinterlegten Konfigurationsparametern der Online-Applikation übereinstimmten. Detailinformationen hierzu finden Sie im Kapitel Protokolle. TODO: +Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der Online-Applikation erfolgen muss für das jeweilige Protokoll der Legacy Modus aktiviert werden. Wird der Legacy Modus verwendet müssen jedoch die bkuURL, das Security-Layer Template und der Target mit den bei MOA-ID-Auth hinterlegten Konfigurationsparametern der Online-Applikation übereinstimmten. Detailinformationen hierzu finden Sie im Kapitel Protokolle.

3.1.10.3 SAML1 Konfiguration

Die SourceID ist ein Teil des SAML1 Artifacts welches zur Abholung der SAML1 Assertion an die Online-Applikation zurückgegeben wird. Standardmäßig wird die SourceID aus der URL der jeweiligen Online-Applikation, an der die Anmeldung stattfinden, generiert. Optional kann jedoch eine SourceID für die gesamte MOA-ID-Auth Instanz vergeben werden, welche für alle Online-Applikationen verwendet wird.

Name

@@ -1213,7 +1215,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der

3.1.11 Security-Layer Transformationen

Die Security-Layer (SL) Transformation, welche von MOA-ID-Auth für die Erstellung der Signatur des AuthBlock verwendet werden soll, muss hier angegeben werden. Über das Datei-Upload Feld kann die zu verwendende Transformation hochgeladen werden. Diese befindet sich in der MOA-ID-Auth Defaultkonfiguration im Ordner /conf/moa-id/transforms/ TransformsInfoAuthBlockTable_DE_2.0.xml. TODO: URL

3.2 Online Applikationen

Die Konfiguration von Online-Applikationen erfolgt ebenfalls mit Hilfe des Moduls MOA-ID-Configuration. Es können sowohl neue Online-Applikationen erstellt als auch bestehende Online-Applikationen bearbeitet oder gelöscht werden. Der erlaubte Konfigurationsumfang hängt jedoch von Role des aktuellen Benutzers ab, wobei eine Konfiguration der gesamten Parameter nur einem Benutzer mit der Role admin möglich ist. Alle Konfigurationsfelder die nur einem Benutzer mit der Role admin zur Verfügung stehen sind gesondert gekennzeichnet.

3.2.1 Informationen zur Online-Applikation (Service Provider)

@@ -1370,7 +1372,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der X X - Über diese Funktion können drei zusätzliche SecurtityLayer-Request Templates für diese Online-Applikation definiert werden. Diese hier definierten Templates dienen als zusätzliche WhiteList für Templetes welche im „StartAuthentication“ Request mit dem Parameter „template“ übergeben werden. Sollte im „StartAuthentication“ Request der Parameter „template“ fehlen, es wurde jedoch eine „bkuURL“ übergeben, dann wird für den Authentifizierungsvorgang das erste Template in dieser Liste verwendet. Detailinformationen zum legacy Request finden Sie im Kapitel Protokolle. TODO: + Über diese Funktion können drei zusätzliche SecurtityLayer-Request Templates für diese Online-Applikation definiert werden. Diese hier definierten Templates dienen als zusätzliche WhiteList für Templetes welche im „StartAuthentication“ Request mit dem Parameter „template“ übergeben werden. Sollte im „StartAuthentication“ Request der Parameter „template“ fehlen, es wurde jedoch eine „bkuURL“ übergeben, dann wird für den Authentifizierungsvorgang das erste Template in dieser Liste verwendet. Detailinformationen zum Legacy Request finden Sie im Kapitel Protokolle. BKU-Selection Template @@ -1484,7 +1486,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der

Hinweis: Werden für die Online-Applikation eigene Templates für die Bürgerkartenauswahl oder die zusätzliche Anmeldeabfrage im SSO Fall (siehe Abschnitt 3.2.2) verwendet, stehen alle Konfigurationsparameter die Einfluss auf die BKU-Auswahl haben nicht zur Verfügung.

3.2.6 Authentifizierungsprotokolle

Dieser Abschnitt behandelt online-applikationsspezifische Einstellungen zu den von der Online-Applikation unterstützen Authentifizierungsprotokollen. Eine Verwendung aller zur Verfügung stehender Authentifizierungsprotokolle durch die Online-Applikation ist ebenfalls möglich. Hierfür muss nur alle benötigten Protokolle konfiguriert werden. Nähere Informationen zu den unterstützten Protokollen finden sie im Kapitel Protokolle. TODO:

Dieser Abschnitt behandelt online-applikationsspezifische Einstellungen zu den von der Online-Applikation unterstützen Authentifizierungsprotokollen. Eine Verwendung aller zur Verfügung stehender Authentifizierungsprotokolle durch die Online-Applikation ist ebenfalls möglich. Hierfür müssen nur alle benötigten Protokolle konfiguriert werden. Nähere Informationen zu den unterstützten Protokollen finden sie im Kapitel Protokolle.

Aus gründen der Übersichtlichkeit kann der Konfigurationsbereich für jeden Protokoll, in der Web-Oberfläche des Konfigurationstools, ein- oder ausgeblendet werden.

3.2.6.1 SAML1

Für das Protokoll SAML1 stehen folgende Konfigurationsparameter zur Verfügung.

@@ -1556,14 +1558,14 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der X - Wird diese Option gewählt erfolgt nach dem Speicher der Konfiguration eine Neu-initialisierung der PVP 2.1 Metadaten der Online-Applikation durch die MOA-ID-Auth Instanz. + Wird diese Option gewählt erfolgt nach dem Speicher der Konfiguration eine Neuinitialisierung der PVP 2.1 Metadaten der Online-Applikation durch die MOA-ID-Auth Instanz. URL zu den Metadaten http://demo.egiz.gv.at/demologin-pvp2-sso/metadata/demoportal-pvp2-sso.mdxml - URL unter der die MOA-ID-Auth Instanz die Metadaten der Online-Applikation beziehen kann. Diese Metadaten müssen durch die Online-Applikation signiert sein. Für den Fall das die Metadaten über https abgeholt werden, muss ja jeweilige Serverzertifikat zur Zertifikatsprüfung im TrustStore der MOA-ID-Auth Instanz hinterlegt sein. + URL unter der die MOA-ID-Auth Instanz die Metadaten der Online-Applikation beziehen kann. Diese Metadaten müssen durch die Online-Applikation signiert sein. Für den Fall das die Metadaten über https abgeholt werden, muss ja jeweilige Serverzertifikat zur Zertifikatsprüfung im TrustStore der MOA-ID-Auth Instanz hinterlegt sein. Die Metadaten werden anschließend durch MOA-ID-Auth innerhalb des in den Metadaten angegebenen Gültigkeitszeitraums automatisch aktuallisiert. Das Aktuallisierungsintervall bei automatischer Aktualisierung beträgt jedoch mindestens 15 Minuten jedoch nicht mehr als 24 Stunden. (Interval: 15min < Aktualisierungszeitpunkt < 24 Stunden)

Hinweis: Metadaten können nur über http oder https bezogen werden. Das Laden von Metadaten aus dem lokalen Verzeichnissystem ist nicht möglich.

@@ -1618,7 +1620,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der

3.2.7 Zusätzliche allgemeine Einstellungen

In Abschnitt ermöglicht eine erweiterte online-applikationsspezifische Individualisierung des AuthBlocks und der Bürgerkartenauswahl. -Die Individualisierung des AuthBlocks steht jedoch dann zur Verfügung wenn die dem Module MOA-ID-Auth beigelegte Security-Layer Transformation (siehe Kapitel TODO:) verwendet wird oder +Die Individualisierung des AuthBlocks steht jedoch dann zur Verfügung wenn die dem Module MOA-ID-Auth beigelegte Security-Layer Transformation verwendet wird oder wenn die individuelle Security-Layer Transformation den Formvorschriften der Spezifikation entspricht.

@@ -1781,7 +1783,9 @@ Exportfunktion verwendet werden.

4 Templates

Dieser Abschnitt spezifiziert den Mindestaufbau der Templates für die BKU Auswahl, die Single Sign-On Anmeldeabfrage und die Security-Layer Request Templates welche vo Module MOA-ID-Auth verwendet werden. Alle hier beschriebenen Templates werden durch MOA-ID-Auth geladen, erweitert und gegebenfalls der Benutzerin oder dem Benutzer im Web-Browser dargestellt. Um einen korrekten Anmeldeprozess zu gewährleisten müssen diese Templates mindestens folgende Formvorschriften und Strukturen aufweisen.

4.1 Bürgerkartenauswahl

Das BKU Template dient im Anmeldeprozess der Auswahl der gewünschten Bürgerkatenumgebung oder Handy-Signature. Nach erfolgter Auswahl durch die Benutzer oder dem Benutzer wird diese an MOA-ID-Auth übermittelt. Für die Übermittlung an MOA-ID-Auth ist ein http GET Request vorgesehen welcher folgende Parameter unterstützt. Die URL dieses http GET Request wird automatisiert über den Parameter „#AUTH_URL#“ (ohne „“) eingetragen und muss nicht manuell hinterlegt werden. Folgende http GET Parameter werden für die BKU-Auswahl akzeptiert.

Hinweis: In der Datei ./htmlTemplates/loginFormFull.html welcher sich relativ zur MOA-ID-Auth Konfigurationsdatei befindet finden Sie das Standard Template welches für den Anmeldevorgang verwendet wird, wenn kein online-applikationsspezifisches Template hinterlegt wurde. Dieses Standard Template unterstützt Responsive Design und passen sich somit in einem weiten Bereich an die aktuelle Fenstergröße an.

Für die Übermittlung an MOA-ID-Auth ist ein http GET Request vorgesehen welcher folgende Parameter unterstützt. Die URL dieses http GET Request wird automatisiert über den Parameter „#AUTH_URL#“ (ohne „“) eingetragen und muss nicht manuell hinterlegt werden. Folgende http GET Parameter werden für die BKU-Auswahl akzeptiert.

@@ -1876,9 +1880,11 @@ Einige dieser Parameter werden jedoch nicht durch den Benutzer oder dem Service <input type="submit" value=">lokale Bürgerkartenumgebung">
</form> -

Als Beispiel für ein BKU-Auswahl Template steht auch das bei MOA-ID-Auth hinterlegte Standardtemplate zur Verfügung. Dieses finden Sie hier.

4.2 Single Sign-On Anmeldeabfrage

Das Send-Assertion Template dient im Falle einer Anmeldung mittels Single Sign-On der Abfrage ob die Anmeldedaten an die betreffende Online Applikation übertragen werden dürfen. Ähnlich dem Template für die Bürgerkartenauswahl müssen auch hierbei Formvorschriften und Strukturen im Aufbau des Templates eingehalten werden.
+

Das Send-Assertion Template dient im Falle einer Anmeldung mittels Single Sign-On der Abfrage ob die Anmeldedaten an die betreffende Online Applikation übertragen werden dürfen.

Hinweis: In der Datei ./htmlTemplates/sendAssertionFormFull.html welcher sich relativ zur MOA-ID-Auth Konfigurationsdatei befindet finden Sie das Standard Template welches für den Anmeldevorgang verwendet wird, wenn kein online-applikationsspezifisches Template hinterlegt wurde. Dieses Standard Template unterstützt Responsive Design und passen sich somit in einem weiten Bereich an die aktuelle Fenstergröße an.

Ähnlich dem Template für die Bürgerkartenauswahl müssen auch hierbei Formvorschriften und Strukturen im Aufbau des Templates eingehalten werden.
Für die Übermittlung an das Modul MOA-ID-Auth ist ein http POST Request vorgesehen welcher folgende Parameter unterstützt. Die URL, an welche dieser http POST Request gesendet werden muss, wird automatisiert über den Parameter „#URL#“ (ohne „“) eingetragen und muss nicht manuell hinterlegt werden.

Name

@@ -2014,6 +2020,21 @@ Die nachfolgenden Form zeigt ein Beispiel für den Aufbau des im BKU-Auswah

Hinweis: Das in MOA-ID 1.5.1 verwendete Security-Layer Template ist kompatibel zu dem in MOA-ID 2.0 verwendeten Security-Layer Template. Jedoch stehen bei dem Template aus MOA-ID 1.5.1 die zusätzlichen Parameter zur Konfiguration mittels Konfigurationstool nicht zur Verfügung.

5 Konfiguration von MOA-SP

MOA-ID überprüft die Signaturen der Personenbindung und des AUTH-Blocks mit dem VerifyXMLSignatureRequest von MOA-SP. Dazu muss MOA-SP wie unten beschreiben konfiguriert werden.
+
+ VerifyTransformsInfoProfile
+ Der Request zum überprüfen der Signatur des AUTH-Blocks verwendet ein vordefiniertes VerifyTransformsInfoProfile. Die im Request verwendete Profil-ID wird in der MOA-ID-Auth Konfiguration im Parameter Authentfizierungsblock Transformationen definiert. Entsprechend muss am MOA-SP Server ein VerifyTransformsInfoProfile mit gleichlautender ID definiert werden. Die Profiledefinition selbst ist in der Auslieferung von MOA-ID in $MOA_ID_INST_AUTH/conf/moa-spss/profiles/MOAIDTransformAuthBlockTable_DE_2.0.xml enthalten. Diese Profildefinition muss unverändert übernommen werden.

TrustProfile
+Die Requests zur überprüfung der Signatur verwenden vordefinierte TrustProfile. Die im Request verwendete Profil-IDs werden in der MOA-ID-Auth Konfiguration in den Parametern Personenbindung Trustprofil und Authentfizierungsblock Trustprofil definiert. Diese beiden Elemente können unterschiedliche oder identische TrustProfileIDs enthalten. Am MOA-SP Server müssen TrustProfile mit gleichlautender ID definiert werden. Die Auslieferung von MOA-ID enthält das Verzeichnis $MOA_ID_INST_AUTH/conf/moa-spss/trustprofiles/MOAIDBuergerkarteRoot, das als TrustProfile verwendet werden kann. Weitere Zertifikate können als vertrauenswürdig hinzugefügt werden.

Certstore
+Zum Aufbau eines Zertifikatspfades können benötigte Zertifikate aus einem Zertifikatsspeicher verwendet werden. Die Auslieferung von MOA-ID enthält das Verzeichnis $MOA_ID_INST_AUTH/conf/moa-spss/certstore, das als initialer Zertifikatsspeicher verwendet werden kann.

Hinweis: Mit dem Wechsel auf Version 1.3 verwendet MOA SP/SS ein neues Format für die XML-Konfigurationsdatei. Für die Konvertierung einer älteren Konfigurationsdatei auf das neue Format steht Ihnen ein Tool zur Verfügung. Details dazu finden sie in der der Distribution von MOA-SP/SS beiligenden Dokumentation im Kapitel 'Konfiguration', Abschnitt 1.2.1.

6 Tomcat Security Manager

Apache Tomcat bietet die Möglichkeit den Server unter einem Security Manager zu betreiben. Damit ist es möglich den lokalen Dateizugriff zu beschränken. Mit Hilfe der Datei "catalina.policy" können so Zugriffe auf lokale Dateien und Verzeichnisse festgelegt werden. Eine beispielhafte catalina.policy Datei finden Sie im Verzeichnis $MOA_ID_INST_AUTH/tomcat. Diese Datei wurde unter Apache Tomcat 4.1.31, 5.0.28 und 5.5.27 getestet.

Mehr Informationen zum Security Manager entnehmen Sie bitte der entsprechenden Apache Tomcat Dokumentation.

A Referenzierte Spezifikation

diff --git a/id/server/doc/handbook/faq/faq.html b/id/server/doc/handbook/faq/faq.html deleted file mode 100644 index 4e9ff77a3..000000000 --- a/id/server/doc/handbook/faq/faq.html +++ /dev/null @@ -1,125 +0,0 @@ - - - - - MOA SS und SP - FAQ - - - -

- - - - - -

Dokumentation

MOA: Serversignatur (SS) und Signaturprüfung (SP)

FAQ

Inhalt

-
Allgemeines
-
-
Übersicht der Fragen
-
-
Antworten
-

1 Allgemeines

Dieses Dokument enthält eine Reihe von häufig gestellten Fragen zu Installation, Konfiguration und Verwendung von MOA Serversignatur (SS) und Signaturprüfung (SP).

2 Übersicht der Fragen

Installation

Beim Starten von MOA SPSS tritt folgende Exception auf: java.lang.ClassCastException: iaik.asn1.structures.Name. Was kann der Fehler sein? [Zur Antwort]
Ich möchte MOA SS/SP in einer Umgebung betreiben, die einen Internet-Zugang nur über einen Proxy erlaubt. Funktioniert das? [Zur Antwort]

Konfiguration

Ich möchte gerne die CRL-Archivierung von MOA verwenden, möchte aber eine andere als die in der Konfiguration erwähnte postgreSQL-Datenbank verwenden. Geht das? [Zur Antwort]
Ich möchte ein Zertifikat (z.B. einer Zwischen-Zertifizierungsstelle) manuell in den internen Zertifikatsspeicher von MOA SP importieren. Wie funktioniert das? [Zur Antwort]
Meine bestehende Konfigurationsdatei funktioniert mit MOA SP/SS 1.3 oder höher nicht mehr. Was ist passiert? - [Zur Antwort]

Verwendung

Bei der Prüfung einer Signatur liefert die Prüfung des Zertifikatsstatus den Code 1. Was kann der Fehler sein? [Zur Antwort]

3 Antworten

Installation

Beim Starten von MOA SPSS tritt folgende Exception auf: java.lang.ClassCastException: iaik.asn1.structures.Name. Was kann der Fehler sein?
-
Auf Grund einer mangelhaften Implementierung in einigen Versionen des JDK 1.3.1 kann es beim Betrieb von MOA zu folgendem Problem kommen: Sun macht in der Implementierung von PKCS7.getCertificate() einen Downcast vom Interface java.security.Principal auf die eigene Implementierung, was zu einer ClassCastException führt, wenn der JCE-Provider von Sun nicht an erster Stelle in der List der Security-Provider installiert ist. MOA geht nun aber so vor, dass der JCE-Provider des IAIK an die erste Stelle installiert wird, wenn er zum Zeitpunkt der Konfiguration noch nicht installiert war. Wird dann von irgendeinem ClassLoader der jar-Verifier benützt, wird PKCS7.getCertificate() verwendet, und es kommt zu einer ClassCastException.
-
Wird MOA über die API-Schnittstelle verwendet, ist ein Workaround die manuelle Installation des IAIK-JCE-Providers nach dem Sun JCE-Provider (etwa an die letzte Stelle), bevor die MOA-Konfiguration aufgerufen wird. Bei Verwendung der Webservices ist die Möglichkeit der statischen Konfiguration der JCE-Provider mittels Angabe in der Datei $JAVA_HOME/jre/lib/security/java.security der einzige bekannte Workaround. Hierzu müssen die Einträge
-
```
 security.provider.1=sun.security.provider.Sun
-   security.provider.2=com.sun.rsajca.Provider 
```
-
durch folgenden Eintrag ergänzt werden:
-
```
security.provider.3=iaik.security.provider.IAIK
```
-
-
Ich möchte MOA SS/SP in einer Umgebung betreiben, die einen Internet-Zugang nur über einen Proxy erlaubt. Funktioniert das?
-
Ja, zumindest für Zugriffe über HTTP. Sie müssen dazu die nachfolgenden JAVA System-Properties setzen:
-
```
http.proxyHost=<proxyhost>
-http.proxyPort=<proxyport>
-http.nonProxyHosts="<exceptionhosts>"
```
-
<proxyhost> gibt den Namen oder die IP-Adresse des Proxies an.
-
<proxyport> gibt den Port des Proxies an.
-
<exceptionhosts> enthält eine Liste von Rechnernamen, die nicht über den Proxy laufen sollen. Jedenfalls müssen sie hier localhost angeben. Einzelne Namen sind durch eine Pipe (|) zu trennen. Bitte beachten Sie, dass IP-Addressen nicht angegeben werden dürfen, sowie die verpflichtend zu verwendenen Anführungszeichen.
-
-

Konfiguration

Ich möchte gerne die CRL-Archivierung von MOA verwenden, möchte aber eine andere als die in der Konfiguration erwähnte postgreSQL-Datenbank verwenden. Geht das?
-
Ja, das ist möglich. Wenn Sie eine mySQL-Datenbank verwenden möchten, sind folgende Maßnahmen zu treffen:
-
- Laden Sie den mySQL-JDBC-Connector herunter und fügen Sie das im Download enthaltene jar-File mysql-connector-java-3.x.x-stable-bin.jar zum Klassenpfad für MOA SPSS hinzu.
- Geben Sie im MOA-Konfigurationsfile mit Hilfe des generischen Konfigurationsparameters DataBaseArchiveParameter.JDBCUrl eine gültige JDBC-URL zu Ihrer mySQL-Datenbank angeben. Hinweise zum Format dieser URL für mySQL finden Sie hier.
-
Wenn Sie eine andere Datenbank verwenden möchten, beispielsweise Oracle, gehen Sie sinngemäß wie oben vor und setzen zusätzlich noch folgenden Schritt:
-
- Geben Sie im MOA-Konfigurationsfile mit Hilfe des generischen Konfigurationsparameters DataBaseArchiveParameter.JDBCDriverClass den vollständig qualifizierten Klassennamen des JDBC-Treibers an, der die Verbindung zu Ihrer Datenbank herstellt.
-
-
Ich möchte ein Zertifikat (z.B. einer Zwischen-Zertifizierungsstelle) manuell in den internen Zertifikatsspeicher von MOA SP importieren. Wie funktioniert das?
-
Sie können für diesen Zweck ein mit MOA SP/SS mitgeliefertes Kommandozeilen-Tool verwenden, das Sie im Verzeichnis $MOA_SPSS_INST/tools finden. Wechseln Sie zu diesem Verzeichnis und rufen Sie die Script-Datei certtools.bat bzw. certtools.sh (je nach Betriebssystem) auf. Achten Sie darauf, dass die Umgebungsvariable $JAVA_HOME korrekt gesetzt ist. Die Syntax für dieses Tool lautet:
-
```
certtool -add <cert> <store>
```
-
<cert> bezeichnet dabei Pfad und Dateiname des zu importierenden X509-Zertifikats. Das Zertifikat muss DER-kodiert vorliegen.
-
<store> bezeichnet den Pfad des internen Zertifikatsspeichers von MOA SP. Wenn Sie nach der Installationsanleitung vorgegangen sind, lautet dieser Pfad $CATALINA_HOME/conf/moa-spss/certstore.
-
-
- Meine bestehende Konfigurationsdatei - funktioniert mit MOA SP/SS 1.3 oder höher nicht mehr. Was ist passiert?
-
Mit dem Wechsel auf Version 1.3 verwendet MOA SP/SS ein neues, übersichtlicheres Format für die - XML-Konfigurationsdatei.
-
Wenn Sie von einer älteren Version von MOA SP/SS auf die Version 1.3 wechseln und Ihre bestehende - Konfiguration beibehalten wollen, steht Ihnen ein einfaches Kommandozeilenwerkzeug zur Verfügung, mit - dem Sie Ihre Konfigurationsdatei vom bisherigen auf das neue Format migrieren können.
-
Informationen zur Verwendung des Werkzeugs finden Sie in Abschnitt 1.2.1 des Konfigurationshandbuchs.
-

Verwendung

Bei der Prüfung einer Signatur liefert die Prüfung des Zertifikatsstatus den Code 1. Was kann der Fehler sein?
-
Dieser Fehlercode bedeutet: Es konnte keine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konstruiert werden. Das kann grundsätzlich eine der beiden folgenden Ursachen haben:
-
- Keines der Zertifikate in der Kette vom Signatorzertifikat bis zu einem selbstsignierten Wurzelzertifikat ist im anzuwendenden TrustProfile enthalten.
- Die Zertifikatskette konnte nicht bis zu einem im anzuwendenden TrustProfile enthaltenen vertrauenswürdigen Zertifikat gebildet werden.
-
Prüfen Sie also zunächst, ob sie im anzuwendenden TrustProfile ein passendes vertrauenswürdiges Zertifikat konfiguriert haben. Das kann beispielsweise das Zertifikat jener CA sein, die das Signatorzertifikat ausgestellt hat, oder aber auch das Zertifikat einer CA weiter oben in der Hierarchie des Zertifizierungsdiensteanbieters, beispielsweise das selbstsignierte Wurzelzertifikat.
-
Wenn diese Prüfung das Problem nicht behebt, gelingt des MOA SP vermutlich nicht, ein für die Bildung der Zertifikatskette notwendiges Zertifikat zu lokalisieren. Mögliche Gründe sowie Lösungsmöglichkeiten dafür sind:
-
- Das aktuell letzte Zertifikat in der bereits gebildeten Zertifikatskette besitzt zwar die Zertifikatserweiterung AuthorityInformationAccess mit einem Hinweis auf das nächste Zertifikat der zu bildenden Kette, das darin per URL referenzierte Zertifikat kann jedoch nicht geladen werden. Prüfen Sie daher zunächst, ob MOA SP/SS per HTTP oder LDAP Zugriffe nach außen tätigen darf.
- Das aktuell letzte Zertifikat in der bereits gebildeten Zertifikatskette besitzt keine Zertifikatserweiterung AuthorityInformationAccess mit einem Hinweis auf das nächste Zertifikat der zu bildenden Kette, und auch im internen Zertifikatsspeicher von MOA SP ist das nächste Zertifikat nicht enthalten. Ist Ihnen das nächste Zertifikat bekannt (z.B. durch manuellen Download von der Webseite des Zertifizierungsdiensteanbieters), können Sie es manuell in den internen Zertifikatsspeicher importieren. Eine Anleitung dazu finden Sie hier.
  -
-

- - diff --git a/id/server/doc/handbook/index.html b/id/server/doc/handbook/index.html index 12c598c9d..5ffd1ebeb 100644 --- a/id/server/doc/handbook/index.html +++ b/id/server/doc/handbook/index.html @@ -26,8 +26,13 @@

Erläuterung aller Konfigurationsoptionen sowie Leitfaden für häufige Konfigurationsaufgaben.

Protokolle

Erläuterung der unterstützen Authentifizierungsprotokolle.

FAQ

Häufig gestellte Fragen zu Installation, Konfiguration und Anwendung.

Anwendungen

Erläutert die Integration in bestehende Online-Applikationen und beschreibt die beigelegten Demo Applikationen

Zusatzinformationen

Spezifiziert allgemeine Funktionen des Modules MOA-ID-Auth

+ +

diff --git a/id/server/doc/handbook/install/install.html b/id/server/doc/handbook/install/install.html index a109fb6a7..3d3b8b68d 100644 --- a/id/server/doc/handbook/install/install.html +++ b/id/server/doc/handbook/install/install.html @@ -2,7 +2,7 @@ - MOA SS und SP - Installation + MOA-ID - Installation < @@ -23,7 +23,7 @@

Übersicht

MOA-ID-Auth

MOA-ID-Auth und MOA-ID-Configuration

Basisinstallation
-
1.1 Externe Services
-
Für die Anmeldung in Vertretung und die Anmeldung ausländischer Personen werden zusätzliche externe Services verwendet.
-
1.1.1 Online-Vollmachten
-
Ab der MOA-ID Release 1.5.0 werden Online-Vollmachten (für Anwendungen aus dem öffentlichen Bereich) unterstützt. Hierzu werden diese Vollmachten über eine Online-Vollmachten-Service ausgewählt. Der Zugang zu diesem Online-Vollmachten Service ist über eine Client-Server Authentifizierung abgesichert. Als Client-Zertifikate werden Zertifikate der Firmen A-Trust bzw. A-CERT, die mit der Verwaltungs- oder Dienstleistereigenschaft versehen sind, akzeptiert.
-
1.1.2 Ausländische Bürger
+
1.1 Externe Services
+
Für die Anmeldung in Vertretung und die Anmeldung ausländischer Personen werden zusätzliche externe Services verwendet.
+
1.1.1 Online-Vollmachten
+
Ab der MOA-ID Release 1.5.0 werden Online-Vollmachten (für Anwendungen aus dem öffentlichen Bereich) unterstützt. Hierzu werden diese Vollmachten über eine Online-Vollmachten-Service ausgewählt. Der Zugang zu diesem Online-Vollmachten Service ist über eine Client-Server Authentifizierung abgesichert. Als Client-Zertifikate werden Zertifikate der Firmen A-Trust bzw. A-CERT, die mit der Verwaltungs- oder Dienstleistereigenschaft versehen sind, akzeptiert.
+
1.1.2 Ausländische Bürger

Ab der MOA-ID Release 1.4.7 ist es möglich, dass sich auch ausländische Bürger mittels MOA-ID einloggen können. Hierzu wird eine Verbindung zu einem sogenannten Stammzahlenregister-Gateway aufgebaut, dass basierend auf den Zertifikatsdaten des ausländischen Bürgers eine Eintragung im Ergänzungsregister für natürliche Personen gemäß E-Government Gesetz §6(5) vornimmt. Somit ist es möglich, dass eine Personenbindung ausgestellt werden kann, die in weitere Folge an MOA-ID weitergeleitet wird. Der Zugang zu diesem Stammzahlenregister-Gateway ist über eine Client-Server Authentifizierung abgesichert. Als Client-Zertifikate werden Zertifikate der Firmen A-Trust bzw. A-CERT, die mit der Verwaltungs- oder Dienstleistereigenschaft versehen sind, akzeptiert.
-
2 MOA-ID-Auth
+
2 MOA-ID-Auth

Das Modul MOA-ID-Auth dient der Identifizierung und Authentifizierung im Rahmen eines Anmeldevorgangs an einer Online-Applikation. Die Identifizierung und Authentifizierung erfolgt mit Bürgerkartem, Handy-Signatur oder für ausändische Personen mittels STORK.

Die Funktionalität und der Aufbau der Schnittstellen des Modules MOA-ID-Auth in Richtung Online-Applikation wird im Kapitel Protokolle beschriebe.
Für den Betrieb von MOA-ID-Auth ist der Einsatz von MOA-Signaturprüfung (MOA-SP) erforderlich.
-
2.1 Ablauf einer Anmeldung
+
2.1 Ablauf einer Anmeldung

Die nachfolgende Grafik beschreibt den Ablauf eines Abmeldevorgangs an einer Online-Applikation mit Hilfe von MOA-ID-Auth unter Verwendung der Bürgerkarte oder der Handy-Signatur.

@@ -81,7 +89,7 @@
MOA-ID-Auth sendet die Anmeldedaten an den Service-Provider und setzt im Browser des Benutzers ein SSO Session-Tokken welches für weitere Anmeldevorgänge verwendet werden kann.
Die Anmeldedaten werden vom Service-Provider verarbeitet und der Benutzer wird vom Service-Provider an die Online-Applikation weitergeleitet.

3 MOA-ID-Configuration

Das Modul MOA-ID-Configuration stellt eine web-basierte Benutzerschnittstelle zur Konfiguration des Moduls MOA-ID-Auth zur Verfügung, wobei sich die Konfiguration in zwei Teilbereiche unterteilt ist. Eine detailierte Aufstellung der einzelnen Konfigurationspunkte befindet sich im Kapitel Konfiguration.

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

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

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 Logout	LogOut	https://<host>:<port>/moa-id-auth/LogOut + http://<host>:<port>/moa-id-auth/LogOut

Protokoll

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

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.

- +

- + - + - + - + - + +

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

Protokolle				Beschreibung	Beschreibung
PVP 2.1	PVP 2.1	OpenID Connect				SAML 1	SAML 1
PVP 2.1	PVP 2.1	Name	Name			SAML 1	SAML 1	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

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

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

1.4 SSO Logout

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.

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.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

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 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.html	Optional: URL auf die HTML Vorlage für den Security-Layer Request, welcher für die Kommunikation mit der Bürgerkartenumgebumg verwendet wird. Die URL muss in der online-applikationsspezifischen Konfiguration von MOA-ID-Auth hinterlegt werden (siehe Parameter SecurityLayerTemplates). + 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.

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

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.
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.
Der Service Provider extrahiert Informationen aus den Metadaten und generiert einen Authentifizierungsrequest und sendet diesen über den Browser an das Modul MOA-ID-Auth.
MOA-ID Auth holt die Metadaten des Service Providers und validiert die Signatur der Metadaten mit dem in der MOA-ID-Auth Konfiguration für diesen Service Provider (Online-Applikation) hinterlegten Zertifikat. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
MOA-ID-Auth validiert den Authentifizierungsrequest mit den Informationen aus dem Metadaten des Service Providers. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
MOA-ID-Auth leitet die BenutzerIn oder den Benutzer zur Bürgerkartenauswahl. +
1. Die BenutzerIn oder der Benutzer Authentifiziert sich mit der gewählten Methode.
+
War die Authentifizierung der BenutzerIn oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers.
MOA-ID-Auth senden die Assertion über den Browser an den Service Provider.
Der Service Provider validiert die Assertion mit den Informationen aus den Metadaten des Modules MOA-ID-Auth. +
1. Ist die Validierung erfolgreich wird die BenutzerIn oder der Benutzer an der Online-Applikation angemeldet.
+

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

+ + + + + + + + + + + + + +

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 (sie 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.

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

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`
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. 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`
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 bereichsspezifikschen Personkennzeichens (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.

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.

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

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.
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.
Der Service Provider generiert den AuchCode Request und sendet diesen über den Browser an das Modul MOA-ID-Auth.
MOA-ID-Auth validiert den AuthCode Request.
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. -

Die AuthCode Response wird mittels Redirect an den Service Provider retourniert.

Der Service Provider generiert den AccessToken Request und sendet diesen an MOA-ID-Auth zum Abholen der Benutzerdaten.
MOA-ID-Auth validiert den AccessToken Request

MOA-ID-Auth generiert die AccessToken Response -

Retournierung der AccessToken Response an den Service Provider

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.

Identifikatior aus der Konfiguration

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.

Identifikatior aus der Konfiguration

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

Der Benutzer verbindet sich zu einem Web-Portal (Service Provider) über das die Online-Applikation erreichbar ist.
Der Service Provider antwortet mit einer öffentlichen Portalseite welche einen Login Bereich mit Bürgerkartenauswahl beinhaltet.
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.
MOA-ID-Auth validiert den StartAuthentication Request. Ist die Validierung erfolgreich wird der Anmeldevorgang vorgesetzt.
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.
+
War die Authentifizierung der BenutzerIn oder des Benutzers erfolgreich generiert MOA-ID-Auth die Assertion mit den Anmeldedaten des Benutzers.
MOA-ID-Auth senden das SAML 1 Artifact, welches zur Abholung der Assertion verwendet werden kann, über den Browser an den Service Provider.
Der Service Provider stellt einen GetAuthenticationData Request an MOA-ID-Auth unter Verwendung des zuvor übermittelten Artifacts.
MOA-ID-Auth validiert das Artifact. Ist die Validierung erfolgreich antwortet MOA-ID-Auth mit der SAML 1 Assertion, welche die Anmeldedaten beinhaltet.
Der Service Provider verarbeitet die Assertion und danach ist der Benutzer an der Online-Applikation angemeldet.

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

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.

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.

SAML 1.0 Protocol Schema
+
SAML 1.0 Assertion Schema

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

A Referenzierte Spezifikation

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ + + + Document identifier: cs-sstc-schema-assertion-01 + Location: http://www.oasis-open.org/committees/security/docs/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ + + + + Document identifier: cs-sstc-schema-protocol-01 + Location: http://www.oasis-open.org/committees/security/docs/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Name	`/saml2p:AuthnRequest/@ID`
Gebrauch	Ein Mal
Erläuterung	Dieses Attribut beinhaltet einen vom Service Provider generierten Identifikator für diesen Authentifizierungsrequest.

Inhalt

1 Datenmanagement

1.1 Sessiondaten

1.1.1 Allgemein

1.1.2 Single Sign-On

1.2 Logging von Statistikdaten

Inhalt

1 Allgemeines

2 Integration in bestehende Online-Applikationen

2.1 Bürgerkartenauswahl

2.1.1 Request aus einem iFrame

2.1.2 Request aus dem Hauptframe

2.2 Single Sign-On Anmeldeabfrage

3 Demo Applikationen

3.1 PVP 2.1 Demo

3.1.1 Installation

3.1.1.1 Einsatz der Demo Applikation in Tomcat

3.1.1.2 Einsatz der Demo Applikation in Tomcat

3.1.2 Konfiguration Demo Applikation

3.1.3 Konfiguration von MOA-ID-Auth

3.1.4 Anwendung

1 Übersicht

3.1.2 Default BKUs

3.1.6 MOA-SP

3.1.10.2 Legacy Modus

3.1.10.3 SAML1 Konfiguration

3.1.11 Security-Layer Transformationen

3.2 Online Applikationen

3.2.1 Informationen zur Online-Applikation (Service Provider)

3.2.6 Authentifizierungsprotokolle

3.2.6.1 SAML1

3.2.7 Zusätzliche allgemeine Einstellungen

4 Templates

4.1 Bürgerkartenauswahl

4.2 Single Sign-On Anmeldeabfrage

5 Konfiguration von MOA-SP

6 Tomcat Security Manager

A Referenzierte Spezifikation

Inhalt

1 Allgemeines

2 Übersicht der Fragen

Installation

Konfiguration

Verwendung

3 Antworten

Installation

Konfiguration

Verwendung

1 Übersicht

2 MOA-ID-Auth

2 MOA-ID-Auth und MOA-ID-Configuration

2.1 Basisinstallation

2.1.1 Einführung

2.1.2.4 Einsatz des Moduls MOA-ID-Configuration in Tomcat

Inhalt

1.1 Externe Services

1.1.1 Online-Vollmachten

1.1.2 Ausländische Bürger

1.1 Externe Services

1.1.1 Online-Vollmachten

1.1.2 Ausländische Bürger

2 MOA-ID-Auth

2 MOA-ID-Auth

2.1 Ablauf einer Anmeldung

2.1 Ablauf einer Anmeldung

3 MOA-ID-Configuration

3 MOA-ID-Configuration

Inhalt

Inhalt

1 Allgemeines

1.1 Übersicht der Zugangspunkte

1.1 Übersicht der Zugangspunkte

1.2 Übersicht der möglichen Attribute

1.3 Single Sign-On

1.4 SSO Logout

1.5 Legacy Request (Bürgerkartenauswahl beim Service Provider)

2 PVP 2.1

2.1 Ablauf einer Anmeldung mittels PVP 2.1

2.2 Metadaten

2.3.2 Authentifizierungsresponse