internal/policy/module_scope.go: policy_module_scopes verknuepft optional
eine (role, permission)-Regel mit einem LIC-02-Feature-Flag. Enforcer.
AuthorizeForTenant ist DIESELBE zentrale Entscheidungsfunktion wie Authorize
(Akzeptanzkriterium 3, kein zweiter Enforcement-Mechanismus) — prueft
zusaetzlich zur Grundregel, ob das verknuepfte Modul fuer den Tenant aktiv
ist. Existiert kein ModuleScope-Eintrag, bleibt eine Regel wie bisher ohne
Lizenzbindung gueltig (Kombinationsfall). GuardModuleScoped erweitert
policy.Guard um dieselbe Pruefung.
internal/flag (LIC-02) wurde 1:1 aus dem lic-02-Branch uebernommen (git show
aus derselben Repo-Historie, keine Aenderung) — RBAC-04 haengt sowohl an
RBAC-01/02 als auch an LIC-02, aber diese leben auf getrennten, noch nicht
gemergten Feature-Branches ohne gemeinsame Historie.
Fail-Safe-Verhalten aus LIC-02 greift automatisch: ein nicht konfiguriertes
oder nicht erreichbares Feature-Flag gilt als deaktiviert, nie als aktiviert
(sicherer Default fuer Modul-Aktivierungspruefungen).
Pruefungen (ausgefuehrt auf root@192.168.1.131, go build/vet/test PASS):
1. Zugriff auf deaktiviertes Modul trotz passender Rolle abgewiesen —
TestAuthorizeForTenant_DeniesWhenModuleNotActivated: GuardModuleScoped
ruft die Query-Funktion nachweislich nicht auf. PASS.
2. Reaktivierung macht Berechtigung im laufenden Betrieb wirksam, kein
Neustart — TestAuthorizeForTenant_BecomesActiveWithoutRestart: derselbe
Enforcer/Service-Prozess, Flag per Store.Set aktiviert, TTL abgewartet,
danach erlaubt. PASS.
3. Zusammenspiel Modul-Scope + Rollenscope in Kombinationsfaellen —
TestAuthorizeForTenant_CombinationsOfRoleAndModuleScope: keine Regel ->
verboten; Regel ohne Modul-Scope -> immer erlaubt; Regel mit Modul-Scope
und Flag aus -> verboten; Flag an -> erlaubt. PASS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
