... |
... |
@@ -11,13 +11,10 @@ |
11 |
11 |
|
12 |
12 |
== Migration bestehender Service-Konten-Anbindungen == |
13 |
13 |
|
14 |
|
-* Bestehende Anbindungen zu Service-Konten von **BundID**, **BayernID** und **ELSTER** werden bei der Installation des Plugins automatisch auf das neue Plugin umgestellt. |
15 |
|
-* Die veralteten Plugin-Bundles (jar-Dateien) bleiben dabei auf dem System erhalten, werden aber deaktiviert. |
16 |
|
-* Alle zuvor konfigurierten Anbindungen werden als Externe Benutzer im jeweiligen Bereich (System oder Mandant) definiert. |
17 |
|
-* Designer-Vorlagen, die mit den veralteten Plugins in das System gekommen sind, werden entfernt. |
18 |
|
- |
19 |
|
-=== Migrations-Beispiel für BayernID Anbindung: === |
20 |
|
- |
|
14 |
+Bestehende Anbindungen zu Service-Konten von **BundID**, **BayernID** und **ELSTER** werden bei der Installation des Plugins automatisch auf das neue Plugin umgestellt. |
|
15 |
+Die veralteten Plugins bleiben dabei auf dem System werden aber deaktiviert. Alle zuvor konfigurierten Anbindungen werden als Externe Benutzer im jeweiligen Bereich(System oder Mandant) definiert. |
|
16 |
+Designer-Vorlagen, die mit den veralteten Plugins in das System gekommen sind, werden entfernt. |
|
17 |
+\\**Migrations-Beispiel für BayernID Anbindung:** |
21 |
21 |
Ausgangspunkt ist ein FORMCYCLE System mit mehreren Mandanten. In zwei Mandanten ist jeweils das// AKDB: Bürgerkonto-Service-Plugin //(Anbindung an **BayernID**) installiert. |
22 |
22 |
Einer der **BayernID **Mandanten hat die Einbindung des Bürgerkonto Logins als Externer Benutzer konfiguriert. |
23 |
23 |
|
... |
... |
@@ -35,37 +35,30 @@ |
35 |
35 |
{{/info}} |
36 |
36 |
|
37 |
37 |
|
38 |
|
-=== Migration für BundID Anbindungen === |
39 |
|
- |
|
35 |
+**Migration für BundID Anbindung:** |
40 |
40 |
Bei bestehenden **BundID** Anbindungen werden die vorhandenen Externen Benutzer mit der neuen Konfigurationseinstellungen erweitert. Vorhandene Formulare mit BundID Anbindung, können ähnlich, wie bei der BayernId ohne Anpassung genutzt werden. |
41 |
41 |
|
42 |
|
-=== Migration für ELSTER Anbinungen === |
|
38 |
+== Konfiguration neuer Servicekonto Anbindungen == |
43 |
43 |
|
44 |
|
-Bei bereits im System existenten **ELSTER** Anbindungen werden die vorhandenen Externen Benutzer mit neuen Konfigurationseinstellungen erweitert. Formulare mit einer Zugriffssteuerung über **ELSTER** können ohne weitere Anpassung genutzt werden. |
45 |
|
- |
46 |
|
-== Vorüberlegungen zur Anbindung neuer Servicekonten == |
47 |
|
- |
48 |
48 |
Neue Anbindungen an Servicekonten müssen im {{formcycle/}} System als [[Externe Benutzer>>doc:Formcycle.SystemSettings.UserInterface.ExternalUsers.WebHome]] (auch als Authentikatoren bezeichnet) angelegt werden. Dabei ist es möglich diese im System- als auch im Bereich des Mandanten anzulegen. |
49 |
49 |
Folgende Überlegungen sollten für eine Entscheidung des Bereichs, in welchem die Externen Benutzer angelegt werden, herangezogen werden. |
50 |
50 |
|
51 |
|
-**Ist ein Multi-Mandanten {{formcycle/}} System mit unterschiedlichen Host-Adressen für die Ansteuerung der Formulare der einzelnen Mandanten vorhanden? (Meist realisiert über Anbindung mehrerer Frontend-Server)** |
|
43 |
+**Ist ein Multi-Mandanten {{formcycle/}} System mit unterschiedlichen Host-Adressen für die Ansteuerung der Formulare in den einzelnen Mandanten vorhanden (meist realisiert über Anbindung mehrerer Frontend-Server)?** |
52 |
52 |
|
53 |
|
-In diesem Fall sollte jeweils im Mandanten ein Externer Benutzer angelegt werden, welcher die Anbindung an des Servicekonto realisiert. |
54 |
|
-\\Der Grund für dieses empfohlene Vorgehen ist, dass die aktuellen Anbindungen an die **BundID**, die **BayernID, **sowie an das **ELSTER**-Portal alle auf Grundlage des [[SAML 2.0>>https://en.wikipedia.org/wiki/SAML_2.0||rel="noopener noreferrer" target="_blank"]] - Protokolls arbeiten. Eine Festlegung bei der Kommunikation über das SAML 2.0 Protokoll ist es, dass im Vorfeld zwischen dem jeweiligen Identity Provider (Servicekonto-Portal) und dem Service Provider (FORMCYCLE) Metadaten ausgetauscht werden müssen. In diesen Metadaten sind die Rücksprungziele in das jeweils andere System (per URL) fest definiert. |
55 |
|
-Durch das Anlegen eines Externen Benutzers im Bereich des jeweiligen Mandanten kann hier eine saubere Trennung und damit auch Nutzung in den Formularen stattfinden. |
56 |
|
-Legt man bei dieser Systemkonstellation verschiedene Externe Benutzer im System - Bereich an, so muss der Formularentwickler innerhalb des Formular die für seinen Mandanten korrekte Anbindung auswählen, was eine potenzielle Fehlerquelle sein kann. |
|
45 |
+In diesem Fall sollte jeweils im Mandanten ein Externer Benutzer angelegt werden, welcher die Anbindung an des Servicekonto realisiert. Die aktuellen Anbindungen an die **BundID**, die **BayernID **sowie an das **ELSTER**-Portal arbeiten alle auf Grundlage des [[SAML 2.0>>https://en.wikipedia.org/wiki/SAML_2.0||rel="noopener noreferrer" target="_blank"]] - Protokolls. Eine Festlegung bei der Kommunikation über das SAML Protokoll ist es, dass im Vorfeld zwischen dem jeweiligen Identity Provider und dem Service Provider (FORMCYCLE) Metadaten ausgetauscht werden müssen, wo die Rücksprungziele in das jeweils andere System (per URL) fest definiert sind. Durch das Anlegen des Externen Benutzers im Bereich des jeweiligen Mandanten kann hier eine saubere Trennung und damit auch Nutzung in den Formularen stattfinden. |
|
46 |
+Legt man bei dieser Systemkonstellation die verschiedenen Externen Benutzer im System - Bereich an, so muss der Formularentwickler dann innerhalb des Formular die für seinen Mandanten korrekte Anbindung auswählen, was eine potenzielle Fehlerquelle sein kann. |
57 |
57 |
|
58 |
58 |
**Ist ein Multi-Mandanten- oder ein Single-Mandat- {{formcycle/}} System mit einer Host-Adresse für die Ansteuerung der Formulare vorhanden?** |
59 |
59 |
|
60 |
60 |
Hier sollten alle Externen Benutzer für die Servicekonten-Ansteuerung im System-Bereich angelegt werden. Der Vorteil ist an dieser Stelle, dass alle Anbindungen zentral an einer Stelle vorhanden sind und alle Formular-Benutzer in den verschiedenen Mandanten Zugriff auf diese erhalten. |
61 |
61 |
|
62 |
|
-== Allgemeine Informationen zur Anbindung eines Servicekontos == |
|
52 |
+=== Anbindung eines Servicekontos === |
63 |
63 |
|
64 |
64 |
{{figure image="extUser_selection.png"}} |
65 |
65 |
Auswahl eines Servicekontos |
66 |
66 |
{{/figure}} |
67 |
67 |
|
68 |
|
-In diesem Abschnitt werden die Schritte, welche für die Anbindung aller Servicekonten gleichermaßen gelten, erläutert. |
|
58 |
+In diesem Abschnitt werden die allgemeinen Schritte, welche für die Anbindung der unterschiedlichen Servicekonten notwendig sind, erläutert. |
69 |
69 |
|
70 |
70 |
Bevor man ein Servicekonto anbindet sollten folgende Voraussetzungen erfüllt sein: |
71 |
71 |
|
... |
... |
@@ -72,7 +72,7 @@ |
72 |
72 |
* Die im Unternehmen verantwortlichen technischen und organisatorischen Ansprechpartner müssen bekannt sein (Namen, E-Mail-Adressen). Diese Informationen werden innerhalb des Registrierungs-Prozesses für die einzelnen Servicekonten an unterschiedlichen Stellen benötigt. |
73 |
73 |
* URLs für die Anbindung des FORMCYCLE-Systems müssen eingerichtet und **von außen erreichbar** sein. Dabei ist zu beachten, dass bei Verwendung eines Frontend-Servers die URL zu diesem verwendet wird. |
74 |
74 |
|
75 |
|
-Die Anbindung eines Servicekontos lässt sich in folgende Schritte gliedern: |
|
65 |
+Die Anbindung eines Servicekontos lässt sich allgemein in folgende Schritte gliedern: |
76 |
76 |
|
77 |
77 |
1. Anlegen einen neuen Externen Benutzer (Authentikator) unter dem Menüpunkt System > [[Systemplugins>>doc:Formcycle.SystemSettings.UserInterface.SystemPlugins||target="_blank"]] oder Mandant > [[Plugins>>doc:Formcycle.UserInterface.Client.Plugins||target="_blank"]]. |
78 |
78 |
1. Spezifische Authentikator Konfiguration über die zur Verfügung gestellte Oberfläche ausführen. Die Konfigurationsoberfläche unterscheidet sich je nach ausgewählten Servicekonto. Auf die Unterschiede bei der Anbindung des jeweiligen Servicekonto-Typs wird in den nachfolgenden Abschnitten näher eingegangen. |
... |
... |
@@ -80,15 +80,15 @@ |
80 |
80 |
selbst durchzuführende Konfiguration auf Seiten des Identity Providers über ein Self-Service Portal (ELSTER) |
81 |
81 |
1. Freigabe des Authentikators in {{formcycle/}}, nach erfolgter Rückmeldung über die erfolgte Registrierung der Metadaten durch den jeweiligen Identity Provider bzw. Freigabe durch Prüfungsinstanz (bei ELSTER Self Service Portal Registrierung) und damit Beginn der Einbindung des Servicekontos in Formulare |
82 |
82 |
|
83 |
|
-== Details für die Anbindung der BundID == |
|
73 |
+=== Details zur Anbindung BundID === |
84 |
84 |
|
85 |
|
-== Details für die Anbindung des ELSTER //Mein Unternehmenskontos// == |
|
75 |
+=== Details zur Anbindung ELSTER //Mein Unternehmenskonto// === |
86 |
86 |
|
87 |
|
-== Details für die Anbindung der BayernID == |
|
77 |
+=== Details zur Anbindung BayernID === |
88 |
88 |
|
89 |
89 |
Um das Servicekonto der **BayernID** anzubinden ist ein neuer Externer Benutzer anzulegen und als Authentifizierungstyp **BayernID** auszuwählen. |
90 |
90 |
|
91 |
|
-=== Schritt 1: Konfiguration anlegen === |
|
81 |
+==== Schritt 1: Konfiguration anlegen ==== |
92 |
92 |
|
93 |
93 |
{{figure image="bayernID_config1.png"}} |
94 |
94 |
Schritt 1: Notwendige Daten für Erzeugung der Service Metadaten festlegen |
... |
... |
@@ -100,7 +100,7 @@ |
100 |
100 |
** Angaben zum organisatorischen und technischen Ansprechpartner. Diese Informationen werden im Zuge des Registrierungsprozesses an das **BayernID**-Portal weitergegeben. |
101 |
101 |
* Speichern der Eingaben. Danach gelangt man zum 2. Schritt der Anbindung. |
102 |
102 |
|
103 |
|
-=== Schritt 2: Metadaten erzeugen und registrieren === |
|
93 |
+==== Schritt 2: Metadaten erzeugen und registrieren ==== |
104 |
104 |
|
105 |
105 |
{{figure image="bayernID_config2.png"}} |
106 |
106 |
Schritt 2 und 3: Download der erzeugten Meta- und vorbefüllten Vertragsdaten für eine jeweiligen Host-Adresse; Aktivierung der BayernID Authentifizierung für Formulare |
... |
... |
@@ -117,7 +117,7 @@ |
117 |
117 |
* **Beitrittserklärung** und **SAML-Metadaten** sind an das **BayernID** Portal (Mail: **BayernID@akdb.de**) zu senden, mit der Bitte, um Aufnahme in den Portalverbund. |
118 |
118 |
* Damit ist der 1. Teil der Registrierung abgeschlossen und eine Antwort vom **BayernID** Portal muss abgewartet werden. |
119 |
119 |
|
120 |
|
-=== Schritt 3: BayernID-Login Aktivierung === |
|
110 |
+==== Schritt 3: BayernID-Login Aktivierung ==== |
121 |
121 |
|
122 |
122 |
{{figure image="bayernID_config3.png"}} |
123 |
123 |
BayernID Postkorbanbindung konfigurieren |
... |
... |
@@ -131,28 +131,8 @@ |
131 |
131 |
dass der anfragende Service dem Portal nicht bekannt ist. |
132 |
132 |
{{/info}} |
133 |
133 |
))) |
134 |
|
-* ((( |
135 |
|
-Nach Aktivierung des Logins erscheint erweitert sich die Konfigurationsoberfläche des Authentikators.* Unter dem Punkt //Erweiterte Einstellungen// > //Konfigurtion BayernID Postkorbanbindung// können Sie das Zertifikat, welches Sie im Zuge der Registrierung ihrer Metadaten vom **BayernID **Portal erhalten haben sollten, hochladen und zusammen mit dem zugehörigen Passwort an der Authentikator-Konfiguration abspeichern. |
136 |
|
-* ((( |
137 |
|
-Über den Button //Postkorb Verbindung prüfen// kann der Zugriff auf den Postkorb-Webservice getestet werden. |
138 |
|
-Der Webservice muss dabei vom {{formcycle/}} Master-Server aus erreichbar sein (dafür sind im System unter Umständen Firewall Freigaben notwendig).((( |
139 |
|
-{{warning}} |
140 |
|
-Folgende URL muss **vom FORMCYCLE Master-Server** **aus erreichbar** sein: |
141 |
|
- |
142 |
|
-* Testsystem: https:~/~/infra-pre-bayernid.freistaat.bayern/bspx-postkorb-okkomm-ws/bspservices/postkorbkomm |
143 |
|
-ODER |
144 |
|
-* Livesystem: https:~/~/bayernid.freistaat.bayern/bspx-postkorb-okkomm-ws/bspservices/postkorbkomm |
145 |
|
-{{/warning}} |
146 |
|
-))) |
147 |
|
- |
148 |
|
-((( |
149 |
|
-{{info}} |
150 |
|
-**Fehlerbehebung, wenn die Prüfung des Postkorbverbindung fehl schlägt:** |
151 |
|
- |
152 |
|
-Prüfen Sie, ob die Freischaltung in der Firewall erfolgt ist. |
153 |
|
-Der Postkorb-Webservice nutzt das HTTPS Protokoll für die Kommunikation, welches im Transport-Layer das TCP Protokoll benutzt. Deshalb sollte in ihrer Firewall die IP 193.28.249.234 (für das Livesystem **bayernid.freistaat.bayern**) oder IP 193.28.249.228 (für das Testsystem **infra-pre-bayernid.freistaat.bayern**) als TCP-Verbindungen der Port 443 (das ist der Standard-Https-Port) sowohl für die ausgehende als auch eingehende Kommunikation freigegeben sein. |
154 |
|
-{{/info}} |
155 |
|
-))) |
156 |
|
-))) |
157 |
|
-* Sollte für die Kommunikation ein Proxy-Server notwendig sein, so kann dieser in den Eingabefeldern //Proxy Host //und //Proxy Port// konfiguriert werden. |
158 |
|
-))) |
|
124 |
+* Nach Aktivierung des Logins erscheint erweitert sich die Konfigurationsoberfläche des Authentikators. |
|
125 |
+** Unter dem Punkt //Erweiterte Einstellungen// > //Konfigurtion BayernID Postkorbanbindung// können Sie das Zertifikat, welches Sie im Zuge der Registrierung ihrer Metadaten vom **BayernID **Portal erhalten haben sollten, hochladen und zusammen mit dem zugehörigen Passwort an der Authentikator-Konfiguration abspeichern. |
|
126 |
+** Über den Button //Postkorb Verbindung prüfen// kann der Zugriff auf den Postkorb-Webservice getestet werden. |
|
127 |
+Der Webservice muss dabei vom {{formcycle/}} Master-Server aus erreichbar sein (dafür sind im System unter Umständen Firewall Freigaben notwendig). |
|
128 |
+** Sollte für die Kommunikation ein Proxy-Server notwendig sein, so kann dieser in den Eingabefeldern //Proxy Host //und //Proxy Port// konfiguriert werden. |