Il faut faire attention à l'indentation lors de la modification du fichier. Une mauvaise indentation peut faire échouer la compilation

De pluis, le fichier doit impérativement être encodé en UTF-8 sinon la compilation peut échouer; Exemple d'erreur : [ERROR] Failed to execute goal org.apache.maven.plugins:maven-resources-plugin:3.2.0:resources (default-resources) on project esup-signature: Input length = 1

global:
    root-url: https://esup-signature.univ-ville.fr					# Adresse d'accès à votre instance
    domain: univ-ville.fr
    nexu-url: https://localhost:9895
    nexu-version: 1.23-SNAPSHOT
    nexu-download-url: /downloads/nexu-bundle.zip	
    hide-wizard: false												# Désactiver le bouton "Assistant de création de demande"
    hide-auto-sign: false											# Désactiver le bouton "Auto signature"
    hide-send-sign-request: false									# Désactiver le bouton "Demander une signature"
	hide-wizard-except-roles:										# Rôles faisant exception à la règle hide-wizard précédente
	hide-auto-sign-except-roles:									# Rôles faisant exception à la règle hide-auto-sign précédente
	hide-send-sign-except-roles:

Détails concernant le système de renommage des fichiers :

Le modèle est construit à l'aide d'attributs entre crochets.

default : [title]

Les attributs disponibles sont :

• [title] : titre du document original
• [id] : identifiant du parapheur
• [worflowName] : nom du circuit
• [user.name] : nom prénom de l'utilisateur courant
• [user.eppn] : eppn de l'utilisateur courant
  [user.initials] : initiales de l'utilisateur courant
• [UUID] : un identifiant unique
• [order] : le numéro d'ordre de création pour un même circuit
• [timestamp] : timestamp sous forme de long
• [date-fr] : date dd/MM/yyyy hh:mm
• [date-en] : date yyyy-MM-dd hh:mm

session:
  jdbc:
      initialize-schema: always
      save-mode: always

    datasource:
        driver-class-name: org.postgresql.Driver
        url: jdbc:postgresql://localhost:5432/esupsignature
        password: esup
        username: esupsignature
		jdbc-url: ${spring.datasource.url}
		hikari:
		    auto-commit: false

Attention au mode create qui, lui, détruit et re-crée la base complète au moment du démarrage de l'application

jpa:
	hibernate:	
	    ddl-auto: update
	properties:
	    hibernate:
	        dialect: org.hibernate.dialect.PostgreSQLDialect
	        format_sql: true
	        jdbc:	
    	        lob:
        	        non_contextual_creation: true
		show-sql: false
		open-in-view: false

    cmis-passwordmail: Administrator
#    cmis-respository-id: default
#    cmis-root-pathhost: /default-domain/workspaces

    security:
        oauth2:
            client:
                registration:
                    franceconnect:
                        provider: franceconnect-idp
                        authorization-grant-type: authorization_code
                        client-id: <client_id>
                        client-secret: <client_secret>
                        client-authentication-method: client_secret_post
                        redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"
                        scope:
                            - openid
                            - family_name
                            - given_name
                            - email
                provider:
                    franceconnect-idp:
                        authorization-uri: https://fcp.integ01.dev-franceconnect.fr/api/v1/authorize
                        token-uri: https://fcp.integ01.dev-franceconnect.fr/api/v1/token
                        user-info-uri: https://fcp.integ01.dev-franceconnect.fr/api/v1/userinfo
                        user-name-attribute: sub
                        user-info-authentication-method: header

