Sicherheit & Authentifizierung

PgArachne verlässt sich vollständig auf das PostgreSQL-Berechtigungssystem. Es erfindet keine Access Control Lists (ACLs) neu. Alle Abfragen werden unter der spezifischen Datenbankrolle des authentifizierten Benutzers mit SET LOCAL ROLE ausgeführt.

1. Interaktives Login (JWT)

Benutzer authentifizieren sich über die Login-Funktion mit ihrem echten PostgreSQL-Benutzernamen und -Passwort. Bei Erfolg erhalten sie ein generisches JWT. Wenn dieses Token verwendet wird, wechselt PgArachne die aktive Rolle für die Dauer der Anfrage zu diesem Benutzer.

2. Service-Konten (API-Token)

Für automatisierte Systeme oder Skripte können Sie langlebige API-Token verwenden.

• Token werden in der Tabelle pgarachne.api_tokens gespeichert.
• Jedes Token ist einem bestimmten Datenbankbenutzer/-rolle zugeordnet.
• Senden Sie das Token über den Header Authorization: Bearer <token>.

Das Erstellen von API‑Tokens erfordert pgarachne_admin. Verwende pgarachne.add_api_token(...) mit einer Rolle, die Mitglied von pgarachne_admin ist.

3. Externer Identity Provider (eigenes JWT)

Wenn Benutzer außerhalb von PgArachne authentifiziert werden (z. B. über einen externen Auth-Dienst), kann dieser Dienst JWTs ausstellen und direkt an PgArachne senden.

• Header-Format: Authorization: Bearer <jwt>.
• Signatur: nur HMAC (HS256/HS384/HS512) mit demselben JWT_SECRET, der in PgArachne konfiguriert ist.
• Pflicht-Claims: db_role (String, nicht leer) und db_name (String, muss zu /api/:database passen).
• Empfohlener Claim: exp (Unix-Timestamp) für das Ablaufdatum.

Minimales Payload-Beispiel:

{
  "db_role": "demo_user",
  "db_name": "my_database",
  "exp": 1767225600
}

Wichtig: asymmetrische JWT-Algorithmen (z. B. RS256/ES256) werden von der aktuellen Server-Implementierung nicht akzeptiert.

-- Erlaube 'pgarachne' zu 'demo_user' zu wechseln
GRANT demo_user TO pgarachne;

Siehe auch

• Konfiguration
• Fehlercodes