DTL_LicenseServer — Manuel de référence

Préface

DTL_LicenseServer est un service léger de gestion de licences destiné aux applications Windows. Il centralise la création des licences, l’autorisation des machines, la validation en ligne et la révocation, tout en évitant de placer les secrets du serveur ou un accès direct à la base de données dans le logiciel distribué.

Ce manuel constitue la référence descriptive du produit : il expose ses responsabilités, son architecture, ses données, ses interfaces et ses garanties. Il s’adresse aux responsables techniques, développeurs, exploitants et personnes chargées d’évaluer le système.

Contexte et périmètre

Finalité

Le service associe un droit d’utilisation à un produit, une adresse électronique et un nombre maximal de machines. Il décide si une machine peut recevoir ou conserver une activation et produit un jeton signé attestant cette décision.

Frontières de confiance

• L’application cliente connaît l’URL publique et les informations de licence, mais jamais la clé privée de signature ni les identifiants MariaDB.
• L’outil d’administration possède une clé d’API réservée à la création de licences.
• Le serveur PHP porte la logique d’autorisation et signe les jetons.
• MariaDB conserve l’état de référence des produits, licences, activations et événements.

Responsabilités exclues

DTL_LicenseServer n’est ni un système de paiement, ni un portail client, ni un annuaire d’identités. Il ne fournit pas d’interface graphique d’administration et ne remplace pas les contrôles d’accès, la sauvegarde ou la supervision de l’hébergement.

Architecture

Cycle de vie d’une licence

Création

Une licence appartient à un produit et possède un courriel de référence, un état, une échéance facultative et un plafond d’activations. La clé en clair n’est renvoyée qu’à la création ; seule son empreinte SHA-256 est conservée ensuite.

Activation et actualisation

Le serveur vérifie le produit, la clé, le courriel, l’état, l’échéance et le quota. Une première machine obtient une ligne d’activation et un jeton Ed25519. Une demande ultérieure de la même machine non révoquée actualise ses informations sans consommer de place supplémentaire.

Désactivation et réactivation

La désactivation date la révocation de l’activation ; son jeton n’est alors plus valide. Si la même machine présente de nouveau les justificatifs de licence et qu’une place est disponible, le serveur réutilise sa ligne, efface la date de révocation et émet un nouveau jeton. Le quota est contrôlé avant cette réactivation.

États

Modèle de données

Jeton d’activation

Le jeton signé relie une décision à un produit, une licence, une activation et une machine. Sa charge utile comprend la version du format, product_code, license_id, activation_id, machine_id_hash et issued_at. Sa signature protège l’intégrité ; l’état courant reste vérifié côté serveur.

Capacités fonctionnelles

• Création d’une licence pour un produit actif, avec quota et échéance facultative.
• Activation initiale, actualisation d’une machine connue et réactivation contrôlée d’une machine révoquée.
• Validation en ligne de la signature, de la machine, de l’activation et de la licence.
• Désactivation d’une machine et invalidation de son jeton.
• Journalisation des événements significatifs et diagnostic de santé du service.
• Messages français et anglais pour les outils Python fournis.

Le produit d’exemple du schéma porte le code MYPRODUCT et le nom MyProduct. Il illustre le caractère générique du service et n’impose pas le nom du logiciel licencié.

Interface de service

Toutes les réponses utilisent JSON. L’interface distingue l’observation de santé, les opérations portant sur une activation et la création administrative.

Classes de réponse

Les succès ordinaires utilisent les classes HTTP 200 et 201. Les requêtes invalides, authentifications absentes, refus de licence, objets inconnus et conflits de quota relèvent des classes 400. Les erreurs de configuration, signature ou base de données relèvent des classes 500. Les réponses contiennent un indicateur de succès et, en cas de refus, un code d’erreur stable.

Modèle de sécurité

• Transport : HTTPS protège la confidentialité et l’authenticité des échanges.
• Signature : Ed25519 rend détectable toute altération d’un jeton.
• Minimisation : les clés de licence et identifiants matériels bruts ne sont pas conservés par le serveur ; leurs empreintes SHA-256 le sont.
• Administration : la création de licences est séparée et protégée par X-Admin-Key.
• Secrets : server/config.php contient les identifiants MariaDB, la clé d’administration et la clé privée ; il appartient à la frontière de confiance de l’hébergement.
• Traçabilité : les événements enregistrent notamment le type de décision et l’adresse IP reçue par PHP.

Composants internes

Invariants

• Un produit doit exister et être actif avant qu’une licence puisse être délivrée pour son code.
• Une activation non révoquée occupe une place dans le quota ; une activation révoquée n’en occupe pas.
• Le jeton, la machine et la ligne d’activation doivent se désigner mutuellement.
• Une clé de licence en clair n’est pas récupérable depuis la base après sa création.

Limites connues

• Le client fourni enregistre next_check_days et offline_grace_days, mais ne décide pas encore lui-même de l’autorisation hors ligne.
• Les paramètres de fenêtre et de plafond des tentatives d’activation existent dans la configuration, mais ne sont pas appliqués par les scripts actuels.
• L’outil d’administration crée des licences ; il ne fournit pas encore de commandes de liste, suspension, révocation ou réactivation.
• Le client fourni est propre à Windows.
• Le dépôt ne contient pas encore de suite de tests automatisés.

La version du service est 1.0.6. Toute évolution du protocole, du schéma ou de la charge utile des jetons doit préserver la compatibilité ou annoncer explicitement sa rupture.

Glossaire