ldap:     
    search-base: ou=people																# Base de recherche des utilisateurs, ex : ou=people
    user-object-classes: inetOrgPerson													# Object classes correspondant aux utilisateurs (un "ou" est appliqué aux valeurs de cette liste)
    group-object-classes: groupOfNames													# Object classes correspondant aux groupes (un "ou" est appliqué aux valeurs de cette liste)
    ou-object-classes: organizationalUnit											 	# Object classes correspondant aux OU (un "ou" est appliqué aux valeurs de cette liste)
    alias-object-classes: nisMailAlias													
    users-search-filter: ((&(|(displayName={0}*)(cn={0}*)(uid={0})(mail={0}*))(mail=*)) # Filtre de recherche des utilisateurs
	group-search-base: ou=groups														# Base de recherche des groupes, ex : ou=groups
    group-search-filter: member={0}														# Filtre utilisé pour rechercher les groupes d'un utilisateur, ex : member={0}
    all-groups-search-filter: cn=*{0}													# Filtre utilisé pour rechercher des groupes, ex : cn=*{0}
    all-aliases-search-filter: (mail={0})												# Filtre utilisé pour rechercher des aliases
    user-id-search-filter: (uid={0})													# Le champ dans lequel on trouve le login des utilisateurs, ex : (uid={0})
    user-eppn-search-filter: (eduPersonPrincipalName={0})								# Le champ dans lequel on trouve l'eppn des utilisateurs c'est ce champ qui sera utilisé comme identifiant unique en base, ex : (eduPersonPrincipalName={0})
    user-mail-search-filter: (mail={0})													# Le champ dans lequel on trouve l'email des utilisateurs , ex : (mail={0})
    ou-search-filter: (supannCodeEntite={0})											# Requete pour trouver les OU des utilisateurs (utile seulement pour le pré-remplissage de l'affectation dans les formulaires)
    member-search-filter: (&(uid={0})({1}))												# Filtre pour contrôler l’appartenance d’un utilisateur à un groupe, ex : &(uid={0})({1}))
    members-of-group-search-filter: memberOf=cn={0},ou=groups,dc=univ-ville,dc=fr		# Filtre utilisé pour retrouver les membres d’un groupe, ex : memberOf=cn={0},ou=groups,dc=univ-ville,dc=fr
	eppn-left-part-search-filter: (uid={0})												# Permet de gérer le cas où l'eppn n'est pas construit avec <uid>@<domain>. Il faut donc spécifer le champ dans lequel on trouve la partie gauche de votre eppn
	mapping-filters-groups:																# Liste d'attribution de groupe en fonction d'un filtre LDAP
		student : "(eduPersonAffiliation:=student)"
        staff : "(eduPersonAffiliation:=staff)"

On peut utiliser mapping-filters-groups pour attribuer des groupes à un utilisateur, par exemple : avec mes-users : "eduPersonAffiliation:=member", toutes les personnes issue de ce filtre se verront affectées au groupe "mes-users"

Si dans mapping-groups-roles on a mes-users: ROLE_USER, l'utilisateur obtiendra le rôle ROLE_USER.

Attention vos requetes LDAP doivent impérativement être mises entre parentheses.

De plus les objectClasses des éléments recherchés sont ecrits en dur dans les classes PersonLdap, PersonLightLdap, OrganizationalUnitLdap et AliasLdap. Pour élargir le champ de recherche il faut modifier ces classes directement. Elle sont situées dans le dossier :

src/main/java/org/esupportail/esupsignature/service/ldap/entry

mail:
    from: no-reply.esup-signature@univ-ville.fr

sms:
    enable-sms : false
#    service-name: SMSU
#    url: https://smsu-api.univ-ville.fr/
#    username: sms-account
#    password: ********

Pour que la signature soit valable, le fournisseur du timestamp doit apparaitre dans la liste European Trusted List (EUTL). Sur cette page on trouve une liste de serveurs utilisables : https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710. Il faut faire attention à ne prendre que des fourniseurs Adobe ou EUTL.

Par défaut, DSS Signature propose d'utiliser http://tsa.belgium.be/connect cependant il semble que le serveur impose un nombre maximum de requetes.

Depuis la version 1.28.9 il est possible de saisir plusieurs urls. Dans ce cas le système essai chaque adresse jusqu'a obtenir un timestamp.

Les autres paramètres n'ont pas besoin d'être modifiés

dss:
    cache-data-source-driver-class-name: org.hsqldb.jdbc.JDBCDriver
    cache-data-source-url: jdbc:hsqldb:mem:cachedb
    cache-password:
    cache-username: sa
    default-validation-policy: policy/sign-constraint.xml
    server-signing-keystore-filename: validate_service.p12
    server-signing-keystore-password: password
    server-signing-keystore-type: PKCS12
    tsp-servers: 
        - http://timestamp.sectigo.com/qualified
        - http://tsa.belgium.be/connect
    ks-filename: oj_keystore.p12
    ks-password: dss-password
    ks-type: PKCS12
    lotl-country-code: EU
    lotl-url: https://ec.europa.eu/tools/lotl/eu-lotl.xml
    oj-url: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.276.01.0001.01.ENG
    country: FR
    state-or-province: Région
    postal-code: XXXXX
    locality: Ville
    check-revocation-for-untrusted-chains: true																#Débloque la possibilité de signer avec des certificats non eIDas (ex : Sectigo Rénater)

proxy:
    http-enabled: true
    http-host: localhost
    http-port: 3128
    http-user: 
    http-password: 
    http-excluded-hosts:
    https-enabled: true
    https-host: localhost
    https-port: 3128
    https-user: 
    https-password: 
    https-excluded-hosts:

fs:
    smb-login: esup-signature											# login du compte autorisé à acceder au partage SMB
    smb-password: ********
    smb-uri-test: smb://smb.univ-ville.fr								# chemin vers un partage de test. Pour smb il sera possible d'utiliser des chemins absolus
    vfs-test-uri: /tmp													# chemin vers un repertoire local de test. Pour vfs il sera possible d'utiliser des chemins absolus (FTP compris)
    cmis-uri-test: https://esup-signature.univ-ville.fr/nuxeo			# url du chemin vers le serveur CMIS /!\ ce chemin sert pour autant pour les tests que comme reférence absolue du serveur
    cmis-login: Administrator											# login autorisé à acceder au serveur CMIS
    cmis-password: Administrator
    cmis-respository-id: default
    cmis-root-path: /default-domain/workspaces							# chemin vers le dossier accéssible par esup-signature

Il y a actuellement une confusion concernant la configuration des acces aux stockages externes.

Pour les stockages utilisant de SMB ou VFS, il s'agit de configurer une url de test (pour les test d'intégration). Par la suite, au niveau du paramétrage dans esup-signature, il sera possible de mettre n'importe quel url absolue (pour smb, le compte configuré devra avoir les bons accès)

