NotariumDocumentation
Version de la documentation: latest
FR

Authentification

L'authentification de Notarium est intégrée et repose entièrement sur la base de métadonnées — aucun IdP externe, aucun JWT, aucun SMTP. Le mode se choisit avec la variable AUTH_MODE et détermine s'il y a une connexion ou non.

Le mode password (par défaut)

Sécurisé par défaut : authentification multi-utilisateur complète.

  • Premier démarrage. Sur une instance vierge, le premier visiteur crée le propriétaire via l'écran de configuration initiale (host-admin et propriétaire des espaces configurés). Aucun mot de passe n'est préréglé ; une fois ce compte enregistré, la configuration se ferme définitivement.
  • Sessions. Une connexion crée une session côté serveur — une ligne dans la base, pas un JWT. Elle réside dans le cookie HttpOnly nt_session, avec un TTL glissant de 30 jours et le drapeau Secure derrière HTTPS. La révocation est instantanée : désactiver un utilisateur ou changer un mot de passe supprime aussitôt les sessions actives.
  • Une base de métadonnées est nécessaire. Elle est présente par défaut — SQLite sous DATA_DIR, rien à configurer. On ne touche à META_DB_URL que pour migrer vers un Postgres externe. Voir Base de données.

Le mode none

Un unique principal disposant de tous les accès — l'opérateur active ce mode de façon délibérée, pour le poste de travail, le développement local ou un intranet de confiance. Les routes d'authentification renvoient 404, il n'existe aucune interface de connexion, et aucune base de métadonnées n'est requise pour l'authentification.

N'exposez pas une instance none sur le réseau

En mode none, quiconque peut atteindre le port obtient un accès complet à toutes les données — y compris le point d'accès MCP des agents. Ne l'utilisez que sur un réseau isolé ou de confiance.

Rôles et accès

L'accès aux données est accordé par l'appartenance à un espace, et il existe trois rôles :

RôlePermissions
readerLit tout dans l'espace.
writerModifie les notes.
ownerGère l'appartenance.

Le drapeau host-admin confère le contrôle des utilisateurs et des espaces, mais pour lire les données d'un espace précis, l'appartenance à celui-ci reste nécessaire. Plus de détails sur le modèle — Modèle d'accès.

Invitations et réinitialisations de mot de passe

Notarium n'embarque aucun SMTP — la remise initiale d'un compte passe par un lien à usage unique que l'administrateur transmet à la main. Un seul mécanisme, deux usages :

  • Invitation — ajoute un utilisateur sans mot de passe ; le lien reste valide 7 jours.
  • Réinitialisation de mot de passe — le lien reste valide 24 heures ; l'accepter met fin aux anciennes sessions.

Le jeton voyage dans le fragment de l'URL (/invite#<token>), il n'atterrit donc jamais dans les journaux d'accès. Un utilisateur n'a qu'un seul lien de ce type actif à la fois, et l'administrateur ne connaît jamais le mot de passe de quiconque.

Jetons pour les agents

Les agents IA s'authentifient avec un jeton d'accès personnel (PAT) de la forme Authorization: Bearer ntp_…, avec une portée read ou write, éventuellement restreinte à des espaces précis. Le secret n'est affiché qu'une seule fois. L'émission de jetons et les autres actions de gestion ne sont accessibles qu'au sein d'une session — un PAT divulgué ne peut pas élever ses privilèges. Détails — Connecter un agent et Sécurité et visibilité.

Récupérer l'accès

Comme seul l'administrateur émet un lien de réinitialisation, perdre le mot de passe de l'unique administrateur reviendrait à perdre l'accès. La solution est la CLI d'administration, qui agit directement sur la base de métadonnées. C'est l'une des commandes intégrées à l'image, l'appel est donc court et s'exécute directement dans le conteneur en cours d'exécution :

docker compose exec notarium admin create-admin <user> --random

# pour un simple docker run :
docker exec -it notarium admin create-admin <user> --random

Nul besoin d'arrêter le serveur : SQLite en mode WAL tolère un second processus en écriture, et Postgres plus encore. La CLI retrouve la base de métadonnées toute seule, selon la même logique que le serveur (META_DB_URL, ou la racine dérivée de DATA_DIR) ; face à un mauvais chemin, elle s'arrête sur une erreur au lieu de créer en silence une base vide où « il n'y a aucun utilisateur ».

Commandes disponibles :

CommandeAction
listListe les utilisateurs.
passwd <user> [--password <pw> | --random]Change un mot de passe.
create-admin <user> [--random] [--display "Name"]Crée un administrateur.
grant <user> <space> <owner|writer|reader>Octroie un rôle dans un espace.

Sans option, le mot de passe est lu depuis stdin avec l'écho supprimé, il n'atterrit donc jamais dans l'historique des commandes. setPassword/createAdmin ne sont disponibles que depuis la CLI — il n'existe aucun chemin HTTP pour ces opérations : c'est la frontière opérateur de l'hôte. Les autres commandes de l'image sont décrites sur la page CLI de l'image.