Renforcement de la politique de sécurité des mots de passe
Nbre de derniers mots de passe historisés
Afin d’interdire leur réutilisation sur la définition d’un nouveau mot de passe.
Sera désormais valorisé à 5, c’est-à-dire que les 5 derniers mots de passe ne pourront être réutilisés.
Durée de validité, en nombre de jours
Durée de vie d’un mot de passe lorsque l’option d’expiration du mot de passe est activée.
Reste valorisée à 90, c’est-à-dire que la saisie d’un nouveau mot de passe est obligatoire tous les 90 jours.
Nombre maximum de tentatives
Nombre de tentatives de connexions avant blocage du compte.
Reste valorisé à 5, c’est-à-dire qu’au bout de 5 tentatives infructueuses de connexion faute de renseigner le bon mot de passe, le compte utilisateur est alors suspendu.
Dans ce cas, une intervention de l’administrateur d’abonnement ou de l’assistance technique sera nécessaire pour débloquer la situation.
Taille minimum du mot de passe
Désormais valorisée à 10, c’est-à-dire que le prochain mot de passe soumis devra avoir une longueur minimum de 10 caractères.
Taille maximale du mot de passe
Reste valorisée à 30, c’est-à-dire que la saisie d’un mot de passe ne peut excéder la longueur de 30 caractères.
Nombre de règles minimal à respecter
Nombre de types de caractères différents pouvant figurer dans la saisie du mot de passe parmi : les caractères numériques, majuscules, minuscules, spéciaux
Désormais valorisé à 4, c’est-à-dire que la prochaine saisie de mot de passe devra contenir au moins 1 caractère de chacune des 4 catégories possibles.
- Les caractères spéciaux comprennent les caractères suivants :
- $£%*µ, ? ;. :/ !§&~#’{([-|_@)]=+}
- D’autres caractères sont disponibles sur le clavier :
- €¨¤ùé »è`\ç^à°
- Ces derniers caractères peuvent figurer dans un mot de passe, mais ne seront pas comptabilisés dans la catégorie des caractères spéciaux
- Il reste donc nécessaire de s’assurer qu’au moins 1 caractère de la 1ère liste proposée soit présent
Ecran de position de trésorerie
Création d’un nouvel écran de position de trésorerie, celui-ci permet de créer des vues consolidées extraites à partir des soldes des comptes émetteurs.
Ce nouvel écran est disponible depuis le menu :
→ Comptes → Position de trésorerie
Pour accéder à cet écran :
- L’abonnement doit disposer du module fonctionnel "Trésorerie relevé"
- L’utilisateur doit être habilité à consulter les soldes (ou habilitation supérieure) sur au moins un compte émetteur
Pour le moment l’utilisateur dispose d’une vue des soldes par comptes sans possibilité de regroupement.
Ecran de position de trésorerie
Propagation en masse des habilitations sur les comptes émetteurs
Un exploitant peut maintenant habiliter un ou plusieurs utilisateurs sur l’ensemble des comptes émetteurs d’un abonnement.
Propagation en masse des habilitations sur les comptes émetteurs
Migration de la base de données en UTF-8
La base de données était encodée en "latin1".
Cependant, ce jeu de caractères n’est pas adapté à une application écrite en Java et aux données manipulées par l’application.
Il nous pose des problèmes d’écritures des données dans la base lorsque les caractères, encodés en UTF-8, ne possèdent pas d’équivalent en latin1.
La migration de la base de données en UTF-8 permet de régler ces problèmes, étant donné qu’il n’y a plus de conversion à faire entre les caractères manipulés par l’application et ceux stockés dans la base.
Il a été choisi d’affecter la "collation" utf8_unicode_520_ci et de la définir comme "collation" par défaut pour le schéma (contre utf8_general_ci défini normalement par défaut mais moins complet).
La migration de la base de données en UTF-8 prend du temps.
A titre d’exemple, il faut compter environ 2 heures pour migrer la base de production de Sycomore.
Il est conseillé d’exécuter ces requêtes de migration directement sur le serveur de la base de données.
Enfin, étant donné que l’encodage de certains caractères est effectué sur 3 caractères (contre 2 en latin1), la taille de la base de données peut sensiblement augmenter.
Toutefois, cela n’a pas été significatif sur la base de production de Sycomore.
La table "schema_version" n’est pas incluse dans le script de migration car cette table est gérée par le flyway.
Pour convertir cette table en cas de besoin, il faut exécuter la commande suivant : ALTER TABLE schema_version CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_520_ci ;
Duplication des droits utilisateurs
Création d’une nouvelle fonctionnalités côté exploitant permettant d’affecter tout ou partie des droits d’un utilisateur à un ou plusieurs utilisateurs.
Cette fonctionnalité est disponible depuis le menu :
→ Utilisateurs → Gestion utilisateurs
→ Actions ’Associer les abonnements’ sur un des utilisateurs du tableau → Sélectionner un ou plusieurs abonnements → Fonction ’Affecter les habilitations’
Deux modes d’affectation des habilitations sont alors proposés :
- Affectation manuelle : C’est celle que l’on connaît déjà qui permet d’affecter en masse des habilitations identiques sur un ensemble de notion
- Affectation par duplication : Copie les habilitations d’un utilisateur source vers les utilisateurs cibles
Il est possible de choisir les notions qui seront concernées :
- Habilitations abonnement
- Habilitations entité
- Habilitations comptes
- Habilitations FQA
- Habilitations FR
- Habilitations FQR
Affectation des habilitations par duplication
Configuration des Agents
La configuration des agents est disponible via le menu Paramétrage → Agent.
Le menu est disponible sous condition que l’utilisateur connecté ait un rôle d’exploitant de la plateforme.
Pour que le rôle d’exploitant puisse être affecté à un utilisateur métier, la propriété post.utilisateurs.habilitations.exploitantActivablePourUtilisateurMetier doit posséder la valeur true.
Attention : Cette propriété est utilisée maintenant par 3 applications : IHM, BackEnd et Gateway.
Ecran d’édition d’une configuration d’installation d’un agent
Cet écran est celui accédé à partir du menu Paramétrage → Agent.
Il permet d’éditer une configuration d’installation d’un agent et de générer le fichier de properties correspondant.
Le fichier de properties est le fichier à fournir à l’agent pour qu’il puisse démarrer et récupérer sa ou ses configurations métier auprès de Sycomore.
Cet écran liste également les configurations métier associées à cette configuration d’installation.
Un bouton permet d’accéder à l’écran d’édition de chacune de ces configurations, écran présenté dans le paragraphe suivant.
Ecran d’édition d’une configuration métier d’un agent
Cet écran permet l’édition d’une configuration métier d’un agent.
Cela consiste à définir la configuration des parties "dépôt", "réceptions" et "conversions" de l’agent dans des onglets dédiés, présentés dans les paragraphes ci-dessous.
Onglet de configuration de la gestion des dépôts
Cet onglet permet de configurer le transfert des dépôts vers des serveurs bancaires.
Les configurations suivantes sont à définir dans cet onglet :
- L’arborescence des fichiers à déposer contient :
- Le répertoire entrée pour les fichiers en attente de prise en charge
- Le répertoire en cours pour les fichiers pris en charge en cours du traitement
- Le répertoire erreur pour les fichiers pris en charge qui sont en erreur
- Le répertoire archive pour les fichiers correctement traités et transférés en banque
- La fréquence à laquelle les répertoires de dépôt des fichiers à uploader sont scannés
- L’impression ou non du bordereau de transfer
- La compression des fichiers avant de les traiter
- Le mode de sélection du FQA à appliquer sur les fichiers. 2 modes disponibles :
- Par une expression régulière
- Inclure le nom du FQA dans le nom du fichier déposé
- La liste des destinataires à notifier en cas d’erreur
- Le sujet et le corps de la notification à envoyer en cas d’erreur
Onglet de configuration des réceptions
Cet onglet permet de configurer les réceptions d’une configuration métier.
Peuvent être définis :
- La fréquence de réception des fichiers à récupérer
- Les répertoires de stockage des fichiers récupérés
- Les flux retour à récupérer via l’agent
- Les lignes de commandes à exécuter suite à une réception en succès ou en erreur
- Les patterns de nommage des fichiers qui sont reçus
WebServices de conversion
De nouveaux WebServices de conversion ont été ajoutés avec la référence de l’abonnement dans leurs URLs.
Les WebServices existants jusqu’alors s’appuyaient sur la référence abonné fournie dans les informations d’authentification.
Cependant, ce mode d’authentification (du style ’refAbo|login’ + mot de passe) est déprécié, à la faveur d’une authentification du style "adresse email + mot de passe".
L’abonnement cible doit alors être identifié dans l’URL du WebService, c’est pourquoi ces nouveaux WebServices de conversion ont été ajoutés :
- Création d’une demande de conversion d’un virement
- URL dépréciée : POST /rest/conv/v1/ficbq/sct ?dateExecution=dateExecution&fqa=refFqa
- Nouvelle URL : POST /rest/conv/v1/abonnements/refAbo/ficbq/sct ?dateExecution=dateExecution&fqa=refFqa
- Création d’une demande de conversion d’un prélèvement
- URL dépréciée : POST /rest/conv/v1/ficbq/sdd ?datePrelevement=datePrelevement&typeFichierSource=typeFichierSource&modeTest=modeTest&fqa=refFqa
- Nouvelle URL : POST /rest/conv/v1/abonnements/refAbo/ficbq/sdd ?datePrelevement=datePrelevement&typeFichierSource=typeFichierSource&modeTest=modeTest&fqa=refFqa
- Récupération du compte rendu d’une conversion
- URL dépréciée : GET /rest/conv/v1/ficbq/idConversion
- Nouvelle URL : GET /rest/conv/v1/abonnements/refAbo/ficbq/idConversion
- Récupération du fichier reliquat d’une conversion
- URL dépréciée : GET /rest/conv/v1/ficbq/idConversion/fichierReliquat
- Nouvelle URL : GET /rest/conv/v1/abonnements/refAbo/ficbq/idConversion/fichierReliquat
- Récupération d’un fichier converti
- URL dépréciée : GET /rest/conv/v1/ficbq/idConversion/fichiersConvertis/idFichier
- Nouvelle URL : GET /rest/conv/v1/abonnements/refAbo/ficbq/idConversion/fichiersConvertis/idFichier
- Relancer une conversion
- URL dépréciée : PUT /rest/conv/v1/ficbq/idConversion/relancer ?modeTest=modeTest
- Nouvelle URL : PUT /rest/conv/v1/abonnements/refAbo/ficbq/idConversion/relancer ?modeTest=modeTest
- Supprimer une conversion
- URL dépréciée : DELETE /rest/conv/v1/ficbq/idConversion
- Nouvelle URL : DELETE /rest/conv/v1/abonnements/refAbo/ficbq/idConversion
Authentification "Basic" sur les WebServices du backend
L’authentification "Basic" sur les WebServices exposés par le backend n’était pas opérationnelle jusqu’à présent, seule l’authentification par token l’était.
Cela a été corrigé et permet notamment à la nouvelle version de l’agent (à partir de la version 2.0.0) de récupérer sa configuration (nouveau WebService exposé par le backend).
Dans la configuration Zuul de la gateway, la règle redirigeant les requêtes vers le backend doit impérativement contenir le paramètre "sensitiveHeaders", comme ceci :
zuul:
routes:
backend:
path: /sycomore/api/**
url: http://localhost:8081/api/
# Surcharge du paramètre sensitiveHeaders afin de conserver les informations d'authentification
sensitiveHeaders:
...Webservice de récupération des utilisateurs techniques
Nouveau web service permettant de récupérer les utilisateurs qui sont des utilisateurs techniques
URL : GET /api/v1/abonnements/refAbo/utilisateurs ?technique=technique
Une remarque sur cet article ?