Pour CMIS, l'attribut cmis-uri-test est mal nommé car il s'agit de l'adresse "fixe" du server CMIS (Nuxeo par ex). Au niveau de l'application il faudra configurer des adresses relatives.

Pour plus d'information voir la page Gestion des circuits#D%C3%A9finirunesourcepourlesdocuments

pdf:
    convert-to-pdf-a: true
    path-to-g-s: /usr/bin/gs
    pdf-a-level: 2
    pdf-to-image-dpi: 72

Pour une explication détaillée du fonctionnement de la sécurité, voir : Configuration de la sécurité

Pour CAS :

url : l'adresse de votre serveur CAS

service : l'url de votre esup-signature + /login/cas

CAS nécessite la configuration d'un LDAP. C'est la solution idéale pour une utilisation interne

Pour Shibboleth :

credentials-request-header : attribut dans lequel on trouve les groupes de l'utilisateur

idp -url : adresse de votre IDP Shibboleth

principal-request-header : attribut dans lequel on trouve l'identifiant de l'utilisateur

security:
    cas:
        service: https://esup-signature.univ-ville.fr/login/cas
        title: Compte Université (CAS)
        url: https://cas.univ-ville.fr
#    shib:
#        credentials-request-header: MEMBER
#        idp-url: https://idp.univ-ville.fr
#        principal-request-header: REMOTE_USER
#        title: Compte d’un autre établissement (Shibboleth)
#		 domains-white-list-url: https://eduspot.renater.fr/eduspot/whitelist-eduspot.txt
	web:
    	group-to-role-filter-pattern: <pattern groupe esup-signature>(\w*)		#ici on configure un pattern permettant de retrouver (discerner) vos groupes dédiés à esup-signature
	    mapping-groups-roles:										
	        <nom du groupe des administrateurs>: ROLE_ADMIN
	        <nom du groupe utilisateur autorisés à accéder à l'application>: ROLE_USER	        
	    ws-access-authorize-ips: 127.0.0.1
#	    group-mapping-spel:
#	        for.esup-signature.user: "true"

group-to-role-filter-pattern: Ce pattern permet de donner automatiquement les rôles correspondants à la partie (\w*) du pattern. Prenons le pattern for.esup-signature.role.(\w*), si l'utilisateur est dans le groupe for.esup-signature.role.bondecommande, il obtiendra automatiquement le role ROLE_BONDECOMMANDE utilisable par la suite pour donner des droits au niveau des formulaires et des circuits.

mapping-groups-roles: Permet de définir des rôles en fonction des groupes de l'utilisateur. Le ROLE_USER est maintenant obligatoire pour accéder à l'application. Si constituer un groupe d'utilisateur est difficile, vous pouvez utiliser mapping-filters-groups dans la conf ldap pour constituer des groupes à l'aide de requêtes ldap.

ws-access-authorize-ips : permet de configurer les adresses autorisées à accéder aux web services d' esup-signature. On peux mettre autant d'adresses que souhaité séparées par des virgules ainsi que des plages du genre 192.168.1.0/24. (Exemple : ws-access-authorize-ips : 127.0.0.1, 192.168.1.0/24, 10.54.20.11, etc. )

