Esup-Signature

Arborescence des pages

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Sommaire

...

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é

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)

Elle permet à l'administrateur de consulter toutes les demandes. Les demandes peuvent être filtrées en fonction de leur statut

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

Info

Esup-signature permet de créer des circuits de signatures puissants dont les paramètres 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)

...

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'usageTypesSous 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 étapesVérificationÉtape sans modification du document (étape de validation administrative)

...

Niveaux légaux de signature eIDAS

Niveau eIDASCaractéristiquesValeur juridique
Signature électronique simple (SES)- Lien faible avec le signataire- Pas forcément basée sur un certificat- Exemple : signature scannée, case à cocherPreuve 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 nonForce 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 :  

TypeUtilisable pourPrérequisCorrespondance pour le paramètre 
authorized-sign-types
Placage de l’image de signatureSignature simple
imageStamp
Certificat généré automatiquementSignature avancéeServeur XPKI
openPkiCert
Certificat lié à mon profilSignature avancée
userCert
Certificat lié à l’étape du circuitSignature avancée
autoCert
Certificat présent sur mon poste ou sur clé USBSignature avancée, Signature qualifiée (si certificat eIDas)
nexuCert
Certificat autorisé par le gestionnaireSignature avancée
groupCert
Certificat cachet d’établissementSignature 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 : 

Cycle de vie des demandes


...

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)

Elle permet à l'administrateur de consulter toutes les demandes. Les demandes peuvent être filtrées en fonction de leur statut

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 : Gestion des circuits


...

Les formulaires

Voir la page dédiée aux formulaires : Gestion des formulaires

...

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.

Image Removed

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

Image Removed

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)

Image Removed

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.

Image Removed

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
languagejava
themeRDark
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

Pour les cas les plus spécifiques, il est possible d'ajouter, au sources originales, une classe qui décrira précisément un circuit.

Info

L’intérêt de cette solution est de pouvoir mettre en place des mécanismes complexes de calcul des participants. On peut par exemple imaginer de calculer le n+1 de l'utilisateur courant.

Cette nouvelle classe devra implémenter la classe "DefaultWorkflow". Des exemples sont déjà présent dans le code source original d'Esup-signature dans le dossier 

src/main/java/org/esupportail/esupsignature/service/workflow/impl/

Votre classe doit être construite comme suit :

Bloc de code
languagejava
themeRDark
package org.esupportail.esupsignature.service.workflow.impl;

import org.esupportail.esupsignature.entity.Data;
import org.esupportail.esupsignature.entity.User;
import org.esupportail.esupsignature.entity.WorkflowStep;
import org.esupportail.esupsignature.entity.enums.SignType;
import org.esupportail.esupsignature.exception.EsupSignatureUserException;
import org.esupportail.esupsignature.service.workflow.DefaultWorkflow;
import org.springframework.stereotype.Component;

import java.util.ArrayList;
import java.util.List;

@Component
public class BasicWorkflow extends DefaultWorkflow {

   private String name = "BasicWorkflow";
   private String description = "Une signature";
   private List<WorkflowStep> workflowSteps;

   @Override
   public String getName() {
      return name;
   }

   @Override
   public String getDescription() {
      return description;
   }

   @Override
   public List<WorkflowStep> getWorkflowSteps() {
      if(this.workflowSteps == null) {
         try {
            this.workflowSteps = generateWorkflowSteps(userService.getCurrentUser(), null, null);
         } catch (EsupSignatureUserException e) {
            return null;
         }
      }
      return this.workflowSteps;
   }

   public void initWorkflowSteps() {
      this.workflowSteps = new ArrayList<>();
   }

   @Override
   public List<WorkflowStep> generateWorkflowSteps(User user, Data data, List<String> recipentEmailsStep) throws EsupSignatureUserException {
      List<WorkflowStep> workflowSteps = new ArrayList<>();
/* ici on construit la liste des étapes du circuit */
      WorkflowStep workflowStep = new WorkflowStep();
      workflowStep.setStepNumber(1);
      workflowStep.setSignType(SignType.pdfImageStamp);
      workflowStep.setDescription("Choix du signataire");
      workflowStep.setChangeable(true);
      if(data != null) {
         workflowStep.setRecipients(workflowService.getFavoriteRecipientEmail(1, data.getForm(), recipentEmailsStep, user));
      } else {
         workflowStep.getRecipients().add(recipientService.createRecipient(null, userService.getGenericUser("Utilisateur issue des favoris", "")));
      }
      workflowSteps.add(workflowStep);
      return workflowSteps;
   }
}


