Licences SaaS & on-premise¶

À quoi ça sert¶

Ce module gère le cycle de vie complet des installations on-premise de Jigi : déclaration d'une instance chez un client, émission d'un fichier de licence signé (.lic) à partir de l'empreinte machine du client, puis suivi et gestion (suspension, révocation, renouvellement) de cette licence dans le temps.

Prérequis¶

Prérequis

Modules sous licence : PLATFORM (espace opérateur Jigi)
Permissions : platform.tenants.read, platform.tenants.manage, platform.license.manage, platform.subscription.admin
Rôles : JIGI_OPERATOR, JIGI_ADMIN

Comment ça marche¶

Comprendre le principe général¶

Un client en on-premise héberge Jigi sur sa propre infrastructure, sans connexion permanente au SaaS Jigi. Pour que son installation fonctionne, elle doit posséder un fichier .lic signé cryptographiquement par la plateforme SaaS Jigi, qui autorise l'usage des modules souscrits pour une durée donnée et le lie à son matériel (empreinte machine). Le flux se déroule toujours en trois temps :

Le client exporte l'empreinte de sa machine depuis son installation on-premise (opération manuelle, sans connexion sortante automatique).
Il transmet cette empreinte à l'équipe Jigi (email, ticket support…).
Un opérateur Jigi déclare l'instance puis émet la licence dans admin-jigi, et transmet le fichier .lic généré au client, qui l'importe dans son installation.

Déclarer une nouvelle instance on-premise¶

