Jede Fachanwendung mit eigenem Login ist ein eigenes kleines Sicherheitsrisiko – und die meisten kommunalen Geoportale leisten sich genau das. Ihre Mitarbeitenden haben längst eine Identität: Sie melden sich morgens am Active Directory an, die IT pflegt Gruppen, Berechtigungen und Offboarding-Prozesse. Und dann kommt das Geoportal und sagt: „Bitte noch ein Benutzername, bitte noch ein Passwort.” Das ist nicht nur unbequem. Es ist eine zweite, schlechter gepflegte Kopie Ihrer Identitätsverwaltung – mit verwaisten Konten, doppelter Passwortpflege und ohne zentrale Kontrolle. Der saubere Weg heißt Single Sign-on über einen Identity-Provider wie Keycloak, angebunden per OpenID Connect (OIDC). Und spätestens seit das OZG-Änderungsgesetz die föderierte Identität für Bürgerinnen und Bürger zum gesetzlichen Normalfall macht, gibt es keinen guten Grund mehr, die eigenen Mitarbeitenden schlechter zu behandeln.
Was SSO und OIDC wirklich leisten
Hinter Single Sign-on stecken zwei Standards, die sauber aufeinander aufbauen. OAuth 2.0 ist das Autorisierungs-Framework: Es regelt, wie eine Anwendung im Auftrag einer Person auf geschützte Ressourcen zugreifen darf, und definiert dafür vier Rollen – Resource Owner, Client, Authorization Server und Resource Server [1]. OpenID Connect setzt als „simple identity layer” auf OAuth 2.0 auf und ergänzt das, was OAuth bewusst offenlässt: die Authentifizierung der Endnutzerin und standardisierte Identitätsinformationen [2].
Für das Geoportal übersetzt sich das so:
| Begriff | Rolle im Protokoll | Funktion im Geoportal-Kontext |
|---|---|---|
| End-User / Resource Owner | Die Person, um deren Identität und Daten es geht [1] | Sachbearbeiterin im Bauamt, GIS-Administrator |
| Client / Relying Party | Anwendung, die Authentifizierung und Claims vom OpenID Provider benötigt [2] | Das Masterportal bzw. die Auskunftsanwendung |
| Authorization Server / OpenID Provider | Authentifiziert den Nutzer und stellt Tokens aus [1] | Keycloak |
| Resource Server | Hält die geschützten Ressourcen | Backend-Dienste: Auskunfts-API, geschützte Layer, Exporte |
Entscheidend ist der richtige Ablauf, der Flow. Der Authorization-Code-Flow liefert dem Browser nur einen kurzlebigen Code; die eigentlichen Tokens tauscht die Anwendung direkt mit dem Server aus. Die OIDC-Spezifikation benennt den Vorteil ausdrücklich: Es werden keine Tokens gegenüber dem User-Agent – und damit möglichen bösartigen Anwendungen mit Zugriff darauf – exponiert [2].
Ein Browser-Frontend ist dabei ein Public Client: Es kann kein Geheimnis sicher verwahren, ein hinterlegtes client_secret gilt per Definition nicht als vertraulich [1]. Genau dafür gibt es PKCE (Proof Key for Code Exchange): Es schützt den Authorization Code gegen Abfangen auf ungeschützten Pfaden [3]. Die aktuelle OAuth-Security-Best-Practice RFC 9700 (Januar 2025) macht daraus eine klare Ansage: Public Clients müssen PKCE verwenden, Authorization Server müssen es unterstützen, und für Confidential Clients ist es empfohlen [4]. Vom früher verbreiteten Implicit Flow, der Access Tokens direkt in der Browser-Antwort ausliefert, rät dieselbe Best Practice ausdrücklich ab [4] [5].
Merksatz: Authorization-Code-Flow mit PKCE ist der Standard für Web-Anwendungen – alles andere ist Altlast.
Warum der eigene Portal-Login das eigentliche Risiko ist
Der separate Login fühlt sich harmlos an. Er ist es nicht, denn er erzeugt drei strukturelle Probleme:
Verwaiste Konten. Verlässt eine Mitarbeiterin die Verwaltung, deaktiviert die IT ihr AD-Konto – das ist eingespielter Prozess. Das Portal-Konto mit eigenem Passwort kennt diesen Prozess nicht. Es lebt weiter, oft mit weitreichenden Rechten auf Eigentümerdaten, bis es irgendwann jemandem auffällt. Im Audit ist genau das die unangenehme Frage: „Wer kann hier eigentlich noch zugreifen?”
Doppelte Passwortpflege. Jedes zusätzliche Passwort senkt die Qualität aller Passwörter. Wer fünf Fachverfahren mit fünf Logins bedient, recycelt Passwörter oder klebt sie unter die Tastatur – nicht aus Böswilligkeit, sondern aus Notwehr.
Keine zentrale Rechteverwaltung. Berechtigungen, die im Portal selbst gepflegt werden, sind für die IT unsichtbar. Es gibt keinen Ort, an dem man verlässlich abliest, wer auf welche Daten zugreifen darf. Eine Berechtigungsmatrix, die nur in den Köpfen oder in einer Portal-Datenbank existiert, ist keine.
Die Konsequenz ist einfach: Identität gehört ins Active Directory beziehungsweise in den Identity-Provider – nicht ins Portal. Das Portal soll Identitäten konsumieren, nicht verwalten.
Wie die Integration konkret aussieht
Keycloak ist der etablierte Open-Source-Identity-Provider für genau dieses Szenario; aktuell ist die Major-Linie 26 [7]. Die Bausteine, mit denen Sie arbeiten, sind überschaubar: Ein Realm verwaltet eine Menge von Benutzern, Credentials, Rollen und Gruppen; Clients sind die Anwendungen, die Keycloak um Authentifizierung bitten; und Rollen gibt es als Realm-Rollen oder als Client-Rollen – ein eigener Rollen-Namespace je Anwendung [6].
Der entscheidende Punkt für die Verwaltung: Keycloak bringt einen LDAP/Active-Directory-Provider mit. Sie können einen oder mehrere Verzeichnisdienste in einem Realm föderieren und die LDAP-Attribute auf das Keycloak-Benutzermodell mappen; importierte Benutzer werden on-demand oder per periodischem Hintergrund-Task synchronisiert [6]. Das AD bleibt führendes System – Keycloak ist die Vermittlungsschicht, kein Konkurrenzverzeichnis. Rollen lassen sich dabei auch Gruppen zuweisen, sodass die vorhandene AD-Gruppenstruktur direkt zur Grundlage der Portalberechtigungen wird [6].
Der Gesamtablauf in fünf Schritten:
| Schritt | Komponente | Was passiert |
|---|---|---|
| 1 | Active Directory | Bleibt führend für Identitäten, Gruppen, Offboarding |
| 2 | Keycloak (Federation) | Föderiert das AD in einen Realm, synchronisiert Benutzer [6] |
| 3 | OIDC-Client | Das Geoportal meldet Nutzer per Auth-Code-Flow + PKCE an [4] |
| 4 | Rollen / Berechtigungsmatrix | AD-Gruppen werden auf Portalrollen abgebildet; das Backend setzt sie serverseitig durch |
| 5 | Public-Mode | Stammdaten bleiben ohne Login zugänglich – der Bürgerzugang braucht kein Konto |
In der Praxis sieht die Berechtigungsmatrix dann etwa so aus: Die AD-Gruppe „GIS-Sachbearbeitung” wird zur Portalrolle für die Eigentümerauskunft, „Bauamt” sieht zusätzlich interne Planungslayer, und wer in keiner der Gruppen ist, bekommt genau das, was auch die Öffentlichkeit sieht. Wichtig ist die Durchsetzung am richtigen Ort: Das Backend prüft die Rolle bei jedem Zugriff – nicht das Frontend. Ein ausgeblendeter Menüpunkt ist keine Zugriffskontrolle.
Die ehrliche Bestandsaufnahme: Wo SSO-Projekte scheitern
SSO-Projekte scheitern selten an Keycloak. Sie scheitern an Details, die man am Anfang für Nebensachen hält:
Der falsche Flow. Ältere Anleitungen empfehlen noch den Implicit Flow. Der liefert Access Tokens direkt über den Browser aus – ohne Client-Authentifizierung, mit Exposition des Tokens im User-Agent [1]. RFC 9700 rät davon ab; wer heute neu baut, baut Auth-Code-Flow mit PKCE [4].
Sorgloses Token-Handling. Tokens sind Schlüssel, und Schlüssel sollen schnell verfallen. Der über die BSI-Website veröffentlichte benutzerdefinierte Grundschutz-Baustein „IAM Dienst Keycloak” (APP.bd.3) formuliert es als SOLLTE-Anforderungen: Access- und Refresh-Token-Lebensdauern begrenzen und Authorization Codes nur wenige Sekunden gültig halten; außerdem soll ein Access Token nur die Rollen des anfragenden Clients enthalten, damit eine Kompromittierung nicht gleich weitere Systeme trifft [8]. Dieselbe Quelle und RFC 9700 fordern übereinstimmend möglichst exakte Redirect-URIs je Client – Wildcards sind eine Einladung zur Client-Imitation [8] [4].
Fehlendes Single-Logout. Login bauen alle, Logout vergessen viele. OIDC definiert dafür zwei finalisierte Spezifikationen: RP-Initiated Logout, bei dem die Anwendung den Nutzer über den end_session_endpoint des Providers abmeldet [9], und Back-Channel Logout, bei dem der Provider die angeschlossenen Anwendungen direkt – ohne Umweg über den Browser – per Logout-Token informiert [10]. Wer das nicht einplant, hat Sitzungen, die den Feierabend überleben.
Rollen-Wildwuchs. Wenn jede Anwendung ihre Rollen frei erfindet, entsteht in zwei Jahren ein undurchdringliches Geflecht. Client-Rollen als sauberer Namespace je Anwendung [6] und eine schriftliche Berechtigungsmatrix („AD-Gruppe → Rolle → Recht”) halten das Modell auditierbar.
AD-Mapping-Fehler. Wer den Synchronisationsmodus nicht versteht, wundert sich über veraltete Gruppenzugehörigkeiten. Klären Sie früh, ob Benutzer importiert und periodisch synchronisiert werden oder ob Keycloak das Verzeichnis direkt befragt [6] – und testen Sie den Fall „Mitarbeiter wechselt die Abteilung” explizit.
Die Brücke zum Masterportal – und zum Bürger
Für das Masterportal ist OIDC kein Fremdkörper, sondern dokumentierter Bestandteil: Die config.js kennt ein login-Modul mit Parametern wie oidcAuthorizationEndpoint, oidcTokenEndpoint, oidcClientId und oidcRedirectUri; das abgerufene Access Token wird in Cookies gehalten, über die das Backend nutzerspezifische Inhalte – etwa geschützte Layer – ausliefern kann [12]. Genauso wichtig ist, was die Doku ebenfalls festhält: Das login-Modul ist optional [12]. Der Public-Mode ist also kein Sonderbau, sondern der Normalfall – Bürgerinnen und Bürger sehen Stammdaten ohne Konto, und erst die geschützten Funktionen verlangen die Anmeldung über Keycloak.
Dass dieses Muster produktionsreif ist, zeigt die Praxis: Das Thüringer Landesamt für Bodenmanagement und Geoinformation hat seine Online-Liegenschaftsauskunft ONLIKA 4.0 auf Masterportal-Basis mit Authentifizierung über Keycloak und BundID umgesetzt – vorgestellt auf der FOSSGIS 2025 [13].
Und der rechtliche Rückenwind ist da: Das Onlinezugangsgesetz definiert das Nutzerkonto als „zentrale IT-Komponente zur einmaligen oder dauerhaften Identifizierung und Authentifizierung der Nutzer” und sieht für Bürgerinnen und Bürger ein zentrales, vom Bund bereitgestelltes Bürgerkonto vor [11]; die jüngste Novelle – das OZG-Änderungsgesetz vom 19. Juli 2024, gemeinhin OZG 2.0 – hat diesen Kurs bekräftigt [11]. Die Richtung ist für Bürger- wie für Mitarbeiteridentitäten dieselbe, und sie entspricht dem Grundgedanken von Registermodernisierung und „Einer für Alle”: Identitäten werden einmal geführt und wiederverwendet, nicht je Verfahren neu erfunden. Ein Geoportal mit eigenem Insellogin fährt gegen diese Richtung.
Daraus folgt die These für GISRede-Projekte: Identität zentral, Berechtigung serverseitig – alles andere ist Bastelei.
Handlungsempfehlung: In fünf Schritten zum SSO im Geoportal
- Vorhandene AD-Struktur erfassen. Welche Gruppen existieren, welche davon taugen als Berechtigungsgrundlage, wo ist Wildwuchs? Das Offboarding muss über das AD nachweisbar funktionieren – sonst erbt das SSO ein kaputtes Fundament.
- Keycloak mit AD-Federation aufsetzen. Einen Realm für die Verwaltung anlegen, den LDAP/AD-Provider konfigurieren, Synchronisation einrichten und mit einer Handvoll Testnutzern verifizieren [6]. Die ausführliche Schritt-für-Schritt-Anleitung dazu: Keycloak für Kommunen einrichten.
- OIDC-Client für das Masterportal konfigurieren. Authorization-Code-Flow mit PKCE [4], exakte Redirect-URIs, kurze Token-Lebensdauern [8]; im Portal das
login-Modul mit den Keycloak-Endpunkten befüllen [12]. - Berechtigungsmatrix definieren. AD-Gruppen auf Portalrollen abbilden, je Anwendung als Client-Rollen geführt, und die Durchsetzung ins Backend legen. Die Matrix gehört schriftlich dokumentiert – sie ist Ihr Audit-Nachweis.
- Public-Mode und Single-Logout testen, Sicherheitsabnahme einplanen. Der Bürgerzugang ohne Login muss unverändert funktionieren; RP-Initiated und Back-Channel Logout gehören in den Testplan [9] [10], ebenso der Fall „AD-Konto deaktiviert → Portalzugriff endet”.
Fazit
SSO im kommunalen Geoportal ist kein Komfort-Feature, sondern ein Sicherheits- und Compliance-Thema. Die Standards sind fertig und eindeutig: OIDC auf OAuth 2.0, Authorization-Code-Flow mit PKCE als verbindliche Best Practice [4], Keycloak als ausgereifter Identity-Provider mit eingebauter AD-Federation [6] und ein Masterportal, das OIDC von Haus aus spricht [12].
Gewinnen werden die Kommunen, die Identität zentral führen und Berechtigungen serverseitig durchsetzen – mit einem Bürgerzugang, der keinen Login verlangt, und einem Fachzugang, der sich nahtlos an die vorhandene Verzeichnisstruktur hängt. Verlieren werden die, die Portallogins isoliert pflegen, Konten verwaisen lassen und sich im nächsten Audit erklären müssen.
GISRede hat diese Kette – AD-Federation, Keycloak, OIDC-Client, rollenbasierte Auskunft mit öffentlichem Bürgerbereich – in kommunalen Geoportalen produktiv umgesetzt. Wie das Rollenmodell und die Anmeldung im Produkt ALKIS Direkt ausgeliefert werden, zeigt der Abschnitt Rollenmodell und Anmeldung in ALKIS Direkt. Wenn Sie vor der Entscheidung stehen oder einen Bestand modernisieren wollen: Sprechen Sie Chris Redekop an.
Quellen
- [1] RFC 6749: The OAuth 2.0 Authorization Framework (IETF)
- [2] OpenID Connect Core 1.0 (OpenID Foundation)
- [3] RFC 7636: Proof Key for Code Exchange by OAuth Public Clients (IETF)
- [4] RFC 9700: Best Current Practice for OAuth 2.0 Security (IETF, BCP 240)
- [5] OAuth 2.0 Security Best Current Practice (oauth.net)
- [6] Keycloak Server Administration Guide (Keycloak-Projekt)
- [7] Keycloak 26.6.3 released (Keycloak-Projekt, 04.06.2026)
- [8] Benutzerdefinierter IT-Grundschutz-Baustein APP.bd.3 „IAM Dienst Keycloak” (PDF, via BSI)
- [9] OpenID Connect RP-Initiated Logout 1.0 (OpenID Foundation)
- [10] OpenID Connect Back-Channel Logout 1.0 (OpenID Foundation)
- [11] Onlinezugangsgesetz (OZG), konsolidierte Fassung (gesetze-im-internet.de)
- [12] Masterportal-Dokumentation: config.js, Modul „login” (masterportal.org)
- [13] FOSSGIS 2025: Masterportal – Liegenschaftsauskunft ONLIKA 4.0 mit Keycloak und BundID (media.ccc.de)