Skip to content
GitLab

[Epic] ELSTER + Accountverwaltung

Ausgangslage

Momentan erfolgt für die Freischaltung auf der STAGING- und PROD-Umgebung eine manuelle Prüfung der Identität von Nutzer:innen (Länder, Kommunen, beauftragte IT-Dienstleister). Eine solche manuelle Prüfung ist fehleranfällig. Zudem verursacht die manuelle Freischaltung von Accounts Aufwände auf Seiten der FITKO.

Lösung

Zukünftig sollen sich Nutzer:innen über das ELSTER-Organisationskonto im FIT-Connect Self-Service-Portal registrieren können. Beim Login mittels des ELSTER-Orgnisationskonto werden auch der Name und eine eindeutige ID der Organisation der sich einloggenden Person übermittelt und gespeichert. Der Login mittels des ELSTER-Organisationskontos stellt sicher, dass nur vertretungsberechtigte Personen der Organisation einen Account im FIT-Connect-Self-Service-Portal erstellen können.

Relevante Links und Bemerkungen

Technische Doku zu Elster: https://nextcloud.fitko.net/index.php/f/145719

Aktuell besitzt nur @Alexander_Hoose einen Account für die Konfig der Elster Umgebung.

Anforderungen & Akzeptanzkriterien

  1. Das Umsetzungskonzept wurde mit RuC (Rechtsabteilung FITKO) abgestimmt und für gut befunden.
  2. Beim Login mittels ELSTER-Organisationskonto werden die im ELSTER-Organisationskonto hinterlegten Kontaktdaten erfasst, um die betroffene Organisation oder den Nutzer bei Bedarf für technische Rückfragen kontaktieren zu können.
  3. Beim Login mittels ELSTER-Organisationskonto wird anhand der im ELSTER-Organisationskonto hinterlegten Daten eindeutig ermittelt, ob es sich bei der Organisation, zu der die sich einloggende Person gehört, um eine Behörde oder eine andere Organisationsform handelt.
  4. Die im ELSTER-Organisationskonto hinterlegten Informationen zur Organisation werden inkl. eindeutiger ID und Organisationstyp vom SSP gespeichert. -> #993
  5. Die erfassten Kontaktdaten werden bei jedem erneuten Login aktualisiert, falls sie sich geändert haben sollten. -> #993
  6. Es liegt ein Konzept für einen Migrationspfad für die auf der PROD-Umgebung bestehenden Accounts vor. Eine Umsetzung kann beispielsweise im Rahmen von #330 erfolgen.
  7. Bis zur Umsetzung von #197 muss zwangsläufig eine manuelle Freischaltung durch die FITKO erfolgen, um sicherzustellen, dass unterzeichnete Nutzungsbedingungen und AVVs vorliegen.
  8. Bis zur Umsetzung von #330 muss für Organisationen, die keine Behörde sind, zwangsläufig eine manuelle Freischaltung durch die FITKO erfolgen, um sicherzustellen, dass ein berechtigtes Interesse vorliegt (Grund: Bis zur Umsetzung von #330 können registrierte Nutzer:innen sowohl Sender, als auch Subscriber anlegen).
  9. Nach Umsetzung von #197 und #330 wird eine Registrierung ohne manuelle Freischaltung der FITKO angestrebt.
  10. Es gibt eine Möglichkeit, Nutzer:innen manuell zu sperren.
  11. Es gibt eine Möglichkeit, API-Clients (und Zustellpunkte?) beliebige Nutzer:innen manuell zu sperren.
  12. Die Datenschutzerklärung des SSP und ggf. die Nutzungsbedingungen wurden angepasst.

Hinweise zur Umsetzung von Stories

Fachadministration für die Accountverwaltung

Hier wäre folgende Story die Basis für die anderen Stories:

Alle anderen Stories weisen keine zwingende Priorisierung auf.

Abschließend ist die Nutzung der Fachadministration (einschließlich Prozesse und Verantwortlichkeiten) für den Support, Betrieb und das Entwicklerteam zu dokumentieren: #1009

Alte Beschreibung vor Umbau des Epics

