From 9753d2e1c9fde6778e070825b141e0e69323c9b6 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Tue, 4 Mar 2014 23:21:46 +0100 Subject: *handbook: some updates and corrections --- id/server/doc/handbook/config/config.html | 36 ++++++++++++++++--------------- 1 file changed, 19 insertions(+), 17 deletions(-) (limited to 'id/server/doc/handbook/config') diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index 52b894fe4..b307bb60a 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -163,7 +163,7 @@

Optional kann nach dem Schritt 3 Basiskonfiguration des Modules MOA-ID-Auth eine bestehende MOA-ID 1.5.1 Konfiguration importiert werden. Für bestehende Konfigurationen < 1.5.1 wird eine vollständige Neukonfiguration empfohlen.

2 Basiskonfiguration

-

Die Basiskonfiguration für die Module MOA-ID-Auth und MOA-ID-Configuration erfolgt mit Hilfe einer textuellen propertie Datei. Diese Propertie Dateien beinhalten alle Konfigurationsparameter welche für den Start der Module erforderlich sind und müssen der Java Virtual Machine durch eine System Property mitgeteilt werden. Alle Änderungen die an der Basiskonfiguration vorgenommen werden erfordern einen Neustart der jeweiligen Java Virtual Machine.

+

Die Basiskonfiguration für die Module MOA-ID-Auth und MOA-ID-Configuration erfolgt mit Hilfe textueller propertie Dateien. Diese Propertie Dateien beinhalten alle Konfigurationsparameter welche für den Start der Module erforderlich sind und müssen der Java Virtual Machine durch eine System Property mitgeteilt werden. Alle Änderungen die an der Basiskonfiguration vorgenommen werden erfordern einen Neustart der jeweiligen Java Virtual Machine.

2.1 MOA-ID-Configuration

Dieser Abschnitt behandelt die Basiskonfiguration des Modules MOA-ID-Configuration. Der erste Teilabschnitt behandelt die Bekanntmachung der Konfigurationsdatei mittels einer System Property und der zweite Teilabschnitt beschreibt die einzelnen Konfigurationsparameter im Detail. Eine Konfiguration die als Ausgangspunkt für die individuelle Konfiguration verwendet werden kann finden Sie hier.

2.1.1 Bekanntmachung der Konfigurationsdatei

@@ -202,7 +202,7 @@

2.1.2.2 Datenbankzugriff

-

Diese Konfigurationsparameter sind nicht optional und müssen in der Konfigurationsdatei enthalten sein und individuell angepasst werden. Für Beispielkonfiguration wurde mySQL als Datenbank verwendet wodurch sich die Konfigurationsparameter auf mySQL beziehen. Das Modul MOA-ID-Configuration kann jedoch auch mit Datenbanken anderer Hersteller betrieben werden. Hierfür wird jedoch auf die Hibernate Dokumention verwiesen, welches im Module MOA-ID-Configuration für den Datenbankzugriff verwendet wird.

+

Diese Konfigurationsparameter sind nicht optional und müssen in der Konfigurationsdatei enthalten sein und individuell angepasst werden. Für die Beispielkonfiguration wurde mySQL als Datenbank verwendet wodurch sich die Konfigurationsparameter auf mySQL beziehen. Das Modul MOA-ID-Configuration kann jedoch auch mit Datenbanken anderer Hersteller betrieben werden. Hierfür wird jedoch auf die Hibernate Dokumention verwiesen, welches im Module MOA-ID-Configuration für den Datenbankzugriff verwendet wird.

@@ -238,7 +238,7 @@

 

Die Beispielkonfiguration beinhaltet noch zusätzliche Konfigurationsparameter für den Datenbankzugriff welche direkt aus der Beispielkonfiguration übernommen werden können. Eine detaillierte Beschreibung der einzelnen Einstellungsparameter kann der Hibernate Dokumention entnommen werden.

2.1.2.3 Bürgerkarten LogIn

-

Zusätzlich zur Authentifizierung mittels Benutzername und Passwort unterstützt das Modul MOA-ID-Configuration auch eine Authentifizierung mittels Bürgerkarte oder Handy-Signatur unter Verwendung des Authentifizierungsprotokolls PVP2.1. Wenn eine Authentifizierung mittels Bürgerkarte oder Handy-Signatur gewünscht wird müssen die nachfolgen Konfigurationsparameter gesetzt werden.