Il faut donc a minima :

  • Préciser un nom et une description (dans name et description)
  • Implémenter la fonction generateWorkflowSteps()

Les formulaires

Info

L'autre fonction principale d'Esup-signature est la possibilité de mettre rapidement en ligne des formulaires. Cette fonction s'appuie sur les PDF Forms (formulaires présent dans les fichiers PDF). Esup-signature est capable d'analyser les formulaires PDF, d'en effectuer le rendu (via PDF.js) et de stocker les données saisies dans sa base de données.

Remarque

La mise en place du formulaire basé sur un PDF se fait en 3 étapes : création du circuit des signatures, création du PDF puis import dans Esup-signature

Création d'un PDF Form

Pour éditer un fichier PDF et créer un formulaire, il faut se doter d'un outils dédié. L'université de Rouen utilise Adobe Acrobat PRO. Sous linux il existe Master PDF Editor (payant)

L'opération consiste à placer les champs de formulaire puis à les configurer de la bonne façon.

Voici un exemple d'un document PDF en mode édition de formulaire sous Adobe Acrobat PRO.

Image Removed

Les champs doivent être configurés comme suit:

...

Une nomenclature de nommage des champs peut être utilisée pour signifier à Esup-signature d'opéré un traitement spécifique à un champ. On peut, via un nommage correcte, préciser si le champ doit être pré-rempli par Esup-signature et à quelles étapes le champ est modifiable.

Info

Depuis la version 1.2, la nomenclature des champs à changée. Les comportements spécifiques sont à configurés dans l'onglet "Calcul" puis la partie "Script de calcul personnalisé".

De plus, il n'est plus nécessaire de configurer ces comportements directement dans le fichier PDF. Il est maintenant possible de (re)définir la configuration après import du modèle PDF dans esup-signature

La syntaxe à utiliser au niveau des scripts de calcul des champs est la suivante :

...

prefill.ldap(person, sn);

...

search.ldap(person, displayName);

...

Remarque

