{ "componentChunkName": "component---src-templates-plugin-docs-tsx", "path": "/plugins/scm-oauth2-plugin/docs/1.0.x/PROZESS_BESCHREIBUNG/", "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":"

Prozessbeschreibung — scm-oauth2-plugin

\n

Dokumentversion: 1.1 · Stand: 17.08.2026 · Softwarestand: scm-oauth2-plugin 1.0.2

\n

Technische Beschreibung der Verarbeitungsvorgänge des Plugins als Grundlage für das Verzeichnis von\nVerarbeitungstätigkeiten (Art. 30 DSGVO), für die Risikoanalyse nach Art. 21 Abs. 2 NIS2 und für die\nDatenschutz-Folgenabschätzung.

\n
\n

Hinweis zur Verwendung: Dieses Dokument beschreibt ausschließlich das Verhalten der Software.\nAlle organisatorischen Festlegungen (Rechtsgrundlage, Löschfristen, Verantwortlichkeiten,\nAuftragsverarbeitung, Mitbestimmung) trifft der Verantwortliche für seine Instanz. Es handelt sich\nnicht um Rechtsberatung.

\n
\n

Inhalt

\n
    \n
  1. Rollen und Abgrenzung
    2. \n
  2. Zweck der Verarbeitung
    3. \n
  3. Datenkategorien
    4. \n
  4. Prozess 1 — Anmeldung (Authorization Code Flow)
    5. \n
  5. Prozess 2 — Benutzerbereitstellung und Migration
    6. \n
  6. Prozess 3 — Gruppen- und Berechtigungssynchronisation
    7. \n
  7. Prozess 4 — Autorisierung im laufenden Betrieb
    8. \n
  8. Prozess 5 — Abmeldung (RP-initiated Logout)
    9. \n
  9. Prozess 6 — Administration der Konfiguration
    10. \n
  10. Speicherorte und Speicherdauer
    11. \n
  11. Protokollierung
    12. \n
  12. Empfänger und Datenflüsse nach außen
    13. \n
  13. Schnittstellen
    14. \n
\n

1. Rollen und Abgrenzung

\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
RolleZuordnung
Verantwortlicher (Art. 4 Nr. 7 DSGVO)Betreiber der SCM-Manager-Instanz
Weiterer VerantwortlicherBetreiber des Identity Providers (IdP), sofern organisatorisch getrennt
Auftragsverarbeiterkeiner durch das Plugin — die Software wird lokal betrieben, es findet kein Datenfluss zum Autor oder zu Dritten statt
DatenquelleIdP (OAuth2/OIDC), mittelbar das dahinterliegende Verzeichnis (z. B. LDAP/AD)
\n

Das Plugin ist eine lokal installierte Softwarekomponente (.smp-Paket, 96 KB) innerhalb des\nSCM-Manager-Prozesses. Es betreibt keinen eigenen Dienst, öffnet keine ausgehenden Verbindungen\naußer zu den konfigurierten IdP-Endpunkten und enthält keine Telemetrie.

\n

Abgrenzung zum SCM-Manager-Kern: Benutzerkonten, Gruppen, Berechtigungen, Sitzungs-Cookies und\ndas Logging werden vom Kern verwaltet und persistiert. Das Plugin ruft dessen Schnittstellen auf\n(UserManager, GroupManager, SecuritySystem, SyncingRealmHelper, AccessTokenCookieIssuer).\nEigene Datenhaltung des Plugins: die Datei je Benutzer unter var/data/oauth2Groups/ sowie zwei\nflüchtige Speicher im Arbeitsspeicher (siehe Abschnitt 10).

\n

2. Zweck der Verarbeitung

\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
ZweckVerarbeitungsschritte
Authentifizierung von Benutzern an SCM-Manager über einen zentralen IdP (Single Sign-on)Prozess 1
Bereitstellung und Aktualisierung des lokalen BenutzerkontosProzess 2
Zugriffssteuerung anhand der im IdP gepflegten Gruppen und RollenProzesse 3 und 4
Beendigung der Sitzung, optional auch der IdP-SitzungProzess 5
Betrieb und Administration der KopplungProzess 6
\n

Es findet kein Profiling und keine Verhaltens- oder Leistungsbewertung statt. Die einzige\nautomatisierte Entscheidung ist die Zuweisung bzw. der Entzug von Zugriffsrechten anhand der\nGruppenzugehörigkeit (siehe DSFA, Abschnitt zu Art. 22).

\n

3. Datenkategorien

\n

Welche Claims gelesen werden, ist konfigurierbar; die Spalte „Standard\" nennt die Vorbelegung.

\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
Nr.DatumQuelle (Claim)StandardPersonenbezug
D1BenutzerkennungusernameAttribute, ersatzweise subpreferred_usernameja, identifizierend
D2AnzeigenamedisplayNameAttributenameja, identifizierend
D3E-Mail-AdressemailAttributeemailja, identifizierend
D4GruppenzugehörigkeitengroupAttributegroupsja, ggf. aussagekräftig (s. u.)
D5Rollen aus dem Access TokenJSON-Pfad, nur bei importRealmRolesrealm_access.rolesja, ggf. aussagekräftig
D6Access TokenToken-Endpunkt des IdP—mittelbar; nicht gespeichert
D7ID TokenToken-Endpunkt des IdP—enthält sub; im Arbeitsspeicher, max. 12 h
D8state, PKCE-Verifier und Nonceim Plugin erzeugt—kein Personenbezug, im Arbeitsspeicher, max. 10 min
D9Anmeldezeitpunkt, Vorgangsausgangimplizit im Protokoll—ja, in Verbindung mit D1
\n
\n

Datenminimierung, Hinweis D4/D5: Gruppen- und Rollenlisten produktiver IdP-Installationen\nenthalten häufig weit mehr als Zugriffsgruppen — etwa Organisationseinheit, Fakultät,\nBeschäftigtenart oder Standort. Diese Angaben werden vollständig in\nvar/data/oauth2Groups/<kennung>.xml abgelegt. Der Verantwortliche sollte den Gruppen-Claim im\nIdP auf die für SCM-Manager erforderlichen Gruppen einschränken (Mapper-/Scope-Konfiguration);\nsiehe Compliance-Bericht, Befund B-03.

\n
\n

Besondere Kategorien nach Art. 9 DSGVO werden nicht verarbeitet, sofern der Gruppen-Claim keine\nentsprechenden Angaben transportiert (z. B. Gewerkschafts- oder Gesundheitsbezug in Gruppennamen).\nDie Prüfung dieser Bedingung obliegt dem Verantwortlichen.

\n

4. Prozess 1 — Anmeldung (Authorization Code Flow)

\n

Auslöser: Klick auf „Anmelden mit <Provider>\", oder automatische Umleitung durch\nForceOAuth2LoginFilter bei aktiviertem forceLogin.

\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\n\n\n\n\n\n
SchrittVorgangKomponenteVerarbeitete Daten
1GET /api/v2/oauth2/auth?from=<Ziel>OAuth2AuthenticationResourceZielpfad (validiert: nur instanzinterne Pfade)
2state (24 Byte Zufall), PKCE-Verifier (32 Byte) und Nonce (24 Byte) erzeugen, mit Zielpfad hinterlegenStateStore, PkceD8
3state als Cookie X-SCM-OAuth2-State setzen (HttpOnly, SameSite=Lax, Secure bei HTTPS, 600 s)StateCookieD8
4Endpunkte ermitteln: manuell konfiguriert oder aus dem Discovery-Dokument (1 h Cache)EndpointResolver, DiscoveryClientkeine personenbezogenen Daten
5HTTP 303 zum Authorization-Endpunkt mit client_id, redirect_uri, scope, state, nonce, code_challengeOAuth2AuthenticationResourceD8
6Authentifizierung beim IdP (Passwort, MFA, Zertifikat …)außerhalb des Plugins—
7Rücksprung GET /api/v2/oauth2/auth/callback?code=…&state=…OAuth2AuthenticationResourcecode, D8
8Prüfung: state stimmt mit dem Cookie dieses Browsers überein (zeitkonstanter Vergleich)OAuth2AuthenticationResourceD8
9state einlösen — einmalig, danach ungültigStateStoreD8
10Code gegen Tokens tauschen (Server-zu-Server, client_secret + code_verifier)OAuth2RestClientD6, D7
10aID Token prüfen: Signatur gegen den JWKS des IdP bzw. gegen das Client-Secret, dazu iss, aud/azp, Laufzeit und Nonce dieser Anmeldung; ein ungültiges Token bricht die Anmeldung abTokenVerifier, JwksProviderD7
11Claims vom Userinfo-Endpunkt abrufenOAuth2RestClientD1–D4
12Benutzer, Gruppen und Rechte bereitstellenProzesse 2 und 3D1–D5
13ID Token für einen späteren Logout vorhalten — nur wenn es geprüft werden konnteIdTokenStoreD7
14SCM-Access-Token-Cookie (JWT) ausstellenLoginHandler (Kern)D1
15HTTP 303 auf den Zielpfad, state-Cookie löschenOAuth2AuthenticationResource—
\n

Abbruchbedingungen — jeweils HTTP 401 mit statischem Text, ohne Rückgabe von IdP-Details:\nfehlendes oder abweichendes state-Cookie, unbekanntes oder abgelaufenes state, fehlender Code,\nFehlermeldung des IdP, ungültiges ID Token, fehlgeschlagene Authentifizierung.

\n

Grundsatz zur Tokenprüfung: Verwendet wird nur, was geprüft werden konnte. Steht keine\nSchlüsselquelle zur Verfügung (weder Discovery-URL noch konfigurierte jwksUrl), wird das ID Token\nverworfen und es werden keine Rollen aus dem Access Token übernommen — mit einer Warnung im\nProtokoll. Die Anmeldung selbst bleibt möglich, da die Identität aus dem über TLS abgerufenen\nUserinfo-Endpunkt stammt.

\n

5. Prozess 2 — Benutzerbereitstellung und Migration

\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
FallVerhaltenKomponente
Konto existiert nichtNeuanlage als externes Konto ohne PasswortUserInfoMapper, SyncingRealmHelper
Konto existiert und ist extern (z. B. bisher LDAP)Übernahme; D2/D3 werden aktualisiert, alle übrigen Attribute bleiben erhaltenUserMigration
Konto existiert mit lokalem PasswortAnmeldung wird abgelehnt, sofern migrateLocalUsers nicht gesetzt istUserMigration
Konto existiert mit lokalem Passwort, migrateLocalUsers gesetztÜbernahme; das lokale Passwort wird entferntUserMigration
\n

Nicht gelieferte Claims überschreiben keine gespeicherten Werte (z. B. bleibt eine vorhandene\nE-Mail-Adresse erhalten, wenn der Claim fehlt). Eine syntaktisch ungültige E-Mail-Adresse wird\nverworfen, damit die Anmeldung nicht scheitert.

\n

Da das Konto und damit die Benutzerkennung erhalten bleibt, bleiben auch alle daran gebundenen\nZuordnungen bestehen: Berechtigungen, Repository-Eigentümerschaft, API-Schlüssel, manuell gepflegte\nGruppenmitgliedschaften.

\n

6. Prozess 3 — Gruppen- und Berechtigungssynchronisation

\n

Bei jeder Anmeldung, nach der Bereitstellung des Benutzers:

\n
    \n
  1. Zusammenführen von D4 und — falls aktiviert — D5. D5 wird nur aus einem signatur- und\nclaimgeprüften Access Token übernommen; andernfalls bleibt die Rollenliste leer.
    2. \n
  2. Normalisieren der Namen: in SCM-Manager unzulässige Zeichen werden durch _ ersetzt\n(GroupNameSanitizer), damit z. B. ein voller Keycloak-Gruppenpfad /entwickler als\n_entwickler nutzbar bleibt und nicht verloren geht.
    3. \n
  3. Ablegen der normalisierten Liste in var/data/oauth2Groups/<kennung>.xml (GroupStore) —\ndiese Liste ist die Grundlage der Autorisierung.
    4. \n
  4. Abgleich der Gruppenobjekte (GroupSynchronizer): fehlende Gruppen werden angelegt\n(Typ xml, Beschreibung „Synchronized by scm-oauth2-plugin\"), Mitgliedschaften werden ergänzt\nund für Gruppen entzogen, die bei der vorherigen Anmeldung vorhanden waren und jetzt fehlen.\nGruppen werden nie gelöscht, auch nicht wenn sie leer werden. Externe Gruppen bleiben\nunberührt.
    5. \n
  5. Administratorrecht (AdminGroupSynchronizer): enthält die Liste die konfigurierte\nadminGroup, wird die Berechtigung * zugewiesen, andernfalls eine früher zugewiesene entzogen.\nBetroffen ist ausschließlich die Einzelberechtigung * dieses Benutzers.
    6. \n
\n

Schritte 4 und 5 laufen mit erweiterten Rechten (AdministrationContext.runAsAdmin), da der\nBenutzer während der Anmeldung noch nicht authentifiziert ist. Fehler in diesen Schritten werden\nprotokolliert und brechen die Anmeldung nicht ab.

\n

7. Prozess 4 — Autorisierung im laufenden Betrieb

\n

Der Kern fragt bei jeder Anfrage alle registrierten GroupResolver. OAuth2GroupResolver liefert\ndie bei der letzten Anmeldung gespeicherte Liste aus var/data/oauth2Groups/. Dadurch wirken\nGruppenrechte auch bei Zugriffen ohne Browser-Sitzung (Git über HTTP, API-Schlüssel).

\n

Konsequenz für die Aktualität: Änderungen im IdP wirken erst mit der nächsten Anmeldung. Ein\nEntzug von Rechten im IdP beendet keine laufende SCM-Sitzung.

\n

8. Prozess 5 — Abmeldung (RP-initiated Logout)

\n

Nur bei aktiviertem ssoLogout. Der Kern beendet zuerst die lokale Sitzung, danach liefert\nAfterLogoutRedirectToIdp das Umleitungsziel:

\n\n

Ohne verfügbares ID Token (z. B. nach einem Neustart) funktioniert die Abmeldung weiterhin, der IdP\nzeigt dann ggf. eine Bestätigungsseite. Fehler führen zu „keine Umleitung\"; die lokale Abmeldung\nist in jedem Fall erfolgt.

\n

9. Prozess 6 — Administration der Konfiguration

\n

GET/PUT auf /api/v2/oauth2/configuration, geschützt durch\nconfiguration:read:oauth2 bzw. configuration:write:oauth2.

\n\n

Die Konfiguration enthält keine personenbezogenen Daten (Ausnahme: die Angaben zum IdP-Client sind\nZugangsdaten der Instanz, keine Personendaten).

\n

10. Speicherorte und Speicherdauer

\n

Pfade relativ zum SCM-Manager-Heimatverzeichnis (Linux/Docker typisch /var/lib/scm).

\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
OrtInhaltVerwaltet vonDauer / Löschung
config/oauth2.xmlKonfiguration inkl. verschlüsseltem Client-SecretPluginbis zur Änderung; Löschung mit dem Plugin
var/data/oauth2Groups/<kennung>.xmlnormalisierte Gruppen-/Rollenliste; der Dateiname ist die BenutzerkennungPluginwird bei jeder Anmeldung überschrieben; keine automatische Löschung, s. Befund B-01
Benutzerdatenbank des KernsD1–D3, Kennzeichen „extern\"KernLöschung mit dem Benutzerkonto
Gruppendatenbank des KernsGruppen und MitgliedschaftenKernMitgliedschaft wird bei Wegfall entzogen; Gruppenobjekt bleibt
Berechtigungen des KernsEinzelberechtigung * bei Admin-GruppeKernEntzug bei Wegfall der Gruppe
Arbeitsspeicher — StateStoreoffene Anmeldevorgänge (state, PKCE-Verifier, Nonce), max. 10.000Plugin10 Minuten oder Einlösung; Verlust bei Neustart
Arbeitsspeicher — JwksProvideröffentliche Schlüssel des IdP, keine personenbezogenen DatenPlugin1 Stunde, danach erneuter Abruf
Arbeitsspeicher — IdTokenStoreID Token je BenutzerPluginAbmeldung oder 12 Stunden; Verlust bei Neustart
Protokolldateiensiehe Abschnitt 11Kern (Logback)nach Protokollierungskonzept des Betreibers
Browser des BenutzersX-SCM-OAuth2-State (600 s), Access-Token-Cookie des KernsPlugin / KernAblauf bzw. Abmeldung
\n

Die beiden Arbeitsspeicher sind bewusst nicht persistent und nicht clusterfähig: In einem\nVerbund ohne Sitzungsbindung muss ein Anmeldevorgang, der auf einem anderen Knoten endet,\nwiederholt werden; die Abmeldung erfolgt dann ohne id_token_hint.

\n

11. Protokollierung

\n

Das Plugin schreibt über SLF4J in das Log des Kerns. 14 Ausgaben enthalten Kennungen:

\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
StufeAnzahlInhalt
INFO7Benutzerkennung bei Gruppenanlage, Mitgliedschaftsänderung, Rechtezuweisung/-entzug, Kontoübernahme; bei einer ungültigen Mail-Adresse nur Kennung und Länge des Wertes, nicht die Adresse selbst
WARN / ERROR4Benutzerkennung und Gruppenname bei fehlgeschlagener Synchronisation, abgelehnte Übernahme eines lokalen Kontos
DEBUG3Kontoname bei Wiederverwendung, Gruppennamen bei Normalisierung
\n

Nicht protokolliert werden: Tokens, code, state, Nonce, PKCE-Verifier, Client-Secret,\nE-Mail-Adressen. Fehlermeldungen\ndes IdP werden ausschließlich protokolliert und nie an den Browser zurückgegeben.

\n

12. Empfänger und Datenflüsse nach außen

\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
RichtungEmpfängerDatenKanal
ausgehend, BrowserIdPclient_id, redirect_uri, scope, state, code_challengeHTTP-Umleitung
ausgehend, ServerIdP Token-Endpunktcode, redirect_uri, client_id, client_secret, code_verifierHTTPS, Server-zu-Server
ausgehend, ServerIdP Userinfo-EndpunktAccess Token als BearerHTTPS, Server-zu-Server
ausgehend, ServerIdP Discovery-Endpunktkeine personenbezogenen DatenHTTPS
ausgehend, ServerIdP JWKS-Endpunktkeine personenbezogenen Daten (öffentliche Schlüssel, 1 h Cache)HTTPS
ausgehend, BrowserIdP End-Session-Endpunktclient_id, id_token_hint (enthält sub), post_logout_redirect_uriHTTP-Umleitung
eingehendvom IdPD1–D5, D6, D7HTTPS
\n

Weitere Empfänger gibt es nicht. Drittlandübermittlung: Liegt der IdP außerhalb des EWR, ist\nKapitel V DSGVO (Art. 44 ff.) durch den Verantwortlichen zu prüfen; das Plugin selbst nimmt keine\nÜbermittlung an andere Stellen vor.

\n

13. Schnittstellen

\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
EndpunktMethodeAuthentifizierungZweck
/api/v2/oauth2/authGETanonym (@AllowAnonymousAccess)Anmeldung starten; HTTP 404 solange deaktiviert
/api/v2/oauth2/auth/callbackGETanonymRücksprung des IdP
/api/v2/oauth2/configurationGETconfiguration:read:oauth2Konfiguration lesen (ohne Secret)
/api/v2/oauth2/configurationPUTconfiguration:write:oauth2Konfiguration schreiben
\n

Registrierte Erweiterungspunkte des Kerns: Shiro-Realm, GroupResolver, LogoutRedirection,\nIndex-Enricher, ExternalAuthenticationAvailableNotifier, Guice-Modul, sowie ein Servlet-Filter\n(@WebElement(\"/*\")) für die erzwungene Anmeldung.

\n
\n

Weiterführend: Compliance-Bericht ·\nDatenschutz-Folgenabschätzung ·\nSourcecode-Statistik · Benutzerdokumentation

","description":"Prozessbeschreibung — scm-oauth2-plugin Dokumentversion: 1.1 · Stand: 17.08.2026 · Softwarestand: scm-oauth2-plugin 1.0.2 Technische Beschreibung der…","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/PROZESS_BESCHREIBUNG/","version":"1.0.x","latestVersion":"1.0.x","latestPageVersion":"1.0.x","language":"PROZESS_BESCHREIBUNG","canonicalPath":"/plugins/scm-oauth2-plugin/docs/latest/PROZESS_BESCHREIBUNG/","latestRootPath":"/plugins/scm-oauth2-plugin/docs/1.0.x/PROZESS_BESCHREIBUNG/"}}, "staticQueryHashes": ["1973669194","2742214048","2956773653","2957019495","698804963"]}