| Sommaire |
|---|
| Avertissement |
|---|
Version 0.11 (beta) Esup-signature est une application en cours de développement. La documentation est en cours d’élaboration |
...
Introduction
| Info |
|---|
Esup-signature propose une interface d’administration qui permet le suivi des demandes en cours, le paramétrage des circuits de signatures ou des formulaires, ainsi que divers outils qui seront détaillés après. La configuration générale de l'application se fait via le fichier de configuration application.yml avant la compilation du projet voir : Configuration Enfin pour des besoins très précis il est possible d’écrire directement des classes spécifiques pour gérer les sources de données, le pré-remplissage des formulaires ou encore pour décrire des circuits de signatures. |
...
| Remarque |
|---|
Pour avoir accès à l'espace "Admin" l'utilisateur doit disposer du rôle ROLE_ADMIN tel que défini dans la propriété group-mapping-role-admin: du fichier de configuration voir : Configuration securitéde la sécurité |
...
Les type de signature
Il existe plusieurs type de signature disponibles dans esup-signature. Voici un tableau qui résume les différents cas :
| Cas d'usage | Types | Sous type |
|---|---|---|
| Dans tous les cas | Signature | Signature simple (signature calligraphique par apposition d'image) Signature avancée (avec un certificat non eIDas) Signature qualifiée (avec certificat eIDas sur support USB) |
Visa | Visuel avec ou sans certificat cachet d'établissement | |
| Dans le cadre d'un circuit à n étapes | Vérification | Étape sans modification du document (étape de validation administrative) |
...
Niveaux légaux de signature eIDAS
| Niveau eIDAS | Caractéristiques | Valeur juridique |
|---|---|---|
| Signature électronique simple (SES) | - Lien faible avec le signataire- Pas forcément basée sur un certificat- Exemple : signature scannée, case à cocher | Preuve recevable en justice, mais force probante faible (peut être contestée facilement). |
| Signature électronique avancée (AES) | - Uniquement sous le contrôle du signataire- Identifie le signataire de manière unique- Détection de toute modification du document- Basée sur un certificat qualifié ou non | Force probante élevée, généralement acceptée dans les contrats en Europe. |
| Signature électronique qualifiée (QES) | - Répond à toutes les conditions de l’avancée- Basée sur un certificat qualifié délivré par un prestataire de services de confiance (QTSP)- Réalisée avec un dispositif qualifié (ex. carte à puce, token, HSM) | Équivaut légalement à une signature manuscrite dans toute l’UE (irréfutable sauf fraude prouvée). |
...
Les moyens de signature
Pour signer, esup-signature met plusieurs moyens à la disposition des utilisateurs en fonction du niveau de signature exigé. Voici les différentes modes possible :
| Type | Utilisable pour | Prérequis | Correspondance pour le paramètre authorized-sign-types |
|---|---|---|---|
| Placage de l’image de signature | Signature simple | imageStamp | |
| Certificat généré automatiquement | Signature avancée | Serveur XPKI | openPkiCert |
| Certificat lié à mon profil | Signature avancée | userCert | |
| Certificat lié à l’étape du circuit | Signature avancée | autoCert | |
| Certificat présent sur mon poste ou sur clé USB | Signature avancée, Signature qualifiée (si certificat eIDas) | nexuCert | |
| Certificat autorisé par le gestionnaire | Signature avancée | groupCert | |
| Certificat cachet d’établissement | Signature avancée, Signature qualifiée (si certificat eIDas) | sealCert |
...
Cycle de vie d'une demande de signature
Une page dédiée au sujet est disponible ici :
...
Liste des demandes
La vue demande est la première vue accessible lorsque que l'on clique sur "Admin" dans la barre de navigation (ou sur la couronne)
...
Pour autant, l'administrateur ne peut pas consulter les documents, il peut simplement vérifier la liste des événements et si besoin supprimer les demandes.
...
Les circuits
Voir la page dédiée aux circuits
...
Dans Esup-signature permet de créer des circuits de signatures puissants dont les fonctionnalités sont :
- Configuration des étapes avec les noms des participants (récupération dans la base locale et dans l'annuaire) et pour chaque étape, le type de signature.
- Configuration des autorisations sur les circuit (qui peut démarrer un circuit) avec des rôles ou nominativement
- Configuration des entrées/sorties pour une récupération et/ou un dépôts automatique des documents
- Activation ou non de la fonction de scan des documents PDF (dans ce cas la description du circuit se trouve dans les métas-données du PDF)
Dans "Admin" puis "Circuit", vous avez accès à l'outil permet de consulter et de modifier les circuits de signatures. Il est possible de filtrer les circuits décrits via l'interface graphique (Workflows globaux) ou les circuits décrits via une classe (Classes workflow). Il suffit de cliquer sur "l’œil" pour accéder à un circuit.
Configurer un circuit
Pour ajouter un nouveau circuit via l'interface graphique, cliquez sur le bouton bleu "+" puis saisissez un nom (unique). Vous serez redirigé vers la fiche correspondant à votre nouveau circuit. En cliquant sur le bouton bleu "3 points" vous pouvez modifier les paramètres généraux du circuit, ajouter des étapes ou supprimer le circuit.
Dans les paramètres généraux, vous pouvez:
- Modifier la description du circuit (pas défaut on y trouve le nom du circuit)
- Activer le système de permettant de scanner les méta-données des fichiers PDF (dans ce cas le ne sera pas nécessaire de définir les étapes du circuit)
- Définir la visibilité du circuit en choisissant parmi : un visibilité globale, un rôle ou nominativement
- Configurer la source des données si l'on souhaite qu' Esup-signature récupère automatiquement les documents.
Dans ce cas il faut choisir le protocole : smb pour les partages réseaux, cmis pour une GED compatible ou directement sur un dossier local de votre serveur Esup-signature,
puis saisir le chemin sous forme d'uri ex : smb://serveur_de_fichiers/bon_de_commandes/tosign - Idem pour la destination des documents
Pour définir un circuit il faut maintenant utiliser le bouton noir "Ajouter un étape" (les pas). Comme pour une demande signature simple, il faut sélectionner les participants concernés par cette étape, choisir si tous les participants doivent signer lors de cette étape et le définir le type (visa, calligraphique ou électronique)
De plus, il est possible d'ajouter un description de l'étape qui apparaîtra au moment où l'utilisateur validera sa demande. De même il est possible de permettre à l'utilisateur de modifier les participants d'une étape au moment de l'envoi de sa demande en cochant la case "L'utilisateur peut modifier les participants" de l'étape correspondante. Lorsque vous validez, un "bloc" étape est créer au niveau de la fiche du circuit. Dans ce bloc, vous avez la possibilité de modifier les informations précédemment saisies.
| Remarque |
|---|
Attention, il n'est pas possible de modifier l'ordre des étapes, il faudra supprimer puis recréer les étapes si besoin |
Définir un circuit via les métas-données des PDF
Dans certains cas, les participants à une étape donnée ne sont pas prédéfinis. Dans le cas concret des bons de commande à l'université de Rouen, les signataires sont détermines en fonction de l'unité budgétaire (donc par l'application métier).
Le cas d'usage à Rouen est que les utilisateurs génèrent des bon de commande "à signer" au format PDF et les déposent dans leur dossier de travail. Deux cas possible :
- Mettre en place un script qui va calculer le workflow, créer ce workflow dans esup-signature via les web-services puis injecter le document dans Esup-signature
- Mettre en place un script qui calcule le workflow, inscrit ce workflow dans les métas-données du document et le copie dans un dossier défini comme "source" au niveau d'Esup-signature
Pour cette dernière solution il faut donc créer un circuit comme vu précédemment, y cocher la case "Scanner les metadonnées des PDF" et définir une source pour la récupération des documents.
Les métas-données qui doivent être inscrite dans les document PDF sont les suivantes:
- sign_type_default_val : contenant le type de signature (visa, pdfImageStamp, certSign ou nexuSign)
- sign_step#<n> : contenant la liste des participant de l'étape n
- sign_target : contenant le chemin de dépot des documents après signature
Lorsque le scheduler passera pour importer les documents, ceux-ci seront analysés, le circuit sera généré en fonction des informations trouvées dans les métas-données.
Exemple de code java permettant d'ajouter les métas-données à un fichier pdf :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
PDDocument document = PDDocument.load(in);
PDDocumentInformation info = document.getDocumentInformation();
info.setCustomMetadataValue("sign_type_default_val", "pdfImageStamp");
info.setCustomMetadataValue("sign_step#1", "[machin@univ-ville.fr, truc@univ-ville.fr]");
info.setCustomMetadataValue("sign_target_key","smb://serveur_de_fichiers/la_destination/signed");
|
Créer une classe workflow
Les formulaires
Création d'un PDF Form
Import du formulaire
...
Les formulaires
Voir la page dédiée aux formulaires : Gestion des formulaires
...
Les messages d'information
Esup-signature propose un système permettant transmettre des messages d'information à tous les utilisateurs. Pour cela, il faut se rendre sur "Admin", "Messages" puis cliquer sur le bouton bleu "+"
Vous pouvez alors saisir un message ainsi qu'une date de fin de diffusion. Tous les utilisateurs verront ce message et auront la possibilité de le désactiver une fois consulté.
...
Gestion des certificats
Esup-signature propose aux administrateurs la possibilité de partager des certificats "établissement" pour une certaine population (en fonction des rôles des utilisateurs).
L'objectif est de permettre aux utilisateurs de signer électroniquement (avec un certificat donc) sans avoir l'obligation d'avoir un certificat à leur nom dans leur profil esup-signature.
Au moment de la signature, les utilisateurs concernés se verront proposer le certificat correspondant à leur rôle (en plus de leur éventuel certificat personnel).
Pour ajouter un certificat, il faut se rendre dans Admin → Gestion des certificats. Puis lors de l'ajout, choisir le keystore contenant le certificat (PKCS12), choisir les rôles autorisés à l'utiliser et enfin saisir le mot de passe du keystore.
| Remarque |
|---|
| Les utilisateurs non pas de mot de passe à saisir lors de la signature |
...
Gestionnaires des rôles
Depuis la version 1.13, il est possible de déclarer des gestionnaires de rôles. Cela a pour but de permettre à des utilisateurs de créer des circuits et des formulaires à destination des personnes possédants le rôle concerné.
Pour chaque rôle connu dans esup-signature, il est possible d'affecter une ou plusieurs personnes :
| Remarque |
|---|
Dans esup-signature, il y a deux façons d'obtenir des rôles:
Pour accéder à l’application il faut impérativement avoir le rôle : ROLE_USER. Pour la partie administration, il faut ROLE_ADMIN Les rôles obtenus seront copiés dans le profil de l'utilisateur. Un utilisateur peut obtenir des rôles du type : staff, student, test, ordre_de_mission, marches, etc.... ceci grâce à des groupes correspondant au pattern group-to-role-filter-pattern (le texte qui suit le préfixe est converti en rôle ex : ROLE_ORDRE_DE_MISSION) ou à l'aide de mapping-groups-roles Les rôle autres (que user et admin) peuvent être utilisés lorsque vous configurez un formulaire ou un circuit pour y restreindre les accès. Pour une explication détaillée du fonctionnement de la sécurité, voir : Configuration de la sécurité |
...
Switch user
Le switch user permet à l'administrateur de prendre la place d'un autre utilisateur. Cela peut être utile pour reproduire ou constater un problème spécifique à un utilisateur. Toutefois, pour des raisons de confidentialité, cette option n'est pas active par défaut. Pour débloquer cette fonctionnalité sur plateforme de test, il faut modifier le fichier application.yml et mettre la valeur enable-su à true
...
Profils techniques de signature (ETSI)
À titre informatif, voici la liste des profils de signature reconnus pas DSS Signature
Non ETSI / NOT_ETSI : signatures techniques reconnues par DSS mais non conformes aux standards européens ETSI.
Profils "historiques" (BES, EPES, T, C, X, XL, A, ERS, etc.) :
Définis avant les profils "Baseline".
Très détaillés, multiples variantes → interopérabilité plus compliquée.
Toujours valides légalement, mais progressivement supplantés par les profils Baseline.
Profils Baseline (Baseline B / T / LT / LTA) :
Définis par ETSI EN 319 122/132/142/162 (eIDAS).
Objectif : simplifier et normaliser.
4 niveaux clairs et hiérarchiques :
B (Basic) → signature simple.
T (Timestamp) → preuve temporelle.
LT (Long Term) → ajoute certificats + infos de validation.
LTA (Archival) → ajoute archivage long terme.
| Famille | Sous-groupe | Niveau | Description |
|---|---|---|---|
| XML | Non ETSI | XML_NOT_ETSI | Signature XML non conforme ETSI. |
| Historique | XAdES_BES | Basic Electronic Signature (signature simple). | |
| XAdES_EPES | BES + politique de signature. | ||
| XAdES_T | Ajout d’un timestamp. | ||
| XAdES_LT | Intègre infos de validation (certificats, OCSP/CRL). | ||
| XAdES_C | Références aux infos de validation (sans les inclure). | ||
| XAdES_X | T + validation + timestamps supplémentaires. | ||
| XAdES_XL | XL = X + toutes les infos nécessaires à la validation future. | ||
| XAdES_A | Archivage long terme (timestamps périodiques). | ||
| XAdES_ERS | Archivage via Evidence Record Syntax (RFC 4998). | ||
| Baseline | XAdES_BASELINE_B | Profil ETSI Baseline – signature simple. | |
| XAdES_BASELINE_T | Baseline + timestamp. | ||
| XAdES_BASELINE_LT | Baseline + validation long terme. | ||
| XAdES_BASELINE_LTA | Baseline + archivage long terme. | ||
| CMS | Non ETSI | CMS_NOT_ETSI | Signature CMS non conforme ETSI. |
| Historique | CAdES_BES | Basic Electronic Signature (CMS). | |
| CAdES_EPES | BES + politique de signature. | ||
| CAdES_T | Ajout d’un timestamp. | ||
| CAdES_LT | Intègre infos de validation. | ||
| CAdES_C | Références aux infos de validation. | ||
| CAdES_X | T + validation + timestamps supplémentaires. | ||
| CAdES_XL | XL = X + toutes les infos de validation incluses. | ||
| CAdES_A | Archivage long terme (timestamps périodiques). | ||
| CAdES_ERS | Archivage avec ERS. | ||
| Baseline | CAdES_BASELINE_B | Baseline simple. | |
| CAdES_BASELINE_T | Baseline + timestamp. | ||
| CAdES_BASELINE_LT | Baseline + validation long terme. | ||
| CAdES_BASELINE_LTA | Baseline + archivage long terme. | ||
| Non ETSI | PDF_NOT_ETSI | Signature PDF non conforme ETSI. | |
| Historique (PKCS7) | PKCS7_B | Signature PKCS#7 basique. | |
| PKCS7_T | PKCS#7 + timestamp. | ||
| PKCS7_LT | PKCS#7 + validation long terme. | ||
| PKCS7_LTA | PKCS#7 + archivage long terme. | ||
| Historique (PAdES) | PAdES_BES | Signature basique (PDF). | |
| PAdES_EPES | BES + politique de signature. | ||
| PAdES_LTV | Long Term Validation (spécifique PDF). | ||
| Baseline | PAdES_BASELINE_B | Baseline simple. | |
| PAdES_BASELINE_T | Baseline + timestamp. | ||
| PAdES_BASELINE_LT | Baseline + validation long terme. | ||
| PAdES_BASELINE_LTA | Baseline + archivage long terme. | ||
| JSON | Non ETSI | JSON_NOT_ETSI | Signature JSON non conforme ETSI. |
| Baseline | JAdES_BASELINE_B | Baseline simple. | |
| JAdES_BASELINE_T | Baseline + timestamp. | ||
| JAdES_BASELINE_LT | Baseline + validation long terme. | ||
| JAdES_BASELINE_LTA | Baseline + archivage long terme. |
...
...