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

    datasource:
        maxdriver-requestclass-sizename: 1280KBorg.postgresql.Driver
        resolve-lazilyurl: true
thymeleaf:
 jdbc:postgresql://localhost:5432/esupsignature
   cache: false
    encodingpassword: UTF-8esup
    mode: HTML
   username: servlet:
        produce-partial-output-while-processing: false
web:
esupsignature
		jdbc-url: ${spring.datasource.url}
		hikari:
		    resourcesauto-commit:
        cache:
            cachecontrol:
                max-age: 1d
                cache-public: true
        static-locations: classpath:/static
mvc:
    static-path-pattern: /**

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
	

    security:
        oauth2format_sql: true
	            clientjdbc:	
    	        lob:
    registration:
    	        non_contextual_creation: true
		show-sql: false
		open-in-view: false

     franceconnectldap:
        base: dc=univ-ville,dc=fr
        password: ********
       provider urls: franceconnect-idpldap://ldap.univ-ville.fr
        username: cn=consult,dc=univ-ville,dc=fr

               authorization-grant-type: authorization_codemail:
        host: smtp.univ-ville.fr

servlet:                client-id: <client_id>
    multipart:
        enabled: true
           client-secret: <client_secret>max-file-size: 1280KB
        max-request-size: 1280KB
        resolve-lazily: true
thymeleaf:
      client-authentication-methodcache: client_secret_postfalse
    encoding: UTF-8
    mode: HTML
    servlet:
          redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}"produce-partial-output-while-processing: false
web:
    resources:
        cache:
            scopecachecontrol:
                            - openidmax-age: 1d
                cache-public: true
           static- family_namelocations: classpath:/static
mvc:
    static-path-pattern: /**

Attention, depuis la version 1.24, les noms de fournisseur franceconnect et proconnect sont reservés pour l'authentification des externes... De plus la configuration a changée ; une page dédiée est disponible ici : Signature des extérieurs (ProConnect, FranceConnect, SMS...)

    security:                        - given_name
                            - email
        oauth2:
            providerclient:
                provider:
    franceconnect-idp:
                        authorization-uri: https://fcp.integ01.dev-franceconnect.fr/api/v1/authorizecas:
                        tokenissuer-uri: https://fcpcas.integ01.devuniv-franceconnect.fr/api/v1/token
ville.fr/oidc

ldap:     
              search-base: ou=people																# Base de recherche des utilisateurs, ex : ou=people
     user-infoobject-uri: https://fcp.integ01.dev-franceconnect.fr/api/v1/userinfo
                        user-name-attribute: sub
                        user-info-authentication-method: header

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

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.

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

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: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
    auto-rotate: true										
	# Corrige automatiquement la rotation des documents en portait <nomqui duont groupeété destournés administrateurs>: ROLE_ADMIN
	de 90°
    gs-command-params:  -dSubsetFonts=true  <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"

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

server:
    servlet:
        session:
            tracking-modestitle: COOKIE
Compte    error:Université (CAS)
        include-stacktraceurl: always
    port: 8080
https://cas.univ-ville.fr
#    tomcatshib:
#        mbeanregistry:
credentials-request-header: MEMBER
#            enabled: true
        remoteip:
            remote-ip-header: X-Forwarded-For
        basedir: ./tem

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.

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