Utilisation d'une BDD

[alan-mushi]

Pour le stockage des données:

1. Des certificats clients utilisés par le serveur (lecture seule pour le serveur, insertion pour les clients)
2. Des timestamps émis par le serveur (lecture-écriture pour le serveur, lecture seule pour les clients)
3. Des clés (publiques) utilisées pour signer les requêtes de timestamps par le serveur (insertion pour le serveur, lecture seule pour les clients)
4. Des signatures publiées par les clients (insertion pour les clients, pas d'accès pour le serveur)

Les points 1 et 3 correspondent à l'utilisation possible d'un serveur LDAP. Les points 2 et 4 correspondraient plus à des bases de type clé-valeur ou bien NoSQL avec un stockage en colonnes. Bien entendu il est possible d'utiliser un seul type de base SQL (MariaDB/PostgreSQL...) pour tous les usages.

Rappelons nous que dans les "publications KSI" il est explicité que le client puisse publier ses certificats et signatures d'une manière à ce que le serveur n'y ait pas accès en modification. Il est possible de traiter cette contrainte en fixant des politiques d'accès ou en employant des serveurs/BDD différents.

Pour ce point je pense que l'utilisation de systèmes de container est tout à fait justifiée.

[alan-mushi]

J'ai utilisé une seule instance de MongoDB (car elle offre un ensemble de fonctionnalités important et fonctionne sur travis). L'API REST a été modifiée pour refléter la nouvelle façon de stocker les signatures émises par le serveur. Toute la configuration pour le client mongo est réalisée par les variables d'environnement récupérées au début du fichier ksi.dao_mongo.py. Je conseille l'utilisation de docker pour réaliser les tests avec MongoDB.