Ouvrir Instances de licence (/admin-jigi/license-instances).
Cliquer sur Déclarer une nouvelle instance pour ouvrir le formulaire de déclaration. Champs à renseigner : nom de la société, nom et email du contact, téléphone, pays (liste actuellement limitée à Côte d'Ivoire, Sénégal, Mali, Burkina Faso, Niger, Guinée), numéro RCCM ou SIRET, et le contenu de l'empreinte machine transmise par le client (zone de texte).
Valider crée l'instance avec un code d'instance généré automatiquement (préfixe JIGI-ONPREM- suivi de 6 caractères aléatoires) et un statut initial PENDING (en attente de licence).
L'instance apparaît désormais dans la liste, filtrable par recherche libre ou par statut.

Émettre une licence pour une instance¶

Depuis la liste, ouvrir la fiche d'une instance (/admin-jigi/license-instances/{instanceId}).
Cliquer sur Émettre une licence pour lancer l'assistant en 2 étapes :
Étape 1 — durée de validité (expiresAt) et durée de la période de grâce en jours (gracePeriodDays), c'est-à-dire le délai supplémentaire pendant lequel l'installation continue de fonctionner après expiration avant blocage effectif.
Étape 2 — activation module par module parmi RH congés, entretiens/évaluations, recrutement, réservations, comptabilité, fournitures, prestataires, RH générale : pour chaque module, activer/désactiver, définir un quota si applicable, et des options spécifiques.
Valider l'assistant déclenche la signature cryptographique du fichier de licence côté serveur (voir Détails techniques) et le rend disponible en téléchargement direct depuis la fiche de l'instance ; un email contenant le fichier .lic en pièce jointe est également envoyé automatiquement.
L'instance passe alors au statut ACTIVE, avec sa date d'activation et sa date d'expiration renseignées. Émettre une nouvelle licence sur une instance qui en avait déjà une remplace l'ancienne (l'ancienne clé passe au statut RENEWED) et conserve la traçabilité du renouvellement.

Suspendre, réactiver ou révoquer une instance¶

Depuis la fiche de l'instance :

Suspendre (avec motif optionnel) — bloque temporairement l'usage, par exemple en cas de litige commercial ou d'impayé ; réversible.
Réactiver — ne fonctionne que sur une instance actuellement suspendue, la remet en statut ACTIVE.
Révoquer (avec motif optionnel) — action définitive : la clé de licence active passe au statut REVOKED et l'instance elle-même passe en statut REVOKED. Une instance déjà révoquée ne peut plus être suspendue ni réactivée.

Réception de la licence côté client (référence uniquement)¶

Le module app.jigi.license (activé uniquement en profil Spring onprem, donc absent du déploiement SaaS) gère côté client :

l'export de l'empreinte machine et la génération d'une demande de licence, sans appel réseau sortant automatique — l'export est un fichier que l'administrateur du client transmet manuellement, ce qui convient aux environnements isolés/air-gapés ;
l'activation : import du fichier .lic reçu, vérification de la signature et du matériel, puis application de la licence à l'installation locale.

Rotation de la clé de signature (SaaS, hors admin-jigi)¶

La paire de clés EC (courbe secp256r1) qui signe tous les fichiers .lic est gérée au niveau infrastructure, pas depuis l'interface admin-jigi. En local, elle se manipule via ./install-local-local.sh --rotate-signing-key, qui régénère la paire et resynchronise la clé publique vers le trust store on-premise — toute licence signée avec l'ancienne clé cesse alors d'être valide.

Qui peut faire quoi¶

Permission requise	Rôles concernés
`platform.tenants.read`	`JIGI_OPERATOR`, `JIGI_ADMIN`
`platform.tenants.manage`	`JIGI_OPERATOR`, `JIGI_ADMIN`
`platform.license.manage`	`JIGI_OPERATOR`, `JIGI_ADMIN`
`platform.subscription.admin`	`JIGI_OPERATOR`, `JIGI_ADMIN`

Action	JIGI_OPERATOR	JIGI_ADMIN
Lister/consulter une instance (`platform.tenants.read`)	✅	✅
Déclarer une nouvelle instance (`platform.tenants.manage`)	✅	✅
Créer/modifier/supprimer une instance, émettre une licence (`platform.license.manage`)	✅	✅
Suspendre/réactiver/révoquer une instance (`platform.tenants.manage`)	✅	✅
(côté on-prem uniquement, profil Spring `onprem`) Exporter l'empreinte, importer/activer un `.lic` (`platform.subscription.admin` / `platform.license.manage`)	—	—

platform.license.manage a été ajoutée et attribuée aux deux rôles par V223__rh281_license_instance_permissions.sql — pas de nuance connue entre JIGI_OPERATOR et JIGI_ADMIN sur ce module côté SaaS.

Détails techniques¶

Détails techniques

Côté SaaS (émission) — package app.jigi.subscription :
- Entité LicenseInstance (table subscription.license_instances) : identité du client, empreinte machine (machineId, macAddresses, dockerDaemonId, cpuModel, cpuCores, totalMemoryMb, hostname, motherboardSerial, fingerprintData), statut (LicenseInstanceStatus : PENDING, ACTIVE, GRACE_PERIOD, EXPIRED, SUSPENDED, REVOKED, TRANSFERRED), gracePeriodDays (défaut 14), maxOfflineDays (défaut 90, calculé à l'émission comme gracePeriodDays * 6).
- Entité LicenseKey (table subscription.license_keys) : licValue (le contenu signé du .lic), payloadJson, issuedAt/expiresAt, statut (LicenseKeyStatus : ACTIVE, RENEWED, REVOKED, EXPIRED), renewedFromKeyId (chaînage des renouvellements), issuedByOperatorId.
- Service LicenseIssuanceService : construit le LicensePayload (code d'instance, modules/quotas via ModuleGrant, dates), le signe via LicenseSigningService/LicenseKeyPairService (paire EC secp256r1), bascule l'ancienne clé ACTIVE en RENEWED, persiste la nouvelle clé, peut générer une facture (CustomerInvoice, rattachée à un tenant de facturation interne dédié JIGI_BILLING_TENANT_ID), et envoie l'email avec le .lic en pièce jointe base64.
- Contrôleur LicenseInstanceController (base /admin-jigi/license-instances) : GET/POST racine, GET/PUT/DELETE /{id}, POST /declare, POST /{id}/licenses (émission), POST /{id}/suspend, /reactivate, /revoke.
Côté on-premise (réception) — package app.jigi.license, contrôleurs actifs uniquement sous @Profile("onprem") :
- FingerprintController (/license/fingerprint, /license/request-export) — génère et exporte l'empreinte matérielle locale (MachineFingerprintService), requiert platform.subscription.admin.
- LicenseActivateController (POST /license/activate multipart, GET /license/status) — importe et vérifie un .lic reçu, requiert respectivement platform.license.manage et platform.tenants.read.
- LicenseKeyPairService — gère la paire de clés EC (secp256r1) utilisée pour signer/vérifier les .lic, avec chargement depuis fichier (jigi.license.private-key-path/public-key-path) ou génération éphémère si absent.
Relation SaaS ↔ on-prem : la paire de clés EC est générée côté SaaS ; sa clé publique est synchronisée vers le trust store de chaque instance on-prem, ce qui permet à l'installation cliente de vérifier hors-ligne l'authenticité de tout .lic qu'elle reçoit — voir la section « Local SaaS / On-Prem Test Instances » du CLAUDE.md racine pour l'environnement de test local reproduisant cette relation.

Cas d'erreur et FAQ¶

Un client veut passer en on-premise, quelle est la première étape ? Lui demander d'exporter l'empreinte de sa machine (opération manuelle depuis son installation, ou fournie par son intégrateur si l'installation n'existe pas encore), puis déclarer une nouvelle instance dans /admin-jigi/license-instances avec cette empreinte.

Le fichier .lic a-t-il une date d'expiration stricte, ou une tolérance ? Il y a une période de grâce (gracePeriodDays, 14 jours par défaut) après l'expiration, ainsi qu'une tolérance de fonctionnement hors-ligne prolongée (maxOfflineDays, calculée automatiquement comme 6 fois la période de grâce).

Comment renouveler la licence d'un client existant avant son expiration ? Retournez sur la fiche de son instance et relancez l'assistant d'émission de licence : la nouvelle licence remplace l'ancienne (qui passe en statut RENEWED) et conserve le lien de chaînage entre les deux.

Un client ne paie plus, comment couper son accès sans supprimer ses données de configuration ? Utilisez Suspendre plutôt que Révoquer — la suspension est réversible via Réactiver, contrairement à la révocation qui est définitive.

Que se passe-t-il si la clé de signature Jigi est compromise ? Une rotation de clé (--rotate-signing-key en environnement local) génère une nouvelle paire et resynchronise la clé publique vers les instances on-prem ; toutes les licences déjà signées avec l'ancienne clé deviennent invalides et doivent être réémises.