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 --- .../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 5 files changed, 213 insertions(+) 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 (limited to 'id/server/doc/handbook/application') 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 -- cgit v1.2.3 From dbe8a0c9de38328675852968f2f694a70b0395f1 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Wed, 5 Mar 2014 20:19:50 +0100 Subject: fix some handbook typos --- .../doc/handbook/application/application.html | 33 +++++++++++----------- 1 file changed, 16 insertions(+), 17 deletions(-) (limited to 'id/server/doc/handbook/application') diff --git a/id/server/doc/handbook/application/application.html b/id/server/doc/handbook/application/application.html index 0b39077f7..83e301089 100644 --- a/id/server/doc/handbook/application/application.html +++ b/id/server/doc/handbook/application/application.html @@ -46,43 +46,42 @@

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

Das erste Kapitel behandelt die Integration der von MOA-ID-Auth generierten Bürgerkartenauswahl in bestehende Online-Applikationen. Zusätzlich zur Beschreibung ist MOA-ID auch eine PVP 2.1 Demo Applikation beigelegt. Die Konfiguration und Verwendung dieser Demo Applikation ist Inhalt des letzten Kapitels.

2 Integration in bestehende Online-Applikationen

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 individualisiert werden um die Integration weiter zu verfeinern.

2.1 Bürgerkartenauswahl

Die Bürgerkartenauswahl wird ab MOA-ID 2.0 standardmäßig von MOA-ID-Auth, als Antwort auf einen eingehenden Authentifizierungsrequest, 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 in der Online-Applikation des Service Providers steht jedoch weiterhin als Legacy Variante zur Verfügung.

Die Integration der von MOA-ID-Auth bereitgestellten Bürgerkartenauswahl in eine bestehende Online-Applikation kann auf zwei Arten erfolgen. Bei beiden Varianten erfolgt der Login Vorgang (senden des Authentifizierungsrequests an MOA-ID-Auth) durch den Klick auf einen Login Button. Die Auswahl der Bürgerkartenumgebung erfolgt somit erst im zweiten Schritt. 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 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

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 (Service Providera). 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 zum Kapitel 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 von MOA-ID-Auth generiert werden muss 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

Hinweis: Der Source Code der PVP 2.1 Demo Applikation ist im Order $MOA_ID_AUTH_INST/source/moa-id-oa verfügbar. Jedoch ist die Validierung der PVP 2.1 Assertion in dieser Version nicht vollständig implementiert und müsste bei Verwendung in einem Produktivsystem noch erweitert werden.

3.1.1 Installation

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