From 5d7f7f3b6fc2fb8f8f72f359b0adb738e851d631 Mon Sep 17 00:00:00 2001 From: Thomas Lenz Date: Mon, 16 Jul 2018 13:12:39 +0200 Subject: update handbook, readme, history, example configuration, ... --- id/server/doc/handbook/config/config.html | 233 +++++++++++++++++++++++++----- 1 file changed, 193 insertions(+), 40 deletions(-) (limited to 'id/server/doc/handbook') diff --git a/id/server/doc/handbook/config/config.html b/id/server/doc/handbook/config/config.html index 26925709e..ea9eab017 100644 --- a/id/server/doc/handbook/config/config.html +++ b/id/server/doc/handbook/config/config.html @@ -76,7 +76,9 @@
  • Testing
    • +
  • Security Layer für mobile Authententifizierung
  • SZR Client für STORK <-> PVP Gateway Betrieb
    • +
  • Weitere optionale Konfigurationsparameter
    • @@ -118,6 +120,7 @@
  • BKU Konfiguration
    • +
  • Security Layer für mobile Authententifizierung
  • Test Credentials
  • Vollmachten
  • Zentraler eIDAS Connector
    • @@ -451,32 +454,7 @@ UNIX: moa.id.configuration=file:C:/Programme/apache/tomcat-8.x.x/conf/moa-id/moa https://<host>:<port>/moa-id-auth/MonitoringServlet

    Nach einem erfolgreichen Testdurchlauf Antwortet das Monitoring mit einen http Statuscode 200 und der oben definierten Statusmeldung aus dem Parameter configuration.monitoring.message.success. Im Falle eines Fehlers antwortet das Monitoring mit einem http Statuscode 500 und die Statusmeldung enthält eine Beschreibung des aufgetretenen Fehlers.

    2.2.2.2 Externe Services
    -

    Für den Aufbau von Verbindungen zu anderen Komponenten werden in manchen Fällen spezielle Client-Zertifikate oder Sicherheitseinstellungen benötigt. In diesem Abschnitt erfolgt die Konfiguration der für den Verbindungsaufbau benötigten Parameter. Die Konfiguration der URL zum jeweiligen Service wird jedoch über die Web-Oberfläche des Modules MOA-ID-Configuration vorgenommen (siehe Kapitel 3.1.7).

    -
    2.2.2.2.1 MOA-SP
    -

    Wird MOA-SP über ein Web-Service, welches Client Authentifizierung voraussetzt, angesprochen müssen in diesem Abschnitt die erforderlichen Schlüssel hinterlegt werden.

    - - - - - - - - - - - - - - - - - - - - - -
    NameBeispielwertBeschreibung
    service.moasp.clientKeyStorekeys/moa_sp.p12Dateiname des PKCS#12 Keystores, relativ zur MOA-ID Konfigurationsdatei. Diesem Keystore wird der private Schlüssel für die TLS-Client-Authentisierung entnommen.
    service.moasp.clientKeyStorePasswordpass1234Passwort zum Keystore
    service.moasp.acceptedServerCertificatescerts/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> (siehe Kapitel 3.1.4) angegebenen Zertifikaten erstellt werden kann.
    -

     

    +

    Für den Aufbau von Verbindungen zu anderen Komponenten werden in manchen Fällen spezielle Client-Zertifikate oder Sicherheitseinstellungen benötigt. In diesem Abschnitt erfolgt die Konfiguration der für den Verbindungsaufbau benötigten Parameter. Die Konfiguration der URL zum jeweiligen Service wird jedoch über die Web-Oberfläche des Modules MOA-ID-Configuration vorgenommen (siehe Kapitel 3.1.7)

    2.2.2.2.2 Online-Vollmachen

    MOA-ID-Auth bietet die Möglichkeit der Nutzung von Online-Vollmachten für Anwendungen aus dem öffentlichen Bereich. Hierfür ist ein Online-Vollmachten-Service nötig, wobei die Zugangsdaten zum Online-Vollmachten-Service konfiguriert werden müssen. Der Zugang zum Online-Vollmachten-Service ein Client-Zertifikat für die SSL-Verbindung zum Service. Voraussetzung dafür ist ein Zertifikat von A-Trust bzw. A-CERT mit Verwaltungseigenschaft oder Dienstleistereigenschaft. Wenn ihr MOA-ID-Auth Zertifikat diese Voraussetzung erfüllt, können Sie dieses hier angeben.

    @@ -650,6 +628,21 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet

     

    2.2.2.4 Datenbank

    Das Modul MOA-ID-Auth benötigt für den Betrieb zwei (optional drei) separate Datenbank Schema, welche in der Basiskonfiguration konfiguriert werden. Für Beispielkonfiguration wurde mySQL als Datenbank verwendet wodurch sich die Konfigurationsparameter auf mySQL beziehen. Das Modul MOA-ID-Auth kann jedoch auch mit Datenbanken anderer Hersteller oder einer InMemory Datenbank betrieben werden. Hierfür wird jedoch auf die Hibernate Dokumention verwiesen.

    +
    + + + + + + + + + + +
    NameBeispielwertBeschreibung
    configuration.database.byteBasedValues

    true / false

    Definiert ob Konfigurationswerte als Text oder als Bytes in der Datenbank abgelegt werden.
    + Hinweis: Testbasierte Speicherung kann bei manchen Datenbanksystemen zur problemen führen (z.B. postgreSQL)

    +

    Defaultwert: false

    +

     

    2.2.2.4.1 Konfiguration

    Alle Parameter aus der Basiskonfiguration welche als Prefix configuration.hibernate. im Parameternamen aufweisen konfigurieren den Zugriff auf das Datenbank Schema welches die Konfiguration von MOA-ID-Auth beinhaltet. Eine Konfiguration dieser Parameter ist nicht optional.

    @@ -821,7 +814,97 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet

    Defaultwert: true

    -
    2.2.2.6 SZR Client für STORK <-> PVP Gateway Betrieb
    +
    2.2.2.6 Security Layer für mobile Authententifizierung
    +

    Diese Parameter dienen zur Konfiguration der neuen Authentifizierungsschnittstelle via Security-Layer 2.0

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    modules.sl20.vda.urls.qualeID.endpoint.defaulthttps://www.handy-signatur.at/securitylayer2Defaultendpunkt für die Anbindung an einen VDA mittels Security-Layer 2.0
    modules.sl20.vda.urls.qualeID.endpoint.x Über diese Parameter können weitere Endpunkte konfiguriert werden, wobei das 'x' im Namen durch einen Identifier ersetzt werden muss (z.B.: modules.sl20.vda.urls.qualeID.endpoint.1=https://test1.a-trust.at/securitylayer2) Die Auwahl des Endpunkts erfolgt via http Header im Request an MOA-ID, wobei der Headername 'X-MOA-VDA' lautet und der Headerwert dem Identifier (z.B. '1') entsprechen muss.
    + Hinweis: Hiebei handelt es sich primär um eine Funktion zu Testzwecken im aktuellen Beta-Status
    modules.sl20.security.keystore.pathkeys/sl20.jksDateiname des Java Keystore welcher die Schlüssel zum Signieren und Verschlüsseln von Security-Layer 2.0 Nachrichten beinhaltet. Des weiteren dient dieser KeyStore als TrustStore zur Validierung von signierten Security-Layer 2.0 Nachrichten. Somit müssen Signaturzertifikate von SL2.0 Teilnehmern in diesem TrustStore hinterlegt sein.
    modules.sl20.security.keystore.passwordpasswordPasswort zum Keystore
    modules.sl20.security.sign.aliassigningName des Schlüssels der zur Signierung von SL2.0 Nachrichten
    modules.sl20.security.sign.password Passwort des Schlüssels zur Signierung von SL2.0 Nachrichten
    modules.sl20.security.encryption.aliasencryptionName des Schlüssels zur Verschlüsselung von SL2.0 Nachrichten
    modules.sl20.security.encryption.password Passwort des Schlüssels zur Verschlüsselung von SL2.0 Nachrichten
    modules.sl20.vda.authblock.iddefault

    Identifier für den AuthBlock, welcher der Benutzer im Authentifizierungsprozess unterschreiben muss

    +

    Default: default

    modules.sl20.vda.authblock.transformation.idSL20Authblock_v1.0,
    + SL20Authblock_v1.0_SIC

    Identifier der erlaubten AuthBlock-Transformationen als CSV für die visuelle Darstellung des AuthBlocks

    +

    Default: SL20Authblock_v1.0,SL20Authblock_v1.0_SIC

    modules.sl20.security.eID.validation.disabletrue / false

    Deaktivierung der eID Daten validierung.

    +

    Default: false

    modules.sl20.security.eID.signed.result.requiredtrue / false

    Aktivierung von verpflichtend signierten Kommandos

    +

    Default: true

    modules.sl20.security.eID.encryption.enabledtrue / false

    Aktivierung von Verschlüsselung, wodurch signierte Kommandos Schlüsselmaterial zur Verschlüsselung beinhalten.

    +

    Default:true

    modules.sl20.security.eID.encryption.requiredtrue / false

    Aktivierung von verpflichtender Verschlüsselung. eID Daten müssen durch den VDA verschlüsselt übertragen werden.

    +

    Default:true

    +

     

    +

     

    +

     

    +
    2.2.2.7 SZR Client für STORK <-> PVP Gateway Betrieb

    Die Konfiguration des Stammzahlenregister (SZR) Clients ist nur erforderlich wenn das Modul MOA-ID-Auth als STORK <-> PVP Gateway betrieben wird. Da in diesem Fall die Benutzerin oder der Benutzer über ein PVP Stammportal authentifiziert wird ist eine direkte Generierung der STORK eID während des Anmeldevorgangs nicht möglich. Somit erfolgt für diese Personen einen Stammzahlenregisterabfrage zur Bestimmung der STORK eID.

    Für den in MOA-ID-Auth verwendeten SZR Client sind folgende Konfigurationsparameter erforderlich.

    @@ -945,7 +1028,47 @@ https://<host>:<port>/moa-id-auth/MonitoringServlet

     

    Hinweis: Detaillierte Informationen zu den einzelnen PVP spezifischen Konfigurationsparametern finden Sie in der entsprechenden PVP Spezifikation.

    -

    2.3 Konfiguration des Loggings

    +
    2.2.2.8 Weitere optionale Konfigurationsparameter
    +

    Hierbei handelt es sich um weitere optionale Parameter.

    + + + + + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertBeschreibung
    configuration.restrictions.sp.entityIds

    https://demo.egiz.gv.at/demologin/

    Liste von eindeutigen Online-Applikationsidentifikatioren als Comma Separatet Values (CSV) für welche die Einschränkung auf bestimmte Benutzer aktiviert werden soll. Für alle OAs in dieser Liste ist eine Anmeldung nur dann möglich wenn die bPK des Benutzers in der Whitelist eingetragen ist.

    +

     

    configuration.restrictions.sp.users.urlwhitelist/users.csv

    Whitelist von bPKs als Comma Separatet Values (CSV) für welche eine Anmeldung erlaubt ist.

    +

    z.B.: ZP:xm1zT43arrfTRLnDsxYoFk3XwDU=,ZP:gr99V4hH5KLlarBCcCAbKJNMF18=

    configuration.restrictions.sp.users.sectorurn:publicid:gv.at:cdid+ZPbPK Berecih welcher in der Whitelist verwendet wird
    configuration.foreignsectors.pubkey.xxxxTargetxxxconfiguration.foreignsectors.pubkey.wbpk+FN+468924i=
    + MIIDCzCCAfMCBFr9aB4wDQYJKoZI....

    MOA-ID bietet die Möglichkeit verschlüsselte bPKs entsprechend der Berechnungsvorschrift für Fremd-bPKs zu generieren. Die hierfür benötigen öffentlichen Schlüssel müssen als Base64 kodierte X509 Zertifikate je bPK / wbPK Bereich hinterlegt werden.
    + Der bPK / wbPK Bereich muss als Teil des Konfigurationsschlüssels (z.B. wbpk+FN+468924i, BMI+T1, ...) angegeben werden.

    +
      +
    • Für öffentliche Bereiche: VKZ+Target (VKZ ... Verfahrenskennzeichen)
      • +
    • Für private Bereiche: wbpk+Stammzahl der juristischen Person (z.B. FN+468924i)
      • +
    +


    +

    +

     

    +

    2.3 Konfiguration des Loggings

    Die Module MOA-ID-Auth und MOA-ID-Configuration verwendet als Framework für Logging-Information die Open Source Software log4j. Die Konfiguration der Logging-Information erfolgt nicht direkt durch die einzelnen Module, sondern über eine eigene Konfigurationsdatei, die der Java Virtual Machine durch eine System Property mitgeteilt wird. Der Name der System Property lautet log4j.configuration; als Wert der System Property ist eine URL anzugeben, die auf die log4j-Konfigurationsdatei verweist, z.B. 

    log4j.configuration=file:/C:/Programme/apache/tomcat-8.x.x/conf/moa-id/log4j.properties

    Zustätzlich wird für einige Basiskomponenten, welche über Drittherstellerbibliotheken inkludiert sind, LogBack als Logging Framework verwendet. Die LogBack Konfiguration wird ebenfalls über den System Property angegeben

    @@ -1484,7 +1607,37 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der Ü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 Templates 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. -

    3.2.3 Test Identitäten

    +

    3.2.3 Security Layer für mobile Authententifizierung

    +

    Mit diesem Abschnitt kann der neue Security Layer für mobile Authentifzierung für diese Online Applikation aktiviert werden.
    + Wird diese Schnittstelle aktiviert ist die Security-Layer 1.x Schnittstelle zur Bürgerkartenkommunikation deaktiviert und steht nicht mehr zur Verfügung.

    + + + + + + + + + + + + + + + + + + + + + + +
    NameBeispielwertAdminOptionalBeschreibung

    SL2.0 aktivieren

    		true / falseXXAktiviert den neuen Security Layer für mobile Authentifizierung für diese Online Applikation

    VDA Endpunkt URLs:

    default=https://www.handy-signatur.at/securitylayer2,

    +

    1=https://test1.a-trust.at/securitylayer2,

    +

    2=https://hs-abnahme.a-trust.at/securitylayer2

    		XXEine CSV Liste von VDA Endpunkten, welche für die Online Applikation verwendet werden können. Die Konfiguration erfolgt entsprechend den in Kapitel 2.2.2.6 beschriebenen Regeln.
    + Sind keine Parameter angegeben wird automatisch die Konfiguration aus Kapitel 2.2.2.6 verwendet.
    +

     

    +

    3.2.4 Test Identitäten

    In diesem Abschnitt können für diese Online-Applikation Testidentitäten erlaubt werden. Diese Testidentitäten können auch bei produktiven Instanzen freigeschalten werden, da die Unterschiedung zwischen Produkt- und Testidentität anhand einer speziellen OID im Signaturzertifikat der Testidentität getroffen wird. Folgende Konfigurationsparameter stehen hierfür zur Verfügung.

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

     

    Hinweis: Diese Funktionalität steht jedoch nur Testidentitäten welchen bereits mit einer Test OID im Signaturzertifikat ausgestattet sind zur Verfügung.

    -

    3.2.4 Vollmachten

    +

    3.2.5 Vollmachten

    Dieser Abschnitt behandelt online-applikationsspezifische Einstellungen zur Anmeldung mittels Online-Vollmachen.

    @@ -1576,7 +1729,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. Die Funktionalität der entsprechenden Parameter hat jedoch weiterhin Einfluss auf den Anmeldevorgang.

    -

    3.2.5 Zentraler nationaler eIDAS Connector

    +

    3.2.6 Zentraler nationaler eIDAS Connector

    Dieser Abschnitt behandelt online-applikationsspezifische Einstellungen zum Anknüpfung an den zentralen nationalen eIDAS Connector

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

     

    -

    3.2.6 Single Sign-On (SSO)

    +

    3.2.7 Single Sign-On (SSO)

    Dieser Abschnitt behandelt online-applikationsspezifische Einstellungen zu Single Sign-On

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

    Hinweis: Diese Abfrage ist standardmäßig aktiviert und kann nur durch einen Benutzer mit der Role admin deaktiviert werden.

    -

    3.2.7 Authentifizierung mittels eIDAS

    +

    3.2.8 Authentifizierung mittels eIDAS

    Dieser Abschnitt behandelt Online-Applikationsspezifische Einstellungen zur Authentifizierung mittels eIDAS.

    @@ -1647,10 +1800,10 @@ 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.8 Authentifizierungsprotokolle

    +

    3.2.9 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 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.8.1 SAML1
    +
    3.2.9.1 SAML1

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

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

     

    Hinweis: Das Modul MOA-ID-Auth in der Version 2.0 unterstützt SAML1 nur mehr zur Abwärtskompatibilität mit bereits bestehenden Online-Applikationen. Wir empfehlen den Umstieg auf ein anderes, von MOA-ID-Auth unterstütztes, Authentifizierungsprotokoll. Aus diesem Grund steht die Konfiguration des SAML1 Protokolls nur mehr einer Benutzerin oder einem Benutzer mit der Role admin zur Verfügung.

    -
    3.2.8.2 PVP 2.1
    +
    3.2.9.2 PVP 2.1

    In diesem Bereich erfolgt die applikationsspezifische Konfiguration für das Authentifizierungsprotokoll PVP 2.1.

    @@ -1746,7 +1899,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der
    Pfad zum online-applikationsspezifischen Template für SAML2 (PVP2 S-Profil) http POST-Binding. Relative Pfadangaben werden dabei relativ zum Verzeichnis, in dem sich die MOA-ID-Auth Basiskonfigurationsdatei befindet, interpretiert. Das Template kann ausschließlich aus dem Dateisystem geladen werden.
    -
    3.2.8.3 OpenID Connect
    +
    3.2.9.3 OpenID Connect

    In diesem Bereich erfolgt die applikationsspezifische Konfiguration für OpenID Connect (OAuth 2.0).

    @@ -1778,7 +1931,7 @@ Soll die Bürgerkartenauswahl weiterhin, wie in MOA-ID 1.5.1 im Kontext der
    OpenID Connect Redirect URL. Nach erfolgreicher Authentifizierung wird die Benutzerin oder der Benutzer an diese URL zurückgeleitet.
    -
    3.2.9 Zusätzliche allgemeine Einstellungen
    +
    3.2.10 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 verwendet wird oder wenn die individuelle Security-Layer Transformation den Formvorschriften der Spezifikation entspricht.

    @@ -1836,7 +1989,7 @@ wenn die individuelle Security-Layer Transformation den Formvorschriften der Sp
     
     
    -
    3.2.9.1 Login-Fenster Konfiguration
    +
    3.2.10.1 Login-Fenster Konfiguration

    Diese Konfigurationsparameter bieten zusätzliche Einstellungen für eine Anpassung der Bürgerkartenauswahl welche von MOA-ID-Auth generiert wird. Zur besseren Handhabung werden die angegebenen Parameter direkt in einer Vorschau dargestellt. Alle in diesem Abschnitt angegebenen Parameter sind Optional und werden bei Bedarf durch Standardwerte ergänzt. @@ -1925,7 +2078,7 @@ Alle in diesem Abschnitt angegebenen Parameter sind Optional und werden bei Beda

     

    Hinweis: Bei Verwendung einer online-applikationsspezifischen Bürgerkartenauswahl stehen alle Parameter die die Bürgerkartenauswahl betreffen nicht zur Verfügung.

    Hinweis: Bei Verwendung eines online-applikationsspezifischen Security-Layer-Request Templates stehen alle Parameter die das SL-Template betreffen nicht zur Verfügung.

    -
    3.2.10 Revisionslogging
    +
    3.2.11 Revisionslogging

    Ab MOA-ID 3.x steht ein erweitertes speziell für Revisionsaufgaben abgestimmtest Logging zur Verfügung. Über dieses Feld können die zu loggenden Events als CSV codierte Eventcodes konfiguriert werden. Werden keine Eventcodes konfiguriert wird eine in MOA-ID hinterlegte Defaultkonfiguration verwendet. Eine Liste aller möglichen Eventcodes finden Sie hier.

    3.3 Import / Export

    Üer diese Funktionalität besteht die Möglichkeit eine bestehende MOA-ID 2.x.x -- cgit v1.2.3