+

Zusätzlich zur Authentifizierung mittels Benutzername und Passwort unterstützt das Modul MOA-ID-Configuration auch eine Authentifizierung mittels Bürgerkarte oder Handy-Signatur unter Verwendung des Authentifizierungsprotokolls PVP2.1. Wenn eine Authentifizierung mittels Bürgerkarte oder Handy-Signatur gewünscht wird müssen die nachfolgen Parameter konfiguriert werden.

Name
@@ -432,6 +432,7 @@ https://<host>:<port>/moa-id-configuration/servlet/metadata https://<host>:<port>/moa-id-configuration/secure/usermanagementInit.action

Mit Hilfe dieser Benutzerverwaltung kann ein neuer Benutzeraccount am Konfigurationstool angelegt und ein Kennwort für den Benutzer vergeben werden. Zusätzlich müssen dem neu erstellte Benutzer die Eigenschaften aktiv und admin zugewiesen werden. Nach dem speichern wird der neu angelegte Benutzer in der Liste aller vorhandenen Benutzern dargestellt.

Hiermit ist die Initialisierung des Moduls MOA-ID-Configuration abgeschlossen und die Authentifizierung kann wieder aktiviert werden (siehe general.login.deaktivate Abschnitt 2.2.2.1). Anschließend muss die Java Virtual Machine, in welchem das Modul MOA-ID-Configuration betrieben wird, neu gestartet werden.

+

Hinweis: Ein Betrieb des Moduls MOA-ID-Configuration ohne Authentifizierung ist ebenfalls möglich. In diesem Fall wird jedoch empfohlen den Zugriff auf das Konfigurationstool mit anderen Mitteln einzuschränken.

2.1.4 Benutzerverwaltung

Das Modul MOA-ID-Configuration unterstützt die Benützung und Verwaltung unterschiedlicher Benutzeraccounts. Hierfür stellt die Web-Oberfläche des Modules MOA-ID-Configuration ein spezielles Interface zur Benutzerverwaltung zur Verfügung.

2.1.4.1 Einen neuen Benutzer erstellen

@@ -503,11 +504,11 @@ https://<host>:<port>/moa-id-configuration/secure/usermanagementInit
  1. Durch Administrator: Bei dieser Variante wird der neue Benutzeraccount durch einen Administrator über die Web-Oberfläche erstellt und aktiviert. In diesem Fall müssen alle geforderten Daten durch den Administrator eingetragen werden. Bei dieser Variante ist die Validierung der eMail Adresse nicht zwingend erforderlich, kann jedoch optional aktiviert werden.
    2. -
  2. Durch PVP 2.1 Login: Bei dieser Variante wird die Generierung eines neues Benutzeraccounts durch einen Loginversuch mittels Bürgerkarte oder Handy-Signatur ausgelöst. Nach erfolgreicher Authentifizierung wird die BenutzerIn /der Benutzer an Konfigurationstool weitergeleitet. Hierbei wird geprüft ob aktuell ein Benutzeraccount für diese Person existiert. Wenn kein Account existiert wird die BenutzerIn / der Benutzer aufgefordert die fehlenden Informationen für die Registrierung eines neuen Benutzeraccounts einzutragen. In diesem Fall muss die eMail Adresse durch die BenutzerIn / den Benutzer zwingend validiert werden wofür der Mailversand am Module MOA-ID-Configuration konfiguriert sein muss. Nach erfolgreicher Validierung der eMail Adresse ist der Benutzeraccount als nicht aktiv registriert und muss anschließend durch einen Administrator aktiviert werden. Erst nach erfolgreicher Aktivierung ist eine gültige Anmeldung möglich.
    +
  3. Durch PVP 2.1 Login: Bei dieser Variante wird die Generierung eines neues Benutzeraccounts durch einen Loginversuch mittels Bürgerkarte oder Handy-Signatur ausgelöst. Nach erfolgreicher Authentifizierung wird die BenutzerIn / der Benutzer an Konfigurationstool weitergeleitet. Hierbei wird geprüft ob aktuell ein Benutzeraccount für diese Person existiert. Wenn kein Account existiert wird die BenutzerIn / der Benutzer aufgefordert die fehlenden Informationen für die Registrierung eines neuen Benutzeraccounts einzutragen. In diesem Fall muss die eMail Adresse durch die BenutzerIn / den Benutzer zwingend validiert werden wofür der Mailversand am Module MOA-ID-Configuration konfiguriert sein muss. Nach erfolgreicher Validierung der eMail Adresse ist der Benutzeraccount als nicht aktiv registriert und muss anschließend durch einen Administrator aktiviert werden. Erst nach erfolgreicher Aktivierung ist eine gültige Anmeldung möglich.
    Sollte die Validierung der eMail Adresse nicht innerhalb des in Abschnitt 2.2.1.1 konfigurierten Zeitraums erfolgen, wird die Benutzeranforderung automatisch gelöscht und die BenutzerIn / der Benutzer muss sich erneut am Konfigurationstool registrieren.