Zu klären

  1. Soll der ELSTER-Login auch auf der Testumgebung umgesetzt werden?
    • Alex: Ich würde sagen ja. Für viele Organisationen macht das Sinn und ist juristische Organisation einfacher als die alternativen Logins. Zudem
  2. Ist eine Migration von bestehenden GitLab-Accounts auf ELSTER-Accounts teil dieses Epics oder erst Teil von #330?
    • Alex: Ich würde sagen erst später. Aber man könnte vorsehen, neue Zugänge nur noch auf Elster Basis zu schalten.

Relevante Links und Bemerkungen

Software und Handbücher für ID-Mercury und den Elster Client: https://nextcloud.fitko.net/index.php/f/145796

Technische Doku zu Elster: https://nextcloud.fitko.net/index.php/f/145719

Sammlung von Architektur Skizzen: https://nextcloud.fitko.net/index.php/f/148160

Für alle Story werden standardisierte Testaccounts von Elster benutzt. Diese müssen noch final beschafft werden (its complicated).

Anforderungen & Akzeptanzkriterien

  1. Das Umsetzungskonzept wurde mit RuC (Rechtsabteilung FITKO) abgestimmt und für gut befunden.
  2. Beim Login mittels ELSTER-Organisationskonto werden die im ELSTER-Organisationskonto hinterlegten Kontaktdaten erfasst, um die betroffene Organisation oder den Nutzer bei Bedarf für technische Rückfragen kontaktieren zu können.
  3. Beim Login mittels ELSTER-Organisationskonto wird anhand der im ELSTER-Organisationskonto hinterlegten Daten eindeutig ermittelt, ob es sich bei der Organisation, zu der die sich einloggende Person gehört, um eine Behörde oder eine andere Organisationsform handelt.
  4. Die im ELSTER-Organisationskonto hinterlegten Informationen zur Organisation werden inkl. eindeutiger ID und Organisationstyp vom SSP gespeichert. -> #993
  5. Die erfassten Kontaktdaten werden bei jedem erneuten Login aktualisiert, falls sie sich geändert haben sollten. -> #993
  6. Es liegt ein Konzept für einen Migrationspfad für die auf der PROD-Umgebung bestehenden Accounts vor. Eine Umsetzung kann beispielsweise im Rahmen von #330 erfolgen.
  7. Bis zur Umsetzung von #197 muss zwangsläufig eine manuelle Freischaltung durch die FITKO erfolgen, um sicherzustellen, dass unterzeichnete Nutzungsbedingungen und AVVs vorliegen.
  8. Bis zur Umsetzung von #330 muss für Organisationen, die keine Behörde sind, zwangsläufig eine manuelle Freischaltung durch die FITKO erfolgen, um sicherzustellen, dass ein berechtigtes Interesse vorliegt (Grund: Bis zur Umsetzung von #330 können registrierte Nutzer:innen sowohl Sender, als auch Subscriber anlegen).
  9. Nach Umsetzung von #197 und #330 wird eine Registrierung ohne manuelle Freischaltung der FITKO angestrebt.
  10. Es gibt eine Möglichkeit, Nutzer:innen manuell zu sperren.
  11. Es gibt eine Möglichkeit, API-Clients (und Zustellpunkte?) beliebige Nutzer:innen manuell zu sperren.
  12. Die Datenschutzerklärung des SSP und ggf. die Nutzungsbedingungen wurden angepasst.

Hinweise zur Umsetzung von Stories

Zunächst ist folgende Story umzusetzen, um die Betriebsarchitektur zu finalisieren (hieraus ergeben sich ggf. Anpassungen an Stories):

#990

Danach gibt es zwei Stränge, die (größtenteils) unabhängig von einander umsetzbar sind:

  • Umsetzung des Elster Logins
  • Fachadministration für die Accountverwaltung (zwingend notwendig, um Elster praktisch umzusetzen)

Umsetzung des Elster Logins

Zunächst wären folgende Stories umzusetzen:

Alle anderen Stories weisen keine zwingende Priorisierung auf.

Abschließend ist die Nutzung des neuen Logins (einschließlich von Migrationen) für Endnutzer zu dokumentieren: #934

Fachadministration für die Accountverwaltung

Hier wäre folgende Story die Basis für die anderen Stories:

Alle anderen Stories weisen keine zwingende Priorisierung auf.

Abschließend ist die Nutzung der Fachadministration (einschließlich Prozesse und Verantwortlichkeiten) für den Support, Betrieb und das Entwicklerteam zu dokumentieren: #1009

Edited by Alexander Hoose