Sécurité & Authentification

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). PgArachne prend en charge quatre méthodes d’authentification. Les méthodes 1 à 3 utilisent SET LOCAL ROLE pour changer d’identité ; la méthode 4 (identifiants directs) se connecte directement en tant que l’utilisateur, sans changement de rôle nécessaire.

1. Connexion interactive (JWT)

Les utilisateurs s’authentifient en utilisant leur vrai nom d’utilisateur et mot de passe PostgreSQL via la méthode JSON-RPC get_jwt. En cas de succès, ils reçoivent un JWT de courte durée. Les requêtes suivantes portent ce jeton dans l’en-tête Authorization: Bearer <token>, et PgArachne bascule le rôle actif vers cet utilisateur pour la durée de chaque 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ême JWT_SECRET que celui configuré dans PgArachne.
• Claims requis : db_role (chaîne non vide) et db_name (chaîne qui doit correspondre au segment de chemin :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
}

Note : les algorithmes JWT asymétriques (par exemple RS256/ES256) ne sont pas pris en charge.

4. Identifiants directs de base de données (Basic Auth)

L’option la plus simple : envoyez le nom d’utilisateur et le mot de passe PostgreSQL avec chaque requête via l’authentification HTTP Basic standard. PgArachne ouvre un pool de connexions dédié authentifié directement en tant que cet utilisateur — SET LOCAL ROLE n’est pas effectué.

Authorization: Basic <base64(username:password)>

Exemple avec curl :

curl -X POST http://localhost:8080/db/my_database/jsonrpc \
  -u demo_user:user_password \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"api.hello_world","params":{},"id":1}'

Différences clés par rapport aux méthodes basées sur les jetons :

• Aucun GRANT demo_user TO pgarachne n’est requis — PgArachne ne change pas de rôle.
• La sécurité au niveau des lignes (Row-Level Security) et les permissions GRANT de PostgreSQL sont appliquées comme d’habitude car la connexion s’exécute sous l’identité de l’utilisateur réel.
• Les pools de connexions sont conservés par utilisateur pour l’efficacité, avec une durée de vie maximale de 5 minutes. Après un changement de mot de passe, les anciennes connexions expirent dans cette fenêtre.
• Pour que les clés d’idempotence fonctionnent avec les identifiants directs, accordez à l’utilisateur EXECUTE ON FUNCTION pgarachne.save_idempotency_key(text).

-- Required for JWT / API-token auth only:
GRANT demo_user TO pgarachne;

Tableau comparatif des méthodes d’authentification

Voir aussi

• Configuration
• Codes d’erreur