2.1.4.2 Benutzerrechte

-

Alle Benutzer die Admin–Rechte (Eigenschaft admin) besitzen haben vollen Zugriff auf die gesamte Konfiguration der verwalteten MOA-ID-Auth Instanz. Benutzer ohne Admin-Rechten stehen folgende Operationen nicht oder nur eingeschränkt zur Verfügung.

+

Alle Benutzer die Admin–Rechte (Eigenschaft admin) besitzen haben vollen Zugriff auf die gesamte Konfiguration der verwalteten MOA-ID-Auth Instanz. Benutzer ohne Admin-Rechten stehen nur folgende Operationen zur Verfügung wobei diese auch besondere Einschränkungen aufweisen können.

Name

 

-

Wenn das interne Monitoring aktiviert wurde kann ein Testvorgang durch folgende Adresse gestartet werden.

+

Wenn das interne Monitoring aktiviert wurde kann ein Testvorgang durch einen Aufruf der folgenden Adresse gestartet werden.

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

bzw. 

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

 

2.2.2.3 Protokolle

-

MOA-ID-Auth unterstützt mehrere Authentifizierungsprotokolle zwischen einer Online-Applikation und MOA-ID-Auth. Manche dieser Protokolle benötigen Schlüssel zur Signierung von Authentifizierungsdaten. In diesem Abschnitt erfolgt die Konfiguration des zu verwendeten Schlüsselmaterials.

+

MOA-ID-Auth unterstützt mehrere Authentifizierungsprotokolle. Manche dieser Protokolle benötigen Schlüssel zur Signierung von Authentifizierungsdaten oder Metadaten. In diesem Abschnitt erfolgt die Konfiguration des zu verwendeten Schlüsselmaterials.

2.2.2.3.1 PVP 2.1
@@ -850,7 +851,7 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet

Detailinformationen zur Konfiguration der STORK Erweiterung für das Modul MOA-ID-Auth entnehmen Sie bitte der STORK Spezifikation.

3 Konfiguration MOA-ID-Auth

Dieses Abschnitt beschreibt die Konfiguration des Modules MOA-ID-Auth mithilfe der durch das Modul MOA-ID-Configuration zur Verfügung gestellten Web-Oberfläche. Hierzu muss das Konfigurationstool (Module MOA-ID-Konfiguration) bereits installiert und konfiguriert sein (siehe Kapitel 2.1). Nach erfolgreichem Login am Konfigurationstool kann das Modul MOA-ID-Auth über die Web-Oberfläche konfiguriert werden.

-

Die Konfiguration von MOA-ID-Auth ist in zwei Teilbereiche unterteilet. Diese behandeln die Allgemeine Konfiguration der MOA-ID-Auth Instanz und die Konfiguration von Online-Applikationen (Service Providern) die dieser MOA-ID-Auth Instanz zugeordnet sind.

+

Die Konfiguration von MOA-ID-Auth ist in zwei Teilbereiche unterteilet. Diese behandeln die Allgemeine Konfiguration der MOA-ID-Auth Instanz und die Konfiguration von Online-Applikationen (Service Providern) welche dieser MOA-ID-Auth Instanz zugeordnet sind.