group-mapping-spel: Sert à outre passer les groupes obtenus via ldap. Ceci est utiles si vous n'avez pas de configuration LDAP (shibboleth seul par exemple). On utilise alors la syntaxe SePL (Spring Expression Language), avec seulement l'attribut #eppn pris en compte ainsi que la possibilité de mettre la valeur "true".

Ex: pour ajouter à tout le monde le groupe "for.esup-signature.user" on peut mettre for.esup-signature.user: "true". On peut aussi utiliser la syntaxe suivante pour saisir "en dure" des personnes : for.esup-signature.admin: "#eppn == 'toto@univ-ville.fr' or #eppn == 'titi@univ-ville.fr' "

servlet:
    session:
        timeout: 1800								# Durée de session en secondes
        tracking-modes: cookie
    error:
        include-stacktrace: always
    port: 8080
    tomcat:
        mbeanregistry:
            enabled: true
        remoteip:
            remote-ip-header: X-Forwarded-For
        basedir: ./tem

La norme ETSI EN 319 102-1 (cf. [R09] ) définit quatre classes de conformité pour répondre au besoin de protéger la validité de la signature dans le temps. Désormais, pour désigner la classe de la signature, on utilisera le mot « niveau ». Suit la liste des profils implémentant les quatre classes définies dans la norme :

• *AdES_BASELINE_B : Profil implémentant la classe de signature Signature de base
  La version la plus basse et la plus simple contenant au moins une valeur de signature, une référence ou une copie du certificat de signature en tant qu'attribut signé, et éventuellement d'autres attributs signés ou non signés.

• *AdES_BASELINE_T : Profil implémentant la classe de signature Signature avec heure
  Un horodatage concernant l'heure de signature est ajouté pour se protéger contre la répudiation.

• *AdES_BASELINE_LT : Profil implémentant la classe de signature Signature avec matériel de validation à long terme
  Tous les éléments ou références aux éléments nécessaires à la validation de la signature sont intégrés pour permettre une vérification future même si leur source d'origine n'est pas disponible. Par exemple, ce niveau doit prouver que le chemin de certification était valide, au moment de la validation de la signature, jusqu'à un point de confiance selon les contraintes de nommage et les contraintes de la politique de certification de la « Signature Validation Policy ».

• *AdES_BASELINE_LTA : Profil implémentant la classe de signature Signature assurant la disponibilité et l'intégrité à long terme du matériel de validation
  En utilisant un horodatage périodique (par exemple chaque année), la disponibilité ou l'intégrité des données de validation est maintenue. La validité pourrait être limitée en raison de l'obsolescence cryptographique des algorithmes, des clés et des paramètres utilisés, ou en raison de l'expiration ou de la révocation du matériel de validation. L' AdES-BASELINE-LTAaugmentation ajoute des horodatages supplémentaires pour archiver les signatures de manière à ce qu'elles soient toujours protégées, mais également pour pouvoir prouver que les signatures étaient valides au moment où les algorithmes cryptographiques utilisés étaient considérés comme sûrs. Des données de validation supplémentaires peuvent également être incluses.

logging:
    file:
        name: logs/esup-signature.log
    level:
        <nom du groupe des administrateurs>root: ROLE_ADMINinfo
	        <nom du groupe utilisateur autorisés à accéder à l'application>: ROLE_USER	   org.esupportail.esupsignature: info
     
	    ws-access-authorize-ips: 127.0.0.1
#	org.verapdf: error
     group-mapping-spel:
#	   org.apache.pdfbox: error
    for.esup-signature.user: "true"

springdoc:
    api-docs:
        enabled: true
    swagger-ui:
        enabled: true
        supported-submit-methods: []
    packages-to-scan: org.esupportail.esupsignature.web.ws

Lorsque votre configuration sera terminée, vous devez creer un commit git, ceci afin d'éviter tout problème lors d'une prochaine mise à jour. Les commandes git à lancer:

git add .
git commit -m "ma conf de prod"

    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>logs/esup-signature.log</file>
        <append>true</append>
        <immediateFlush>true</immediateFlush>
        <encoder>
            <pattern>[%-5level] %date{dd/MM/yyyy HH:mm:ss} %logger{35} - %msg%n</pattern>
        </encoder>
    </appender>

application.title = Esup Signature
application.footer=Université de Rouen Normandie