Maximilian Stubhan
2cce101c4b
Die Anmeldung läuft über das Firmenkonto. Supabase Auth bleibt dabei die
Sitzungsverwaltung — Entra ist der Anbieter, nicht der Ersatz. Genau deshalb
ist der Eingriff klein: auth.uid() liefert weiterhin eine UUID, profiles.id
trägt weiterhin role und is_active, und damit bleiben is_hr_user() und alle
58 RLS-Policies unverändert gültig. Die Sicherheitsgrenze wandert nicht in
den Anwendungscode.
Der Passwort-Pfad ist weg, nicht deaktiviert. Ein zweiter Anmeldeweg neben dem
Firmenkonto hebelt jede Vorgabe des Mandanten aus — Mehrfaktor, bedingten
Zugriff, Sperrung beim Austritt.
Dazu die Rückweg-Route /auth/callback, die den PKCE-Code gegen eine Sitzung
tauscht, und eine Ausnahme im Proxy: ohne sie leitet der Gate den Code nach
/login um, weil es die Sitzung ja erst danach gibt, und die Anmeldung kommt
nie zustande. Ob jemand HR-Zugriff hat, entscheidet weiterhin nicht die Route,
sondern profiles.role/is_active und darunter die Policies.
Zwei Werkzeuge für die Umstellung:
- relink-profile.ts hängt eine bestehende profiles-Zeile auf die
Entra-Identität um. Ein Passwort-Konto und das Entra-Konto derselben
Person sind für Supabase zwei Benutzer mit verschiedenen IDs; ohne das
zeigt die profiles-Zeile nach der ersten SSO-Anmeldung ins Leere und man
sperrt sich aus. Die Fremdschlüssel auf auth.users wandern mit, sonst
stünde in der Historie eine Kennung ohne Konto dahinter.
- entra-claims.ts zeigt, was der Anbieter tatsächlich mitgeschickt hat.
Die geplante Freischaltung über eine Entra-Gruppe hängt daran, wie der
Anspruch heisst und aussieht, und das unterscheidet sich je nach
Tokenkonfiguration des Mandanten. Der Trigger wird erst danach gebaut,
sonst wäre er geraten.
Beim Auswerten der Gruppe später gilt: die Quelle ist auth.identities.
identity_data, nie raw_user_meta_data. Letzteres beschreibt die angemeldete
Person über updateUser() selbst — läse die Freischaltung von dort, könnte sich
jede:r Angemeldete HR-Rechte eintragen. Steht so in docs/entra-sso.md.
Die Anmeldeseite war eine Box im leeren Rosa. Jetzt zweispaltig: links eine
Markenfläche, rechts die Anmeldung; unter 1024px fällt die Fläche weg und die
Wortmarke rückt über die Karte. Die Microsoft-Schaltfläche ist bewusst nicht
mehr in der Hausfarbe — magenta las sich als Aktion *innerhalb* dieser
Anwendung, während sie auf eine fremde Anmeldeseite springt. Weiss mit
grauem Rand ist Microsofts eigene Vorgabe und das Muster, das man
wiedererkennt. Dazu ein Wartezustand für den Sprung und eine Fehlermeldung,
die erklärt, was zu tun ist, statt nur "Kein HR-Zugriff" zu behaupten.
Nachgemessen im laufenden Server statt geschätzt: 656/624 auf 1280px,
Markenfläche in brand-700, Schaltfläche 45px hoch, kein Querlauf auf 375px.
Typecheck, Lint, Build und 182 Tests sind grün.
71 lines
3.0 KiB
TypeScript
71 lines
3.0 KiB
TypeScript
// Zeigt, was Entra ID beim Anmelden tatsächlich mitgeschickt hat.
|
|
//
|
|
// Run with: node --env-file=.env.local supabase/entra-claims.ts <e-mail>
|
|
//
|
|
// Die Freischaltung über eine Entra-Gruppe hängt daran, wie der Anspruch im
|
|
// Token heisst und wie er aussieht — das unterscheidet sich je nachdem, ob im
|
|
// Mandanten „Sicherheitsgruppen" oder „der Anwendung zugewiesene Gruppen"
|
|
// eingestellt ist. Diese Ausgabe ist die Grundlage für den Trigger; ohne sie
|
|
// wäre er geraten.
|
|
|
|
import { createClient } from "@supabase/supabase-js";
|
|
|
|
const SUPABASE_URL = process.env.NEXT_PUBLIC_SUPABASE_URL;
|
|
const SERVICE_ROLE_KEY = process.env.SUPABASE_SERVICE_ROLE_KEY;
|
|
if (!SUPABASE_URL || !SERVICE_ROLE_KEY) {
|
|
throw new Error("Missing NEXT_PUBLIC_SUPABASE_URL or SUPABASE_SERVICE_ROLE_KEY in the environment");
|
|
}
|
|
|
|
const email = process.argv[2];
|
|
if (!email) {
|
|
console.error("Aufruf: node --env-file=.env.local supabase/entra-claims.ts <e-mail>");
|
|
process.exit(1);
|
|
}
|
|
|
|
const supabase = createClient(SUPABASE_URL, SERVICE_ROLE_KEY, {
|
|
auth: { autoRefreshToken: false, persistSession: false },
|
|
});
|
|
|
|
const { data, error } = await supabase.auth.admin.listUsers({ perPage: 1000 });
|
|
if (error) throw new Error(error.message);
|
|
|
|
const matches = data.users.filter((u) => u.email?.toLowerCase() === email.toLowerCase());
|
|
if (matches.length === 0) {
|
|
console.error(`Kein Konto zu ${email}. Vorhanden:`);
|
|
for (const u of data.users) console.error(` ${u.email}`);
|
|
process.exit(1);
|
|
}
|
|
|
|
// Mehrere Treffer sind der Normalfall in der Umstellungsphase: das alte Konto
|
|
// mit Passwort und das neue über Entra sind für Supabase zwei Benutzer.
|
|
for (const user of matches) {
|
|
console.log(`\n── ${user.email} ──`);
|
|
console.log(` id: ${user.id}`);
|
|
console.log(` erstellt: ${user.created_at}`);
|
|
console.log(` Anbieter: ${user.identities?.map((i) => i.provider).join(", ") || "keiner"}`);
|
|
|
|
for (const identity of user.identities ?? []) {
|
|
console.log(`\n identity_data (${identity.provider}) — von GoTrue aus der Antwort des Anbieters:`);
|
|
console.log(
|
|
Object.entries(identity.identity_data ?? {})
|
|
.map(([k, v]) => ` ${k}: ${JSON.stringify(v)}`)
|
|
.join("\n") || " (leer)"
|
|
);
|
|
}
|
|
|
|
// Zum Vergleich, und als Warnung: hierher schreibt auch updateUser(), also
|
|
// die angemeldete Person selbst. Als Grundlage für eine Freischaltung ist
|
|
// das unbrauchbar.
|
|
console.log("\n raw_user_meta_data — auch von der Person selbst beschreibbar, NICHT als Quelle verwenden:");
|
|
console.log(
|
|
Object.entries(user.user_metadata ?? {})
|
|
.map(([k, v]) => ` ${k}: ${JSON.stringify(v)}`)
|
|
.join("\n") || " (leer)"
|
|
);
|
|
}
|
|
|
|
const { data: profiles } = await supabase.from("profiles").select("id, email, role, is_active").eq("email", email);
|
|
console.log(`\n── profiles zu ${email} ──`);
|
|
for (const p of profiles ?? []) console.log(` ${p.id} role=${p.role} is_active=${p.is_active}`);
|
|
if (!profiles?.length) console.log(" (keine Zeile — damit besteht kein Zugriff)");
|