Zum Inhalt

Authorizierung

Die Authorizierung legt fest, welche Benutzer und Service Accounts für einen Herausgeber über die ODI Daten hochladen, aktualisieren oder Schemata veröffentlichen dürfen.

Ablauf im Überblick

Bevor ein Herausgeber Daten über die API veröffentlichen kann, müssen zunächst die passenden Berechtigungen eingerichtet werden. Danach können die Zugangsdaten genutzt werden, um Daten über die ODI-API zu veröffentlichen oder zu aktualisieren.

1. Herausgeber-Berechtigung anlegen — In Keycloak eine Gruppe für den Herausgeber anlegen und die API-Tokens für CKAN und GitLab als Gruppenattribute hinterlegen. Diese Gruppe bildet die gemeinsame Berechtigungsbasis für alle Benutzer und Service Accounts des Herausgebers. (Diese Seite)

2. Client anlegen und Herausgeber zuweisen — In Keycloak einen Client anlegen und dem Herausgeber zuweisen. Erst dadurch erhält der Client die in der Gruppe hinterlegten Berechtigungen. Siehe Programmatischen API-Zugriff einrichten.

3. Zugangsdaten weitergeben — Client ID und Client Secret an das Team oder System weitergeben, das Daten veröffentlichen soll. Diese Zugangsdaten sind umgebungsspezifisch und sollten sicher übertragen und gespeichert werden.

4. Daten veröffentlichen — Mit Client ID und Client Secret kann ein Access-Token abgerufen und die ODI-API verwendet werden, um Datensätze zu veröffentlichen oder zu aktualisieren: - Datensatz hochladen - Datensatz aktualisieren - Datensatzserie fortführen

Berechtigung für einen Herausgeber anlegen

In diesem Schritt wird festgelegt, welche Rechte einem Herausgeber in der ODI zur Verfügung stehen. Dazu werden in Keycloak Gruppen mit Tokens angelegt, über die die passenden Berechtigungen für Benutzer und Service Accounts bereitgestellt werden.

Sicherheitsmodell: Capability-Based Security

Die ODI verwendet ein Capability-Based Security-Modell: Der Besitz eines Tokens oder API-Keys ist selbst die Berechtigung — nicht die Identität des Benutzers.

Wer einen gültigen Token vorlegt, darf die damit verknüpfte Aktion ausführen. Das Zielsystem (CKAN, GitLab) prüft primär den Token, nicht das aufrufende Konto. Die Berechtigung liegt damit im Schlüssel selbst ("Possession of token → access").

In der Praxis bedeutet das: Ein CKAN-API-Token, der einer Keycloak-Gruppe zugewiesen ist, gewährt allen Mitgliedern dieser Gruppe — Benutzer wie Service Accounts — dieselben Schreibrechte in CKAN. Tokens müssen daher sicher verwahrt und bei Kompromittierung umgehend erneuert werden.

Weiterführend: Capability-based security (Wikipedia)

Begriffe: Service Account = Client

In dieser Dokumentation werden Service Account und Client synonym verwendet. Ein Keycloak-Client, der für den maschinellen API-Zugriff eingerichtet wird, entspricht dem, was in anderen Kontexten oft als Service Account bezeichnet wird.

Voraussetzungen

  • Administratorrechte in Keycloak
  • CKAN-API-Token und GitLab-Token für den Herausgeber liegen vor

Es gibt zwei Varianten für die Gruppenstruktur: Variante A verwendet eine einzige Gruppe pro Herausgeber, die alle Berechtigungen enthält — einfach zu verwalten, aber ohne Unterscheidung zwischen Schreiben-Rechten bei CKAN und Schreib-Rechten bei GitLab. Variante B trennt die Schreib-Rechte auf separate Gruppen auf und ist geeignet, wenn z. B. nicht jeder Service Account sowohl Daten hochladen als auch Schemata veröffentlichen soll.

Variante A – Eine Gruppe pro Herausgeber

Eine einzige Gruppe enthält beide Attribute: ckan-token und gitlab-token. Alle Mitglieder der Gruppe können damit sowohl Daten in CKAN hochladen als auch Schemata in GitLab anlegen.

Geeignet wenn:

  • Alle Benutzer und Service Accounts eines Herausgebers denselben Zugriff benötigen
  • Keine feingranulare Trennung erforderlich ist
  • Service Accounts sollen sowohl Daten hochladen als auch Schemata veröffentlichen können

Beispiel: Landesamt für Umwelt Schleswig-Holstein
Gruppenname landesamt-fuer-umwelt-sh
Attribut ckan-token <CKAN-API-Token des LfU>
Attribut gitlab-token <GitLab-Token des LfU>
Mitglieder Sachbearbeiter-Konten, Service Account landesamt-fuer-umwelt-sh-api-client

Schritte in Keycloak

  1. Unter Groups eine neue Gruppe anlegen, z. B. landesamt-fuer-umwelt-sh.
  2. Im Tab Attributes zwei Einträge hinzufügen:
    • ckan-token = <Wert>
    • gitlab-token = <Wert>
  3. Benutzerkonten und Service Accounts der Gruppe zuweisen — wie ein Service Account einer Gruppe zugewiesen wird, ist unter Programmatischen API-Zugriff einrichten, Schritt 4 beschrieben.

Variante B – Getrennte Gruppen für CKAN und GitLab

Pro Herausgeber werden zwei Gruppen angelegt: eine mit dem ckan-token, eine mit dem gitlab-token. So lässt sich steuern, welche Benutzer oder Service Accounts nur Daten hochladen dürfen und welche zusätzlich Schemata veröffentlichen können.

Geeignet wenn:

  • Unterschiedliche Rollen innerhalb eines Herausgebers vorliegen — etwa Fachanwender laden Daten hoch, während die IT-Abteilung Schemata verwaltet
  • Für Upload und Schema-Verwaltung separate Service Accounts verwendet werden

Beispiel: Landesamt für Umwelt Schleswig-Holstein

Gruppe 1 – CKAN-Berechtigung
Gruppenname landesamt-fuer-umwelt-sh-ckan
Attribut ckan-token <CKAN-API-Token des LfU>
Mitglieder Sachbearbeiter-Konten, Service Account landesamt-fuer-umwelt-sh-upload-client

Gruppe 2 – GitLab-Berechtigung

Diese Gruppe ist optional und muss nur angelegt werden, wenn der Herausgeber Schemata in GitLab veröffentlichen und aktualiseren soll.
Gruppenname landesamt-fuer-umwelt-sh-gitlab
Attribut gitlab-token <GitLab-Token des LfU>
Mitglieder Schema-Verantwortliche, Service Account landesamt-fuer-umwelt-sh-schema-client

Schritte in Keycloak

  1. Unter Groups zwei neue Gruppen anlegen: landesamt-fuer-umwelt-sh-ckan und landesamt-fuer-umwelt-sh-gitlab.
  2. In landesamt-fuer-umwelt-sh-ckan im Tab Attributes nur ckan-token setzen.
  3. In landesamt-fuer-umwelt-sh-gitlab im Tab Attributes nur gitlab-token setzen.
  4. Benutzer und Service Accounts jeweils nur der Gruppe zuweisen, die ihrer Rolle entspricht.