Contexte
Deayus Bank est une application bancaire fullstack développée pour mettre en pratique la conception d’un système métier sécurisé.
Le projet ne se limite pas à afficher des comptes ou des transactions. Il cherche à reproduire plusieurs contraintes présentes dans des applications professionnelles :
- authentification centralisée ;
- séparation des organisations ;
- gestion des rôles ;
- contrôle précis des permissions ;
- persistance des données métier ;
- sécurisation des endpoints.
Objectif
L’objectif principal est de construire une base bancaire modulaire permettant à plusieurs organisations de gérer leurs utilisateurs, leurs comptes et leurs opérations.
Le projet permet également d’expérimenter :
- Spring Security ;
- les jetons JWT ;
- Keycloak ;
- le multi-tenant ;
- la gestion des permissions ;
- les tests d’autorisation.
Fonctionnalités
Les fonctionnalités actuellement développées comprennent :
- authentification avec Keycloak ;
- création automatique du profil utilisateur local ;
- gestion des organisations ;
- gestion des membres d’une organisation ;
- attribution de rôles ;
- consultation des utilisateurs ;
- contrôle des permissions ;
- préparation des comptes bancaires ;
- préparation des transactions.
Architecture
L’application repose sur une architecture séparant le frontend, le backend, l’identité et les données.
Frontend
Angular fournit l’interface utilisateur et consomme l’API REST du backend.
Backend
Spring Boot gère :
- la logique métier ;
- les contrôles de sécurité ;
- la validation ;
- l’accès aux données ;
- les endpoints REST.
Authentification
Keycloak constitue le fournisseur d’identité.
Il émet les jetons JWT utilisés par Spring Security pour identifier l’utilisateur.
Base de données
PostgreSQL stocke les données métier locales :
- utilisateurs ;
- organisations ;
- appartenances ;
- comptes ;
- transactions.
Infrastructure
Docker permet d’exécuter les différents services dans des environnements isolés.
Stack technique
- Angular pour le frontend ;
- Spring Boot pour l’API ;
- Spring Security pour la sécurisation ;
- Keycloak pour l’authentification ;
- PostgreSQL pour la persistance ;
- Docker pour l’environnement ;
- Maven pour le backend ;
- TypeScript et Java comme langages principaux.
Modèle de données
Le modèle de données repose principalement sur les entités suivantes :
User
Profil métier local associé à l’identité Keycloak.
Organization
Organisation représentant un tenant du système.
Membership
Association entre un utilisateur et une organisation.
BankAccount
Compte bancaire appartenant à une organisation ou à un utilisateur.
Transaction
Mouvement financier entre deux comptes.
L’entité Membership est centrale, car elle permet à un utilisateur de disposer d’un rôle différent selon l’organisation.
Sécurité
La sécurité est construite sur plusieurs niveaux.
Authentification
Keycloak authentifie l’utilisateur et fournit un jeton JWT.
Autorisation
Le backend vérifie :
- que le jeton est valide ;
- que l’utilisateur existe localement ;
- qu’il appartient au tenant demandé ;
- qu’il possède la permission nécessaire.
Isolation des tenants
Les endpoints liés à une organisation reçoivent le tenant actif grâce au header X-Tenant-Id.
Ce header ne suffit pas à autoriser l’accès.
Le backend vérifie systématiquement l’existence d’une appartenance entre l’utilisateur et l’organisation.
Rôles
Les rôles principaux sont :
ADMIN;MANAGER;USER.
Permissions
Les permissions sont plus précises :
USER_READ;MEMBERSHIP_READ;MEMBERSHIP_MANAGE.
Cette séparation permet de faire évoluer les autorisations sans modifier toute la logique métier.
Problèmes rencontrés
Synchronisation entre Keycloak et la base locale
L’utilisateur existe d’abord dans Keycloak, mais l’application a également besoin d’un profil métier local.
Gestion du tenant
Un utilisateur pourrait tenter d’envoyer l’identifiant d’une organisation à laquelle il n’appartient pas.
Gestion des rôles
Un simple rôle global ne suffit pas, car un utilisateur peut être administrateur dans une organisation et simple utilisateur dans une autre.
Configuration de l’authentification
Plusieurs erreurs ont été rencontrées pendant la configuration :
- erreurs
401; - mauvais client Keycloak ;
- identifiants client invalides ;
- comptes utilisateurs incomplets ;
- erreurs de configuration JWT.
Solutions apportées
Création automatique du profil local
Problème
L’utilisateur authentifié dans Keycloak n’existait pas forcément dans PostgreSQL.
Solution
Un endpoint dédié crée automatiquement le profil local à partir des informations présentes dans le JWT.
Validation du tenant
Problème
Le header X-Tenant-Id pouvait contenir l’identifiant d’une organisation arbitraire.
Solution
Chaque service vérifie l’appartenance de l’utilisateur au tenant avant d’autoriser l’opération.
Rôles par organisation
Problème
Les rôles globaux ne permettaient pas de gérer plusieurs niveaux d’accès selon l’organisation.
Solution
Les rôles sont stockés dans Membership et associés au couple utilisateur-organisation.
Séparation des rôles et permissions
Problème
Les contrôles basés uniquement sur ADMIN, MANAGER et USER étaient trop rigides.
Solution
Les rôles regroupent désormais des permissions métier précises vérifiées par le backend.
Valeur apportée
Deayus Bank met en œuvre une architecture bancaire sécurisée reposant sur un modèle multi-tenant, permettant à plusieurs organisations d'utiliser une même application tout en garantissant une isolation stricte de leurs données.
Grâce à une authentification centralisée avec Keycloak, une gestion fine des rôles et des permissions ainsi qu'une architecture modulaire, le projet constitue une base solide pour le développement de services financiers évolutifs et sécurisés.