Démarrage rapide
Sécurité & Authentification
PgArachne s’appuie entièrement sur le système de permission de PostgreSQL. Il ne réinvente pas les listes
de contrôle d’accès (ACL). Toutes les requêtes sont exécutées sous le rôle de base de données spécifique
de l’utilisateur authentifié en utilisant SET LOCAL ROLE.
1. Connexion interactive (JWT)
Les utilisateurs s’authentifient en utilisant leur vrai nom d’utilisateur et mot de passe PostgreSQL via la fonction de connexion. En cas de succès, ils reçoivent un JWT générique. Lorsque ce jeton est utilisé, PgArachne bascule le rôle actif vers cet utilisateur pour la durée de la requête.
2. Comptes de service (Tokens API)
Pour les systèmes automatisés ou les scripts, vous pouvez utiliser des tokens API longue durée.
- Les jetons sont stockés dans la table
pgarachne.api_tokens. - Chaque jeton est mappé à un utilisateur/rôle de base de données spécifique.
- Envoyez le jeton via l’en-tête
Authorization: Bearer <token>.
La création de tokens API nécessite pgarachne_admin. Utilisez pgarachne.add_api_token(...) avec un rôle membre de pgarachne_admin.
3. Fournisseur d’identité externe (JWT personnalisé)
Si vous authentifiez les utilisateurs en dehors de PgArachne (par exemple via un service d’authentification externe), vous pouvez émettre les JWT dans ce service et les envoyer directement à PgArachne.
- Format de l’en-tête :
Authorization: Bearer <jwt>. - Signature : HMAC uniquement (
HS256/HS384/HS512) avec le mêmeJWT_SECRETque celui configuré dans PgArachne. - Claims requis :
db_role(chaîne non vide) etdb_name(chaîne qui doit correspondre à/api/:database). - Claim recommandé :
exp(timestamp Unix) pour l’expiration du token.
Exemple minimal de payload :
{
"db_role": "demo_user",
"db_name": "my_database",
"exp": 1767225600
}Important : les algorithmes JWT asymétriques (par exemple RS256/ES256)
ne sont pas acceptés par l’implémentation actuelle du serveur.
Configuration critique : Privilèges Proxy
Puisque PgArachne se connecte en tant qu’utilisateur défini dans DB_USER (ex :
pgarachne) et bascule l’identité vers d’autres utilisateurs, l’utilisateur proxy
doit être membre de ces rôles cibles.
Exécutez ce SQL pour chaque utilisateur/rôle qui doit se connecter :
-- Autoriser 'pgarachne' à basculer vers 'demo_user'
GRANT demo_user TO pgarachne;