3.1 Allgemeine Konfiguration

Die Allgemeine Konfiguration des Modules MOA-ID-Auth umfasst alle nicht online-applikationsspezifischen Konfigurationsparameter. Die Konfiguration dieser Parameter erfolgt über eine Web-Oberfläche, welche Eingabefelder für jeden Konfigurationsparameter zur Verfügung stellt. Jedes Eingabefeld wird validiert bevor der Konfigurationsparameter in der Datenbank gespeichert wird. Die Validierung erfolgt auf Basis des zu erwartenden Eingabewerts, wobei der erlaubte Zeichensatz für freidefinierbare textuelle Eingabefelder eingeschränkt sein kann. Detailinformationen zum erlaubten Zeichen finden Sie bei der jeweiligen Beschreibung des Konfigurationsparameters.

@@ -974,8 +975,8 @@ Checking

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

+

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

@@ -1291,8 +1292,8 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der

 

Hinweis: Wird die Online-Applikation durch eine BenutzerIn oder einem Benutzer ohne die Role admin angelegt, wird vor der Speicherung überpüft ob die Online-Applikation alle Anforderungen an eine öffentliche Applikation erfüllt. Die Überprüfung erfolgt auf Basis des eindeutigen Identifikators (Public-URL PRefix) der Online-Applikation und es muss mindestens eine der folgenden Anforderungen erfüllt sein.

- + - +
Name   X XDieses Feld erlaubt die Konfiguration einer online-applikationsspezifischen Templates für die Bürgerkartenauswahl. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus Kapitel 4.1 umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen. Dieses Feld erlaubt die Konfiguration eines online-applikationsspezifischen Templates für die Bürgerkartenauswahl. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus Kapitel 4.1 umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen.
Send-Assertion Template   X XDieses Feld erlaubt die Konfiguration einer online-applikationsspezifischen Templates für die zusätzliche Anmeldeabfrage im Falle einer Single Sign-On Anmeldung. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus Kapitel 4.2 umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen.Dieses Feld erlaubt die Konfiguration eines online-applikationsspezifischen Templates für die zusätzliche Anmeldeabfrage im Falle einer Single Sign-On Anmeldung. Dieses Template muss in die Konfiguration hochgeladen werden und muss die Mindestanforderungen aus Kapitel 4.2 umsetzen. Da diese Templates direkt in den Authentifizierungsprozess eingreifen und diese somit eine potentielle Angriffsstelle für Cross-Site Scripting (XSS) bieten wird die Verwendung von online-applikationsspezifischen Templates nicht empfohlen.

3.2.3 Vollmachten

@@ -1563,7 +1564,8 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der 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. +

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

Infos zum Zertifikat @@ -1866,7 +1868,7 @@ Einige dieser Parameter werden jedoch nicht durch den Benutzer oder dem Service


- Die nachfolgenden Beispiele zeigen ein Beispiel für den Aufbau des im BKU-Auswahl Template zu verwendeten http GET Request Templates für die lokale BKU.

+ Die nachfolgenden Form zeigt ein Beispiel für den Aufbau des im BKU-Auswahl Template zu verwendeten http GET Request Templates für die lokale BKU.

<form method="get"  id="moaidform" action="#AUTH_URL#">

        <input type="hidden" name="bkuURI"  value="#LOCAL#"> 

        <input type="hidden" name="useMandate"  id="useMandate"> 

@@ -1941,7 +1943,7 @@ Einige dieser Parameter werden jedoch nicht durch den  Benutzer oder dem Service
   
 
 


-Die nachfolgenden Beispiele zeigen ein Beispiel für den Aufbau des im  BKU-Auswahl Template zu verwendeten http GET Request Templates für die lokale  BKU.

+Die nachfolgenden Form zeigt ein Beispiel für den Aufbau des im  BKU-Auswahl Template zu verwendeten http GET Request Templates für die lokale  BKU.

 
<form method="post"  id="moaidform_yes" action="#URL#">

        <input type="hidden" name="value"  value="true">

        <input type="hidden" name="mod"  value="#MODUL#">

-- 
cgit v1.2.3