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.
31 lines
1.4 KiB
TypeScript
31 lines
1.4 KiB
TypeScript
import { NextResponse, type NextRequest } from "next/server";
|
|
import { createClient } from "@/lib/supabase/server";
|
|
|
|
// Rückweg aus Entra ID. @supabase/ssr benutzt PKCE, das heisst der Anbieter
|
|
// liefert einen einmaligen Code, der hier gegen eine Sitzung getauscht wird.
|
|
// Ohne diese Route landet die Anmeldung in einer Schleife: der Code steht in
|
|
// der URL, aber es entsteht nie ein Sitzungscookie, und der Proxy schickt
|
|
// zurück auf /login.
|
|
export async function GET(request: NextRequest) {
|
|
const { searchParams, origin } = request.nextUrl;
|
|
|
|
// Entra meldet abgelehnte Zustimmung oder gesperrte Konten als Fehler
|
|
// zurück. Der Text daraus wird nicht angezeigt — er ist fremdbestimmt und
|
|
// stünde sonst auf der echten, korrekt gebrandeten Anmeldeseite.
|
|
if (searchParams.get("error")) {
|
|
return NextResponse.redirect(`${origin}/login?error=sso_failed`);
|
|
}
|
|
|
|
const code = searchParams.get("code");
|
|
if (!code) return NextResponse.redirect(`${origin}/login?error=sso_failed`);
|
|
|
|
const supabase = await createClient();
|
|
const { error } = await supabase.auth.exchangeCodeForSession(code);
|
|
if (error) return NextResponse.redirect(`${origin}/login?error=sso_failed`);
|
|
|
|
// Ob die Person HR-Zugriff hat, entscheidet nicht diese Route, sondern
|
|
// proxy.ts anhand von profiles.role/is_active — und darunter, unabhängig
|
|
// davon, die RLS-Policies. Hier wird nur die Sitzung hergestellt.
|
|
return NextResponse.redirect(`${origin}/`);
|
|
}
|