{ "componentChunkName": "component---src-templates-plugin-docs-tsx", "path": "/plugins/scm-oauth2-plugin/docs/1.0.x/DATENSCHUTZ_FOLGEABSCHAETZUNG/", "result": {"data":{"plugin":{"name":"scm-oauth2-plugin","displayName":"OAuth2/OIDC","description":"Authentication for SCM-Manager using OAuth2/OIDC","author":"Thorsten Ludewig","documentation":[{"version":"1.0.x","languages":["DATENSCHUTZ_FOLGEABSCHAETZUNG","PROZESS_BESCHREIBUNG","COMPLIANCE_BERICHT","SOURCECODE_STATISTIK","javadoc"]}]},"navigation":{"nodes":[]},"versions":{"group":[{"fieldValue":"1.0.x"}]},"languages":{"group":[{"fieldValue":"COMPLIANCE_BERICHT"},{"fieldValue":"DATENSCHUTZ_FOLGEABSCHAETZUNG"},{"fieldValue":"PROZESS_BESCHREIBUNG"},{"fieldValue":"SOURCECODE_STATISTIK"},{"fieldValue":"javadoc"}]},"markdownRemark":{"html":"

Datenschutz-Folgenabschätzung — scm-oauth2-plugin

\n

Dokumentversion: 1.1 · Stand: 17.08.2026 · Softwarestand: scm-oauth2-plugin 1.0.2\nVerarbeitung: Authentifizierung und Zugriffssteuerung für SCM-Manager über einen\nOAuth2/OIDC-Identity-Provider\nRechtsgrundlage der Prüfung: Art. 35 DSGVO

\n
\n

Status dieses Dokuments: Bereitgestellt wird die technische Hälfte einer DSFA — Beschreibung\nder Verarbeitung, Risikobetrachtung aus Sicht der betroffenen Personen und die im Produkt\numgesetzten Abhilfemaßnahmen. Eine DSFA ist nach Art. 35 Abs. 1 DSGVO Aufgabe des\nVerantwortlichen; die in Abschnitt 7 offen gelassenen Felder (Rechtsgrundlage,\nErforderlichkeitsprüfung im konkreten Kontext, Fristen, Beteiligung des\nDatenschutzbeauftragten nach Art. 35 Abs. 2, ggf. Standpunkt der betroffenen Personen nach\nArt. 35 Abs. 9) sind dort auszufüllen. Kein Ersatz für Rechtsberatung.

\n
\n

1. Schwellwertanalyse — ist eine DSFA verpflichtend?

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
PrüfpunktErgebnis
Systematische umfassende Bewertung persönlicher Aspekte, automatisierte Entscheidung mit erheblicher Auswirkung (Art. 35 Abs. 3 lit. a)nein — kein Profiling, keine Bewertung von Verhalten oder Leistung; die einzige Automatik ist die Zuordnung von Zugriffsrechten anhand vorhandener Gruppenzugehörigkeiten
Umfangreiche Verarbeitung besonderer Kategorien (lit. b)nein, sofern der Gruppen-Claim keine Angaben nach Art. 9 transportiert (Bedingung, siehe Risiko RI-05)
Systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche (lit. c)nein
Einsatz neuer Technologien mit hohem Risikonein — etablierte Standards (RFC 6749, 7636, 9700, OIDC Core)
Kriterien der DSK-Liste („Muss-Liste\")keines der Regelbeispiele erfüllt; die Verarbeitung ist eine Zugangskontrolle im Rahmen der IT-Nutzung
Betroffene PersonenBeschäftigte bzw. berechtigte Nutzer der Instanz — abgrenzbarer, dem Verantwortlichen bekannter Personenkreis
\n

Ergebnis: Eine DSFA ist nach hiesiger Einschätzung nicht zwingend erforderlich. Die\nVerarbeitung erfolgt jedoch im Beschäftigungskontext, betrifft alle Nutzer der Instanz und steuert\nZugriffsrechte auf Quellcode; die nachfolgende Betrachtung wird daher freiwillig durchgeführt\nund dient zugleich der Erfüllung der Rechenschaftspflicht (Art. 5 Abs. 2 DSGVO). Fällt die Prüfung\nin Abschnitt 7 beim Verantwortlichen anders aus (etwa wegen Art. 9-Bezug im Gruppen-Claim), ist sie\nals vollwertige DSFA fortzuschreiben.

\n

2. Systematische Beschreibung der Verarbeitung (Art. 35 Abs. 7 lit. a)

\n

Die vollständige technische Beschreibung ist ausgelagert:\nPROZESS_BESCHREIBUNG.md. Kurzfassung:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
MerkmalAngabe
VerarbeitungsvorgängeAnmeldung (Authorization Code Flow mit PKCE), Kontobereitstellung/-migration, Gruppen- und Rechtesynchronisation, Autorisierung, Abmeldung, Administration
DatenkategorienBenutzerkennung, Anzeigename, E-Mail-Adresse, Gruppen-/Rollenzugehörigkeiten, technische Tokens, Anmeldezeitpunkte in Protokollen
Betroffene Personenalle Nutzer der SCM-Manager-Instanz
Verarbeitungsortausschließlich die Instanz des Verantwortlichen; keine Übermittlung an den Hersteller, keine Telemetrie
Empfängerausschließlich der konfigurierte IdP
SpeicherdauerKonfiguration und Gruppenliste bis zur Änderung/Löschung; ID Token max. 12 h im Arbeitsspeicher; Anmeldevorgänge max. 10 min; Protokolle nach Konzept des Betreibers
Automatisierte EinzelentscheidungZuweisung/Entzug von Zugriffsrechten anhand der Gruppenzugehörigkeit (kein Fall des Art. 22 Abs. 1 nach hiesiger Einschätzung)
\n

3. Erforderlichkeit und Verhältnismäßigkeit (Art. 35 Abs. 7 lit. b)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
FrageBewertung
Ist die Verarbeitung zur Zweckerreichung erforderlich?Ja. Ein Zugriff auf Repositories ohne Authentifizierung und Autorisierung ist nicht möglich; die verarbeiteten Daten sind das Minimum für Kontoidentität und Rechtezuordnung.
Gibt es ein milderes Mittel?Die lokale Benutzerverwaltung wäre kein milderes Mittel: sie erfordert dieselben Daten, zusätzlich lokale Passwörter (eigenes Risiko) und verhindert den zentralen Rechteentzug beim Offboarding. SSO reduziert die Zahl der Stellen, an denen Anmeldedaten verarbeitet werden.
Ist die Datenmenge angemessen?Grundsätzlich ja — mit Einschränkung bei Gruppen-/Rollenlisten, die über Zugriffsgruppen hinausgehen (Befund B-03, Risiko RI-05).
Ist die Speicherdauer angemessen?Ja für alle flüchtigen Daten. Einschränkung bei der Gruppendatei nach Kontolöschung (Befund B-01, Risiko RI-04).
TransparenzDer Anmeldevorgang ist für die betroffene Person sichtbar (Umleitung zum IdP, benannter Provider auf der Schaltfläche). Informationspflichten nach Art. 13 erfüllt der Verantwortliche.
\n

4. Risikobetrachtung (Art. 35 Abs. 7 lit. c)

\n

Bewertet wird das Risiko für die Rechte und Freiheiten der betroffenen Personen, jeweils nach\nUmsetzung der im Produkt vorhandenen Maßnahmen (Restrisiko). Skala: gering / mittel / hoch.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
IDRisiko / SchadensszenarioUrsacheEintrittSchwereRestrisiko
RI-01Fremdübernahme des Kontos: Angreifer verknüpft seine IdP-Identität mit der Sitzung der betroffenen Person (Login-CSRF) und handelt unter deren Namenmanipulierter Rücksprung auf den Callbackgeringhochgering
RI-02Abfangen des Autorisierungscodes und Einlösung durch Dritteoffener Redirect, Code-Interceptiongeringhochgering
RI-03Unbefugte Rechteausweitung: eine Person erhält Administratorrechte und damit Zugriff auf fremden Quellcodefehlerhafte Gruppenpflege im IdP, kompromittiertes Konto mit Konfigurationsschreibrechtmittelhochmittel
RI-04Weiterverarbeitung nach Ausscheiden: Gruppenzugehörigkeiten bleiben nach Kontolöschung gespeichertkeine Kaskadenlöschung der Datei je Benutzerhochgeringmittel
RI-05Zweckentfremdung von Organisations- und Beschäftigungsmerkmalen, die über den Gruppen-Claim mitgeliefert werden (z. B. Fakultät, Beschäftigtenart, Standort); im Extremfall Merkmale nach Art. 9Gruppen-Claim des IdP nicht auf Zugriffsgruppen begrenztmittelmittelmittel
RI-06Offenlegung von Benutzerkennungen und Gruppennamen gegenüber Personen mit Log-ZugriffProtokollierung auf INFOmittelgeringgering
RI-07Übernahme eines lokalen Kontos durch eine gleichnamige IdP-IdentitätNamenskollision zwischen lokaler und IdP-Kennunggeringhochgering
RI-08Vertraulichkeitsverlust der Identitätsdaten auf dem Transportwegfehlende oder unwirksame TLS-Prüfunggeringhochgering
RI-09Aussperrung berechtigter Personen (Verfügbarkeit als Betroffenenbelang)Ausfall des IdP bei aktiviertem forceLogin; nicht erreichbarer JWKS-Endpunkt bei vorhandenem ID Token (fail closed)mittelmittelmittel
RI-10Offenlegung des Client-Secrets und damit Angriff auf die KopplungAuslesen der Konfiguration oder eines Backupsgeringhochgering
RI-11Untergeschobenes oder wiederverwendetes Token: eine gefälschte oder aus einer anderen Sitzung stammende Identitätsaussage führt zur Anmeldung unter fremdem Namen oder zu fremden Rollenfehlende Signatur-, Aussteller- oder Nonce-Prüfunggeringhochgering
\n

5. Abhilfemaßnahmen (Art. 35 Abs. 7 lit. d)

\n

5.1 Im Produkt umgesetzt

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RisikoMaßnahme im Code
RI-01state wird an den Browser gebunden (HttpOnly-Cookie X-SCM-OAuth2-State), zeitkonstant verglichen und ist einmalig einlösbar; abweichende oder unbekannte Werte führen zu HTTP 401
RI-02PKCE mit S256 — der Verifier verlässt den Server nie; Umleitungsziele werden auf instanzinterne Pfade begrenzt (//host, /\\, CR/LF werden abgewiesen); der Code wird ausschließlich Server-zu-Server eingelöst
RI-03Rechtevergabe beschränkt auf die Einzelberechtigung * des betroffenen Benutzers; automatischer Entzug, sobald die Gruppe fehlt; Zugriff auf die Konfiguration nur mit dedizierter Berechtigung; Endpunkt-URLs auf http/https mit Host begrenzt
RI-04Speicherstruktur ist gezielt löschbar (eine Datei je Benutzer, Dateiname = Kennung); flüchtige Speicher laufen selbsttätig ab (10 min / 12 h)
RI-05Nur die konfigurierten Claims werden gelesen; der Rollenimport aus dem Access Token ist standardmäßig aus
RI-06Die E-Mail-Adresse wird nicht mehr protokolliert; bei einer ungültigen Adresse nennt die Meldung nur Benutzerkennung und Länge des Wertes
RI-06Tokens, code, state, Verifier und Secret werden nie protokolliert; IdP-Fehlertexte gelangen nicht zum Browser
RI-07Konten mit lokalem Passwort werden nicht übernommen, solange migrateLocalUsers nicht ausdrücklich gesetzt ist; bei Übernahme wird das lokale Passwort entfernt, damit kein zweiter Zugangsweg bestehen bleibt
RI-08TLS-Zertifikatsprüfung im Produktivbetrieb immer aktiv (Abschaltung nur in der Entwicklungs-Stage)
RI-09forceLogin ist standardmäßig aus, die klassische Anmeldung bleibt damit als Rückfallweg verfügbar; die Abmeldung funktioniert auch ohne verfügbares ID Token
RI-10Client-Secret wird verschlüsselt gespeichert, von der API nie ausgeliefert und bei leerer Eingabe unverändert beibehalten
RI-11Signatur des ID Tokens wird gegen den JWKS des IdP bzw. das Client-Secret geprüft, alg: none und unbekannte Verfahren werden abgewiesen, der Algorithmus bestimmt den Schlüsseltyp; zusätzlich werden iss, aud/azp, Laufzeit und der Nonce dieser Anmeldung geprüft. Rollen werden nur aus einem geprüften Access Token übernommen. Ein vorhandenes, aber ungültiges ID Token bricht die Anmeldung ab.
\n

Die Wirksamkeit ist durch gezielte Tests belegt (u. a. fehlendes/abweichendes state-Cookie,\nWiederverwendung eines state, Umleitung auf einen Fremdhost, gefälschtes Access-Token-Cookie,\nAblehnung lokaler Konten, Geheimnisbehandlung) — siehe\nSOURCECODE_STATISTIK.md.

\n

5.2 Vom Verantwortlichen umzusetzen

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RisikoErforderliche MaßnahmePriorität
RI-04Löschung von var/data/oauth2Groups/<kennung>.xml in den Offboarding-Prozess aufnehmen; Umsetzung einer automatischen Löschung im Plugin anstoßen (Befund B-01)hoch
RI-05Gruppen-/Rollen-Claim im IdP auf die für SCM-Manager erforderlichen Gruppen begrenzen (eigener Client-Scope bzw. gefilterter Mapper); prüfen, ob importRealmRoles benötigt wird (Befund B-03)hoch
RI-03configuration:write:oauth2 wie ein Administratorrecht behandeln; Änderungen an der Admin-Gruppe im IdP der Änderungskontrolle unterwerfenhoch
RI-06Log-Level, Zugriff auf Protokolldateien und Aufbewahrungsfrist festlegenmittel
RI-11Discovery-URL verwenden oder jwksUrl konfigurieren, damit die Tokenprüfung greifen kann; Warnungen des Plugins zur fehlenden Schlüsselquelle auswertenhoch
RI-09Notfallzugang ohne SSO vorhalten (lokales Administratorkonto), Verfügbarkeit von IdP und JWKS-Endpunkt im Notfallkonzept berücksichtigenmittel
RI-08Produktivsysteme nie in der Entwicklungs-Stage betreiben; Zertifikatsverwaltung des IdP prüfenmittel
RI-10Zugriffsschutz auf das Heimatverzeichnis und die Backups; Secret bei Verdacht im IdP rotierenmittel
alleInformationspflichten nach Art. 13, Eintrag im Verzeichnis nach Art. 30, ggf. Beteiligung des Betriebs-/Personalrats (in Deutschland regelmäßig § 87 Abs. 1 Nr. 6 BetrVG bzw. landesrechtliche Entsprechung)hoch
\n

6. Bewertung des Restrisikos

\n

Nach Umsetzung der Maßnahmen aus 5.1 und 5.2 verbleiben keine hohen Risiken. Die drei\nmittleren Restrisiken (RI-03, RI-04, RI-05) sind sämtlich durch Konfiguration und\nBetriebsorganisation beherrschbar; RI-04 und RI-05 werden mit den Befunden B-01 und B-03\nadressiert.

\n

Gegenüber Version 1.0 dieses Dokuments ist RI-11 (untergeschobene Tokens) neu aufgenommen und\nunmittelbar auf gering gesenkt, weil die Tokenprüfung in 1.0.2 implementiert wurde; RI-06 ist\ndurch den Verzicht auf die Protokollierung der E-Mail-Adresse weiter reduziert. Voraussetzung für\ndie Wirksamkeit der Tokenprüfung ist eine erreichbare Schlüsselquelle (Discovery-URL oder\njwksUrl).

\n

Eine vorherige Konsultation der Aufsichtsbehörde nach Art. 36 DSGVO ist danach nicht\nerforderlich.

\n

7. Auszufüllen durch den Verantwortlichen

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
FeldEintrag
Verantwortlicher (Name, Anschrift, Kontakt)
Datenschutzbeauftragte(r), Datum der Beteiligung nach Art. 35 Abs. 2
Bezeichnung der Instanz, Basis-URL
Identity Provider (Produkt, Betreiber, Standort der Verarbeitung)
Drittlandbezug, Übermittlungsgrundlage nach Kapitel V
Rechtsgrundlage der Verarbeitung (Art. 6 Abs. 1; ggf. § 26 BDSG / landesrechtliche Norm)
Kreis der betroffenen Personen, Anzahl
Löschfristen: Benutzerkonto, Gruppendatei, Protokolldateien
Beteiligung des Betriebs-/Personalrats
Standpunkt der betroffenen Personen (Art. 35 Abs. 9), soweit eingeholt
Ergebnis der Erforderlichkeitsprüfung im konkreten Kontext
Abweichungen von Abschnitt 1 (Schwellwert) mit Begründung
Freigabe (Name, Funktion, Datum)
Termin der Überprüfung (Art. 35 Abs. 11)
\n

8. Überprüfung

\n

Die Abschätzung ist fortzuschreiben bei:

\n\n
\n

Weiterführend: Prozessbeschreibung ·\nCompliance-Bericht · Sourcecode-Statistik

","description":"Datenschutz-Folgenabschätzung — scm-oauth2-plugin Dokumentversion: 1.1 · Stand: 17.08.2026 · Softwarestand: scm-oauth2-plugin 1.0.2\nVerarbeitung…","tableOfContents":"","frontmatter":{"title":"","subtitle":null,"description":null,"keywords":null,"displayToc":null,"image":null}}},"pageContext":{"name":"scm-oauth2-plugin","slug":"/plugins/scm-oauth2-plugin/docs/1.0.x/DATENSCHUTZ_FOLGEABSCHAETZUNG/","version":"1.0.x","latestVersion":"1.0.x","latestPageVersion":"1.0.x","language":"DATENSCHUTZ_FOLGEABSCHAETZUNG","canonicalPath":"/plugins/scm-oauth2-plugin/docs/latest/DATENSCHUTZ_FOLGEABSCHAETZUNG/","latestRootPath":"/plugins/scm-oauth2-plugin/docs/1.0.x/DATENSCHUTZ_FOLGEABSCHAETZUNG/"}}, "staticQueryHashes": ["1973669194","2742214048","2956773653","2957019495","698804963"]}