Concernant les numéros d'étape, l'étape zéro (0) correspond à la saisie du formulaire (première saisie par l'utilisateur). L'étape 1 correspond à la première étape du workflow, ainsi de suite...

Voici un exemple de l'édition d'un formulaire dans esup-signature :

Image Removed

On voit ici les propriétés du champ modifiables via l'interface. Si la syntaxe mise en place dans le modèle PDF Form est correcte, les champs seront pré-configurés. Sinon il est possible de reprendre la configuration sur cet affichage accéssible dans le menu "Admin" → "Formulaire" → "Liste des champs".

Sur cette copie d'écran on voit que le champ "prenom" est configuré comme suit : Obligatoire, pré-rempli du "givenName" de l"utilisateur courant, avec une auto-completion qui retour le givenName (exemple pas vraiment utile en temps normale mais qui illustre la possibilité de cumuler pré-remplissage et auto-completion) et enfin, modifiable à l'étape 0.

Esup-signature est fourni avec les classes DefaulExtValue et LdapExtValue. La classe DefaultExtValue est utilisable en mettant "default" dans le nom du service. Elle propose les données (calculées) suivante :

  • numéro du jour (day)
  • numéro du mois (month)
  • numéro du l'année (year)
  • date du jour (date)
  • heure (time)
  • date et heure (dateTime)
  • nom prénom de l'utilisateur courant (currentUser)
  • un numéro d'ordre (id). Le numéro d'ordre sera incrémenté lors de la dernière étape du circuit configuré pour ce formulaire

Comme c'est le cas pour les classes workflow, vous pouvez créer vos propre classes de données externes en implémentant le type "ExtValue" en reprenant DefaultExtValue.java par exemple.

Classe de pré-remplissage

Pour pré-remplir ou auto-compléter un formulaire, Esup-signature se base une une classe de "pré-remplissage" du type "PreFill". D'origine Esup-signature est fourni avec la classe DefaultPreFill qui prend en charge les données externes de type Default et Ldap. Ceci répond à une grande partie des besoins. Cependant, tout comme cela peut être le cas pour les workflows, il ce peut qu'il soit nécessaire de calculer certaines données à pré-remplir spécifiquement pour un formulaire (donnée calculée en fonction de l'utilisateur courant par exemple). Dans ce cas il y a là encore la possibilité d'implémenter votre propre classe de type PreFill (voir DefaultPreFill.java pour l'exemple)

Import du formulaire

Lorsque le formulaire PDF est terminé, il faut l'importer dans Esup-signature. Pour cela il faut aller sur "Admin" puis "Formulaire" puis cliquer sur le bouton bleu "+" et enfin sur l'icone PDF.

Image Removed

Vous devez saisir un nom (technique) et un titre (beau titre), sélectionner votre modèle PDF Form, saisir un rôle pour definir qui peut acceder à ce formulaire, choisir le type de pré-remplissage, un circuit qui aura été créer au préalable et éventuellement un dossier de destination.

Image Removed

Lorsque vous validez le formulaire, Esup-signature analyse le PDF Form et constitue la structure du formulaire. Sur cet exemple, on voit qu'il a bien pris en compte la nomenclature des champs. Il est possible de modifier les informations saisies lors de la création en cliquant sur le bouton jaune "crayon"

Votre formulaire sera disponible sur la page d'accueil des personnes autorisées à y accéder. Voici un exemple du rendu dans Esup-signature :

Image Removed

L'utilisateur peut corriger et compléter le formulaire puis l'enregistrer. Après un premier enregistrement, il aura la possibilité d'envoyer définitivement ça demande en cliquant sur le bouton bleu "lecture" et en saisissant (si besoin) les noms des destinataires

Image Removed

Les messages d'information

...

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).

Image Added

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 :

Image Added

Remarque

Dans esup-signature, il y a deux façons d'obtenir des rôles: 

  • à l'aide de filtre LDAP si votre environnement le permet voir :

...

...

  • groupe dans vos attributs de session dont le prefix correspond à celui configuré dans

...

  •  group-

...

  • to-role

...

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 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.

FamilleSous-groupeNiveauDescription
XMLNon ETSIXML_NOT_ETSISignature XML non conforme ETSI.

HistoriqueXAdES_BESBasic Electronic Signature (signature simple).


XAdES_EPESBES + politique de signature.


XAdES_TAjout d’un timestamp.


XAdES_LTIntègre infos de validation (certificats, OCSP/CRL).


XAdES_CRéférences aux infos de validation (sans les inclure).


XAdES_XT + validation + timestamps supplémentaires.


XAdES_XLXL = X + toutes les infos nécessaires à la validation future.


XAdES_AArchivage long terme (timestamps périodiques).


XAdES_ERSArchivage via Evidence Record Syntax (RFC 4998).

BaselineXAdES_BASELINE_BProfil ETSI Baseline – signature simple.


XAdES_BASELINE_TBaseline + timestamp.


XAdES_BASELINE_LTBaseline + validation long terme.


XAdES_BASELINE_LTABaseline + archivage long terme.
CMSNon ETSICMS_NOT_ETSISignature CMS non conforme ETSI.

HistoriqueCAdES_BESBasic Electronic Signature (CMS).


CAdES_EPESBES + politique de signature.


CAdES_TAjout d’un timestamp.


CAdES_LTIntègre infos de validation.


CAdES_CRéférences aux infos de validation.


CAdES_XT + validation + timestamps supplémentaires.


CAdES_XLXL = X + toutes les infos de validation incluses.


CAdES_AArchivage long terme (timestamps périodiques).


CAdES_ERSArchivage avec ERS.

BaselineCAdES_BASELINE_BBaseline simple.


CAdES_BASELINE_TBaseline + timestamp.


CAdES_BASELINE_LTBaseline + validation long terme.


CAdES_BASELINE_LTABaseline + archivage long terme.
PDFNon ETSIPDF_NOT_ETSISignature PDF non conforme ETSI.

Historique (PKCS7)PKCS7_BSignature PKCS#7 basique.


PKCS7_TPKCS#7 + timestamp.


PKCS7_LTPKCS#7 + validation long terme.


PKCS7_LTAPKCS#7 + archivage long terme.

Historique (PAdES)PAdES_BESSignature basique (PDF).


PAdES_EPESBES + politique de signature.


PAdES_LTVLong Term Validation (spécifique PDF).

BaselinePAdES_BASELINE_BBaseline simple.


PAdES_BASELINE_TBaseline + timestamp.


PAdES_BASELINE_LTBaseline + validation long terme.


PAdES_BASELINE_LTABaseline + archivage long terme.
JSONNon ETSIJSON_NOT_ETSISignature JSON non conforme ETSI.

BaselineJAdES_BASELINE_BBaseline simple.


JAdES_BASELINE_TBaseline + timestamp.


JAdES_BASELINE_LTBaseline + validation long terme.


JAdES_BASELINE_LTABaseline + archivage long terme.

...