5 Commits

Include renames

Author	SHA1	Message	Date
patrick	b8b74b5ddc	QA-14: gofmt der geaenderten Testdateien	2026-09-22 01:32:05 +02:00
patrickandClaude Sonnet 5	581f1aff32	QA-14: Core-Tests auf eigene Schemas (testdb) und eindeutige Datenbanknamen umgestellt (Zwischenstand) ... Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-22 00:50:43 +02:00
patrickandClaude Sonnet 5	e8c15ca188	IAM-19: test-infra-fix, DELETE+INSERT als transaktion statt multi-statement-exec ... Zwei kleine Nacharbeiten aus dem Testlauf auf 131: - ConfigStore.Save nutzte einen Multi-Statement-Exec (DELETE; INSERT), den pgx im extended protocol ablehnt ("cannot insert multiple commands into a prepared statement") -- jetzt als Transaktion mit zwei Exec-Aufrufen. - Das Test-Setup fuer die tenants-Tabelle in config_store_test.go war schlanker als das in internal/kek/kek_test.go verwendete Vollschema (fehlende Spalten previous_status/deletion_scheduled_at/ retention_block_reason/retention_checked_at). Da beide Pakete im Gesamttestlauf dieselbe Test-Datenbank per CREATE TABLE IF NOT EXISTS teilen, hat das schlankere Schema (wenn zuerst angelegt) den kek-Test TestTenantKEKHandler_AllowsActiveModuleForTenant zum Fehlschlagen gebracht. Jetzt identisches Vollschema wie kek_test.go. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP	2026-09-17 11:39:43 +02:00
patrickandClaude Sonnet 5	61dac85ff6	IAM-19: verschl-sselte-ablage-von-ldap-ad-bind-credentials ... Speichert das LDAP-Bind-Passwort je Tenant ausschliesslich verschluesselt mit dem Tenant-KEK aus API-10 (AES-256-GCM, kek.EncryptWithTenantKEK/ DecryptWithTenantKEK) statt in einem separaten Secret-Schema oder Klartext (Keycloak-Antipattern bewusst vermieden). Neue Tabelle ldap_bind_config in der Tenant-Datenbank (Migration 0009), neuer internal/ldapsync.ConfigStore fuer Save/Get, rein additiv zu IAM-05 (Syncer/RoleMappingStore unveraendert). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QPsyieCYwvbUBsnN598SbP	2026-09-17 11:32:37 +02:00
sysopsandClaude Sonnet 5	1a82da211d	IAM-05: ldap-active-directory-anbindung ... internal/ldapsync: Client ist eine Schnittstelle (Search() liefert Entry- Liste) — in dieser Umgebung steht kein echter LDAP/AD-Server zur Verfuegung (analog AUD-05/Archive), daher ist die Sync-/Rollenzuordnungs-Logik vollstaendig gegen einen Fake getestet, eine echte Verbindungspruefung gegen LDAP/AD steht noch aus. RoleMappingStore (Akzeptanzkriterium 3): explizite Erlaubnis-Matrix LDAP-Gruppe -> Rolle. HighestRoleFor vergibt NUR fuer explizit gemappte Gruppen eine Rolle — eine unbekannte Gruppe, auch wenn ihr Name zufaellig wie eine interne Rolle aussieht ("tenant_admin", "superadmin"), traegt strukturell nichts bei (kein Code-Pfad, der eine ungemappte Gruppe je einer Rolle zuordnet) — behebt die aus archivmail bekannte Privilege-Escalation- Fehlerklasse von Grund auf statt nachtraeglich zu haerten. Syncer.Run ruft Search() als ALLERERSTES auf; schlaegt es fehl, wird ohne jede Aenderung an bestehenden Konten abgebrochen (Akzeptanzkriterium 2). Pro Eintrag isolierte Fehler landen in SyncResult.Failed, ohne andere Eintraege zu beeintraechtigen. Deaktivierung in LDAP wird als users.Deactivate uebernommen (Akzeptanzkriterium 3). ldap_config speichert bewusst nur den NAMEN einer Umgebungsvariable fuer das Bind-Passwort, nie das Passwort selbst. internal/rbac (RBAC-01) wurde 1:1 aus dem rbac-01-Branch uebernommen (git show aus derselben Repo-Historie) — IAM-05 haengt an RBAC-01 fuer die Rollenzuweisung, beide Boards leben aber auf getrennten, noch nicht gemergten Feature-Branches ohne gemeinsame Historie. Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS): 1. Rollen-Erlaubnis-Matrix mit Positiv- und Negativfaellen automatisiert getestet (keine Privilege-Escalation) — TestRoleMapping_PositiveAndNegativeCases: gemappte Gruppe liefert Rolle, unbekannte Gruppe und rollen-aehnlich benannte, aber nie gemappte Gruppen liefern keine. PASS. 2. Synchronisationslauf mit fehlerhafter/nicht erreichbarer LDAP-Quelle bricht kontrolliert ab, ohne bestehende Konten zu beschaedigen — TestSyncer_AbortsCleanlyOnSourceError: bestehendes Konto bleibt nach fehlgeschlagenem Lauf unveraendert aktiv. PASS. 3. Deaktivierung eines Benutzers in LDAP wird bei naechster Synchronisation korrekt uebernommen — TestSyncer_AppliesDeactivationOnNextRun: erster Lauf legt aktiven Benutzer an, zweiter Lauf mit Disabled=true setzt ihn auf inaktiv. PASS. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-27 22:39:10 +02:00