Mémoire de fin d’études :

Conception et Développement du module

Blueprint Pour la gestion de la sécurité dans
l’écosystème Jhipster

Mémoire de fin d’études pour l’obtention du diplôme d’Ingénieur d’Etat de

l’Ecole des Sciences de l’Information

Filière : Ingénierie des systèmes de l’Information et de la transformation

digitale

FARES Hajar

Sous la direction de : Pr. HILAL Imane

Membres de jury :
 Présidente : Pr. HNIDA Meriem
 Encadrante académique : Pr. HILAL Imane
 Tuteur du stage : Mr. ELKHADIRI Nawfal

Promotion : 2022/2025
 Dédicace
À mes parents

À vous, mes chers parents, qui avez été les premiers bâtisseurs de ma vie. Votre amour
sans condition, vos sacrifices silencieux et votre confiance infinie m’ont soutenu et guidé
jusqu’à présent. C’est dans vos regards que j’ai trouvé la force de continuer, et c’est à
travers vos prières que j’ai découvert le chemin de la réussite. Je vous dois tout ce que je
suis devenu aujourd’hui.

À ma sœur

À toi, ma sœur, ma complice depuis toujours. Ton sourire, ton écoute et ta douceur m’ont
accompagné dans les moments de doute comme dans les instants de bonheur. Ta présence
a été pour moi une lumière réconfortante qui a su dissiper bien des inquiétudes. Merci
d’avoir été là, simplement, avec sincérité.

À Mami, ma deuxième mère

À Mami, cette femme au cœur immense, que le destin a mise sur mon chemin comme un
cadeau. Ton amour maternel, ton attention constante et ta sagesse ont été pour moi une
source de paix et de courage. Tu es bien plus qu’une deuxième mère, tu es un refuge, un
repère, une étoile bienveillante dans mon ciel.

À mon oncle et à sa petite famille

À mon oncle et à sa famille, si précieuse à mon cœur. Votre affection discrète, vos paroles
réconfortantes et vos encouragements m’ont donné l’envie de toujours aller de l’avant.
Vous avez su être une source de chaleur et de force dans les moments où j’en avais le plus
besoin. Merci pour votre présence inestimable.
 Remerciements
Je tiens à exprimer toute ma gratitude à celles et ceux qui, de près ou de loin, ont
contribué à la réalisation de ce travail.

Je remercie tout d’abord Madame Hilal Imane, mon encadrante académique, pour
sa disponibilité, ses conseils éclairés et son accompagnement bienveillant tout au long de
ce projet. Sa rigueur et ses remarques constructives ont été précieuses pour faire avancer
mon travail dans la bonne direction.

Je tiens également à exprimer ma profonde reconnaissance à Monsieur Nawfal Elkha-

diri, qui m’a encadré avec professionnalisme et bienveillance durant toute mon expérience
au sein de Lear. Ses conseils, son exigence et sa confiance m’ont permis de progresser à
chaque étape du projet.

Mes remerciements s’adressent également à Madame Hanane Oulhaj, pour son ac-
cueil chaleureux, son suivi attentif et ses conseils précieux qui ont enrichi mon stage et
facilité mon intégration dans l’équipe.

Un grand merci à toute l’équipe de travail au sein de Lear, pour l’atmosphère pro-
fessionnelle et amicale qui a accompagné mon apprentissage. Une mention spéciale à
Bourahouat Ghizlane, pour son aide précieuse, sa disponibilité et ses encouragements
constants.

Je remercie également les membres du jury, pour le temps qu’ils consacreront à l’éva-
luation de ce travail et pour l’intérêt porté à mon projet.

Je remercie toute l’équipe pédagogique de l’École des sciences de l’informa-

tion(ESI) pour l’enseignement de qualité et l’encadrement dont j’ai bénéficié durant mon
parcours universitaire.

Enfin, je n’oublie pas toutes les personnes — proches, amis ou collègues — qui, par
leur soutien, leurs encouragements ont contribué de près ou de loin à la réussite de ce
projet.
 Résumé
Ce Projet de Fin d’études s’inscrit dans une démarche d’automatisation avancée de la
sécurité des applications d’entreprise. Il a abouti à la conception et au développement du
module blueprint à intégrer dans l’écosystème JHipster afin d’ajouter automatiquement
une couche de sécurité complète fondée sur le modèle RBAC (Role-Based Access Control).
Ce blueprint va bien au-delà d’une simple génération de code : il implémente un
mécanisme structuré de gestion des rôles, des permissions et de la hiérarchie des accès,
compatible à la fois avec les architectures monolithiques et microservices. Il s’intègre
directement dans le processus de génération de projet avec JHipster, en injectant des
composants backend (Spring Boot), frontend (Angular), ainsi que des configurations de
sécurité avancées.
Grâce à cette solution, Lear Corporation bénéficie d’un gain de temps significatif dans
le développement des applications basées sur Jhispter, en garantissant une sécurité renfor-
cée dès la phase initiale, une réduction importante de la complexité liée à la configuration
manuelle des droits d’accès. Ce module blueprint représente ainsi une brique technique
réutilisable, évolutive et adaptée aux exigences en matière de sécurité des accès

Mots-clés : JHipster, Blueprint, RBAC, Sécurité Applicative, Spring Boot, Angular,

Microservices, Gestion des Permissions et leurs hiérarchies
 Abstract
This capstone project is part of an advanced automation approach to enterprise ap-
plication security. It led to the design and development of a blueprint module to be
integrated into the JHipster framework in order to automatically add a complete security
layer based on the Role-Based Access Control (RBAC) model.
This blueprint goes far beyond simple code generation : it implements a structured
mechanism for managing roles, permissions, and access hierarchies, compatible with both
monolithic and microservices architectures. It integrates directly into the project gene-
ration process with JHipster, injecting backend (Spring Boot), frontend (Angular), and
advanced security configuration components.
Thanks to this solution, Lear Corporation benefits from significant time savings in the
development of JHipster-based applications, ensuring enhanced security from the initial
phase and significantly reducing the complexity of manually configuring access rights. This
blueprint module thus represents a reusable, scalable, and security-compliant technical
asset adapted to modern access control requirements.

Keywords : JHipster, Blueprint, RBAC, Application Security, Spring Boot, Angular,

Microservices, Permission Management and Hierarchy
 ‫ڲڪٌۘ‬

‫ﺓ‬ ‫ﻭ‬ ‫ﻭ‬ ‫ﺃ‬ ‫ﺕ‪ .‬ﻭ‬ ‫ﺕﺍ‬ ‫ﺃ ﻥ‬ ‫ﺭ‬ ‫ﻭﻉ‬ ‫ﺍﺍ‬ ‫ﺭﺝ‬
‫ﺫﺝ‬ ‫ﺁ‬ ‫ﺃ ﻥ‬ ‫ﻑﺇ‬ ‫‪JHipster،‬‬ ‫ﺇ ﺭﺍ‬ ‫ﺩ ﺝ‬ ‫‪Blueprint‬‬
‫ﺍ ﺩﻭﺍﺭ ‪(RBAC).‬‬ ‫ﻝﺍ‬ ‫ﺍ‬ ‫ﺍ‬
‫ﺕ‬ ‫ﺩﺍﺭﺓ ﺍ ﺩﻭﺍﺭ ﻭﺍ‬ ‫ﺁ‬ ‫ﻡ‬ ‫‪،‬‬ ‫ﺓﺍ‬ ‫ﺍ‬ ‫ﺓ‬ ‫ﻩﺍ‬
‫ﺓ‬ ‫ﺓ ‪ (Microservices).‬ﻭ‬ ‫ﺕﺍ‬ ‫ﻭﺍ‬ ‫ﺭ ﺍ‬ ‫ﺍ‬ ‫ﺕ‪ ،‬ﻭ‬ ‫ﺍ‬ ‫ﻭ‬
‫ﺕ ‪ Boot) (Spring Backend‬ﻭ‪(Angular) Frontend‬‬ ‫ﻝ ﺇﺩ ﻝ‬ ‫ﺍ ﻭﻉ ‪JHipster‬‬
‫‪.‬‬ ‫ﺇ ﺇ ﺍﺩﺍﺕ ﺃ ﻥ‬
‫ﺓ‬ ‫ﺕﺍ‬ ‫ﺍ‬ ‫ﺍ‬ ‫‪Corporation Lear‬‬ ‫ﺍﺍ ‪،‬‬
‫ﺍﺩ‬ ‫ﺍ‬ ‫ﺍ‬ ‫ﻭﻉ‪ ،‬ﻭ‬ ‫ﺍ ﻭ‬ ‫ﺍ ﺍ‬ ‫ﻯﺃ ﻥ‬ ‫ﻥ‬ ‫‪JHipster،‬‬
‫ﻝﺃ ﻥ‬ ‫ﺍ‬ ‫‪،‬ﻭ‬ ‫ﺍﻡ‪،‬‬ ‫ﺩﺓ ﺍ‬ ‫ﺓ‬ ‫ﻩﺍ‬ ‫ﺕ ﻭ ً‪ .‬ﻭ ُ‬ ‫ﺍ‬
‫ﻝ‪.‬‬ ‫ﺍ‬

‫ﺕ‪Spring ،‬‬ ‫ﺍ ﻭﺭ ‪ (RBAC)،‬ﺃ ﻥ ﺍ‬ ‫ﻝ‬ ‫ﺍ‬ ‫‪ Blueprint، JHipster، :‬ﺍ‬ ‫ﺕﺍ‬ ‫ﺍ‬
‫ﺕﻭ‬ ‫ّ ﺓ ‪ (Microservices)،‬ﺇﺩﺍﺭﺓ ﺍ‬ ‫ﺕﺍ‬ ‫‪ Angular، Boot،‬ﺍ‬
Table des matières

Table des matières iii

Liste des figures iv

Table des abréviations v

Liste des tableaux vi

Liste des listings vii

Introduction générale 1

1 Contexte générale du projet 3

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Lear Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Domaines d’activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Seating (systèmes de sièges) . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 E-Systems (systèmes électriques et électroniques) . . . . . . . . . . 4
1.3 Les clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Lear Corporation – Technopolis Rabat . . . . . . . . . . . . . . . . . . . . 4
1.4.1 Fiche signalétique de Lear Rabat . . . . . . . . . . . . . . . . . . . 4
1.4.2 Organisation de Lear Rabat . . . . . . . . . . . . . . . . . . . . . 5
1.5 Contexte général du projet . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Objectifs du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.8 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Revue de littérature 9
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 La sécurité applicative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 La gestion de la confidentialité des applications . . . . . . . . . . . . . . . 10
2.2.1 RBAC (Role-Based Access Control) : Contrôle d’accès basé sur les
rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

i
 2.2.2 ABAC (Attribute-Based Access Control) : Contrôle d’accès basé
sur les attributs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3 PBAC (Policy-Based Access Control) : Contrôle d’accès basé sur
les politiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4 CPAC (Context-Based Access Control) : Contrôle d’accès basé sur
le contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Benchmark des modèles de sécurité des applications . . . . . . . . . . . . . 12
2.4 Justification du choix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Écosystème technologique de JHipster . . . . . . . . . . . . . . . . . . . . 13
2.5.1 JHipster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2 Les architectures jhipster . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.3 JHipster et Consul . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.4 JHipster et Keycloak . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.5 JHipster et Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.6 Spring Boot : le socle backend . . . . . . . . . . . . . . . . . . . . . 16
2.5.7 Angular : framework frontend moderne . . . . . . . . . . . . . . . . 16
2.6 Blueprnt Jhipster : Personnalisation avancée . . . . . . . . . . . . . . . . 16
2.6.1 Qu’est-ce qu’un Blueprint dans JHipster ? . . . . . . . . . . . . . . 16
2.6.2 Objectifs des Blueprints JHipster . . . . . . . . . . . . . . . . . . . 16
2.6.3 Exemples de Blueprints Officiels . . . . . . . . . . . . . . . . . . . . 17
2.6.4 Cycle de vie d’un Blueprint JHipster . . . . . . . . . . . . . . . . . 17
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Analyse de besoins et conception 19

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1 Exigences fonctionnelles du projet . . . . . . . . . . . . . . . . . . . . . . 19
3.2 critique de l’architecture initiale de JHipster . . . . . . . . . . . . . . . . . 19
3.3 Diagramme Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Diagrammes de séquence du Blueprint . . . . . . . . . . . . . . . . . . . . 21
3.4.1 Diagramme de séquence pour sécuriser les endpoints REST . . . . 21
3.4.2 Diagrammes de séquences pour sécuriser les routes et personnaliser
les interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.3 Diagramme de séquence pour la gestion des rôles et des permissions 28
3.5 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Réalisation du blueprint coté backend 31

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 Intégration du Blueprint dans les architectures JHipster . . . . . . . . . . . 31
4.2 Les actions du blueprint sur le backend des applications JHipster . . . . . 34
4.3 Automatisation de la gestionde la confidentialité apportée par coté backend 37

ii
 4.3.1Objectif1 : Sécuriser les endpoints backend . . . . . . . . . . 37
4.3.2Objectif2 : Communication des permissions entre le Gateway et les
microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.3 Objectif 3 : Communication entre microservices . . . . . . . . . . . 47
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5 Réalisation du blueprint coté frontend et Maintenance 49

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Les actions du blueprint sur le frontend des applications JHipster . . . . . 49
5.2 Automatisation de la gestion de la confidentialité apportée coté frontend . 52
5.2.1 Objectif1 : Personnaliser les interfaces utilisateur selon les permissions 52
5.2.2 objectif 2 : Génération d’interface pour gestion des authorités . . 59
5.2.3 Objectif3 : Génération d’interface pour gestion des permissions . . 61
5.3 Maintenance évolutive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3.1 Dépendance au gateway : seulement pour l’architecture microservice 62
5.3.2 confusion entre Authority et Permission pour les deux architectures 63
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Intégration du blueprint dans un exemple d’application générée par

JHipster 69
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1 Contexte des tests et applications utilisées . . . . . . . . . . . . . . . . . . 69
6.2 Constats sans le blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.1 Architecture Microservices . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.2 Architecture Monolithique : . . . . . . . . . . . . . . . . . . . . . . 71
6.3 Constats après le Blueprint . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.1 Architecture Microservice . . . . . . . . . . . . . . . . . . . . . . . 72
6.3.2 Architecture Monolithique . . . . . . . . . . . . . . . . . . . . . . . 73
6.3.3 Autre Interfaces génrées ou modifiées par le blueprint . . . . . . . . 75
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Conclusion 77

Perspectives et travaux futurs 78

iii
Table des figures

1.1 Clients de Lear Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1 La triade CID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Architecture monolitique standard . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Architecture microservice standard . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Cycle de vie du Blueprint Jhipster . . . . . . . . . . . . . . . . . . . . . . 17

3.1 diagramme use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Diagramme de séquence pour sécuriser les endpoints REST . . . . . . . . . 22
3.3 Flux de sécurisation des routes (architecture microservice)(1) . . . . . . . . 24
3.4 Flux de sécurisation des routes (architecture microservice)(2) . . . . . . . . 25
3.5 Flux de sécurisation des routes (architecture monolithique) . . . . . . . . . 26
3.6 Diagramme de séquence pour la gestion des roles et des permissions . . . . 28
3.7 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1 Intégration du Blueprint dans l’architecture microservice . . . . . . . . . . 32

4.2 Intégration du Blueprint dans l’architecture monolithique . . . . . . . . . . 33
4.3 carte mentale: action du blueprint sur le backend des applications . . . . . 34

5.1 carte mentale: action du blueprint sur frontend des applications JHipster . 50

6.1 Interface vue par un utilisateur simple . . . . . . . . . . . . . . . . . . . . 70

6.2 Interface vue par les administrateurs . . . . . . . . . . . . . . . . . . . . . 71
6.3 Interface utilisateur simple avant le blueprint . . . . . . . . . . . . . . . . . 71
6.4 Interface administrateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 Aperçu des permissions de l’utilisateur . . . . . . . . . . . . . . . . . . . . 72
6.6 Interface personnalisée selon les permissions de l’utilisateur . . . . . . . . . 73
6.7 accès bloqué à une route sécurisé . . . . . . . . . . . . . . . . . . . . . . . 73
6.8 liste des Permissions de l’utilisateur . . . . . . . . . . . . . . . . . . . . . . 74
6.9 Interface personnalisée selon les permissions et leurs hiérarchie . . . . . . . 74
6.10 Accès bloqué à une route sécurisé dans une application monolithique . . . 75
6.11 liste des autorités du (gateway ou monolihique) . . . . . . . . . . . . . . . 75
6.12 Aperçu des microservices accessible . . . . . . . . . . . . . . . . . . . . . . 75
6.13 Interface de gestion des rôles pour les microservice . . . . . . . . . . . . . . 76
6.14 Interface permission-management propre aux microservices . . . . . . . . . 76

iv
Table des abréviations

Abréviation Signification
ABAC Attribute-Based Access Control
API Application Programming Interface
CABC Context-Aware Access Control
Consul Système de service discovery et configuration
CRUD Create, Read, Update, Delete
DB Base de données (Database)
DTO Data Transfer Object
Feign Client HTTP déclaratif pour la communication inter-
services
HTTP HyperText Transfer Protocol
JHipster Générateur d’applications Web basé sur Java et An-
gular
JSON JavaScript Object Notation
JWT JSON Web Token
Keycloak Serveur d’authentification et d’autorisation Open
Source
Microservice Architecture logicielle basée sur des services auto-
nomes
OAuth2 Open Authorization 2.0
PBAC Policy-Based Access Control
RBAC Role-Based Access Control
REST Representational State Transfer
UI User Interface

v
Liste des tableaux

1.1 Fiche signalétique de Lear Corporation Automotive Electronics Morocco . 5

2.1 Benchmark des modèles de contrôle d’accès . . . . . . . . . . . . . . . . . 12

vi
Listings

4.1 Classe [Link] . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2 Exemple End-point avant l’application du blueprint . . . . . . . . . . . . . 39
4.3 Exemple End-point après l’application du blueprint . . . . . . . . . . . . . 40
4.4 Intégration des permissions coté gateway . . . . . . . . . . . . . . . . . . . 41
4.5 Intégration des permissions coté microservice . . . . . . . . . . . . . . . . . 42
4.6 Détection et agrégation des adresses des microservices enregistrés dans
Consul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.7 Méthode responsable de récupérer des permissions . . . . . . . . . . . . . . 46
5.1 Exemple [Link] . . . . . . . . . . . . . . . . . . . . 53
5.2 les Modifications effectuées sur le fichier [Link] . . . . . . . . . 54
5.3 Modification appliquée par le blueprint sur [Link] du gateway . . 56
5.4 Exemple d’un élément d’action avant l’application du blueprint . . . . . . 57
5.5 Exemple des éléments d’action après l’application du blueprint . . . . . . . 58
5.6 Exemple de déclaration de route avant enrichissement par le blueprint . . . 58
5.7 Exemple de déclaration de route après l’application du blueprint . . . . . . 59
5.8 Annotation PreAuthorize avec HasAnyAuthority . . . . . . . . . . . . . . 63
5.9 Utilisation de la Directive hasAnyAuthority . . . . . . . . . . . . . . . . . 64
5.10 Classe CustomPermissionEvaluator générée par le Blueprint . . . . . . . . 65
5.11 Nouvelle annotation @PreAuthorize . . . . . . . . . . . . . . . . . . . . . . 66
5.12 Exemple Méthode getUserFromAuthentication aprés séparaion des permis-
sios et authorités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

vii
Introduction générale

Dans un monde de plus en plus interconnecté, la transformation numérique bouleverse

en profondeur les modes de fonctionnement des entreprises. Cette évolution, bien que
porteuse d’innovation, s’accompagne également de risques majeurs en matière de sécurité
informatique. La protection des données sensibles et la maîtrise des accès aux ressources
numériques sont devenues des priorités stratégiques, en particulier dans un contexte où
les cyberattaques se multiplient et où les exigences réglementaires imposent des standards
élevés de confidentialité.

La gestion des accès utilisateurs représente l’un des enjeux majeurs en cybersécuri-
té. Il ne s’agit plus seulement d’authentifier un utilisateur, mais également de contrôler
précisément ce à quoi il peut accéder, selon ses responsabilités, son rôle et son contexte
d’usage. Une mauvaise configuration des droits d’accès peut exposer une organisation à
des violations graves de données, à des fuites d’informations critiques ou à des sabotages
internes. La sécurisation fine des accès constitue donc un impératif, tant pour protéger
les actifs numériques que pour garantir la conformité et la continuité d’activité.

Assurer cette sécurité granulaire représente cependant un défi technique important,

notamment dans les architectures modernes à base de microservices. Chaque microser-
vice doit non seulement être sécurisé indépendamment, mais aussi pouvoir interagir avec
d’autres composants dans un cadre de confiance partagé. Même dans une architecture
monolithique, la mise en place d’un contrôle d’accès fin, hiérarchisé et évolutif implique
des efforts de configuration souvent fastidieux et sources d’erreurs. La complexité croît
encore lorsqu’il faut adapter dynamiquement les autorisations selon les métiers, les cas
d’usage et les évolutions de l’organisation.

Face à ces enjeux, ce projet s’est orienté vers la mise en place d’une solution tech-
nique adaptée. L’objectif est de concevoir et développer un outil automatisé capable de
renforcer la gestion des rôles, des permissions et de la hiérarchie des accès dans les ap-
plications d’[Link] y répondre, nous avons mis en place un blueprint JHipster
capable d’ajouter automatiquement cette couche de sécurité dans les applications .Ce
composant repose sur le modèle RBAC (Role-Based Access Control), Permettant une ré-
partition cohérente et organisée des autorisations d’accès. Ce mémoire présente l’ensemble
du processus suivi, depuis l’analyse des besoins jusqu’aux résultats obtenus, en passant
par les choix techniques opérés et les perspectives d’amélioration.

La structure du mémoire est la suivante :

1
• Chapitre 1 : Contexte générale du projet.

• Chapitre 2 : Revue de littérature.

• Chapitre 3 : Analyse de besoins et conception.

• Chapitre 4 : Réalisation du blueprint coté backend.

• Chapitre 5 : Réalisation du blueprint coté frontend et maintenance.

• Chapitre 6 : Intégrtion du blueprint dans un exemple d’application générée par

JHipster.

2
Chapitre 1

Contexte générale du projet

Introduction
Le premier chapitre de ce mémoire est consacré à l’analyse du contexte dans lequel
le projet a vu le jour. Il s’agit de présenter l’organisme d’accueil, d’identifier les besoins
métiers, les enjeux de sécurité et les contraintes techniques qui ont motivé la mise en place
de la solution proposée. Cette contextualisation permet de mieux cerner la problématique
à laquelle le projet répond.

1.1 Lear Corporation

Lear Corporation est une entreprise industrielle américaine de renom, leader dans
le secteur des technologies automobiles. Fondée en 1917 sous le nom d’American Metal
Products, elle est devenue, au fil des années, un fournisseur indispensable pour les grands
constructeurs automobiles à l’échelle mondiale. Son siège social se trouve à Southfield,
dans le Michigan, et la société est cotée à la Bourse de New York sous le code LEA.
Aujourd’hui, Lear Corporation emploie environ 173 000 personnes, réparties sur plus de
260 sites à travers 38 pays, illustrant son expansion mondiale et sa capacité d’innovation
constante [1].

1.2 Domaines d’activité

Lear Corporation organise ses activités autour de deux divisions majeures, chacune
spécialisée dans un domaine essentiel à la performance globale de l’entreprise.

1.2.1 Seating (systèmes de sièges)

Au sein de Lear Corporation, la division E-Systems occupe une place essentielle dans
l’essor des technologies de sièges intelligents. Elle est responsable non seulement de la
conception et de la production des sièges automobiles, mais aussi de l’ensemble des com-
posants techniques qui les composent, tels que les structures internes, les mécanismes
de réglage, les matériaux de rembourrage, les revêtements et les dispositifs de confort.
L’entreprise se distingue par sa stratégie d’innovation, notamment grâce à la plateforme
intelligente INTU™, conçue pour améliorer l’expérience utilisateur en matière d’ergono-
mie, de bien-être et de connectivité embarquée. [2].

3
1.2.2 E-Systems (systèmes électriques et électroniques)
Ce secteur regroupe l’ensemble des solutions technologiques embarquées, couvrant
l’électronique de puissance, les modules de gestion de l’énergie, ainsi que les architec-
tures électriques, les faisceaux de câblage, les calculateurs et les logiciels intégrés. Lear
se distingue particulièrement dans les domaines de l’électrification des véhicules, de la
connectivité et de la cybersécurité automobile[3].

1.3 Les clients

Lear Corporation travaille en étroite collaboration avec les principaux constructeurs
automobiles mondiaux, forgeant des partenariats stratégiques avec de nombreux acteurs
majeurs du secteur tels que General Motors, Ford, Stellantis, BMW, Tesla, Volkswagen,
Renault-Nissan, et d’autres, comme illustré dans la Figure 1.1. Cette diversification client
confère à Lear une stabilité stratégique et une capacité d’adaptation face aux évolutions
du marché. [4].

Fig. 1.1 : Clients de Lear Corporation

1.4 Lear Corporation – Technopolis Rabat

1.4.1 Fiche signalétique de Lear Rabat

Lear Corporation opère au Maroc via plusieurs filiales industrielles et techniques. L’une
d’elles, située à Technopolis Rabatshore, opère sous le nom Lear Corporation Automotive
Electronics Morocco. Créée en 2011, cette entité est une SARL au capital de 22,47 millions
de dirhams. Elle se spécialise dans la production de cartes et de composants électroniques
dédiés à l’industrie automobile, dans le cadre de ses activités liées au segment E-Systems.
Le site de Rabat bénéficie d’une situation géographique stratégique, au cœur du parc
technologique Technopolis, qui accueille plusieurs entreprises internationales du secteur
des TIC et de l’électronique, comme détaillé dans la fiche signalétique présentée au Tableau
1.1. [5].

4
 Élément Détail
Nom de la société Lear Corporation Automotive Electronics Morocco
Statut juridique Société par actions simplifiée (SAS)
Surface du site 14 340 m²
Date de création Avril 2010, inauguration officielle en mai 2011
Secteur d’activités Assemblage de cartes électroniques pour véhicules
Chiffre d’affaires De 100 000 000 à 500 000 000 DH
Effectif Entre 500 et 1000 (estimation en 2017)
Principaux clients BMW, DAIMLER, Renault, Volvo, Jaguar
Capital social 22 470 000 DH (en 2017)
Adresse Technopolis-RabatShore, plot 34-37, 11100 Sala Al Ja-
dida, Maroc

Tab. 1.1 : Fiche signalétique de Lear Corporation Automotive Electronics Morocco

1.4.2 Organisation de Lear Rabat

Le site de Lear Rabat s’inscrit dans une stratégie de montée en valeur du groupe au
Maroc, en intégrant des fonctions avancées d’ingénierie, de RD et de support technique.
Il ne s’agit pas uniquement d’un site de production, mais d’un centre technique où sont
développées des solutions innovantes pour les besoins des clients internationaux.
L’organisation interne est structurée en plusieurs départements : ingénierie électro-
nique, développement logiciel embarqué, assurance qualité, supply chain, ressources hu-
maines, entre autres. Cette structuration, permet une gestion efficace des projets dans un
environnement conforme aux standards internationaux de l’industrie automobile. Parmi
les départements clés, figure le département Cybersecurity and Functional Safety,
créé pour répondre aux nouvelles exigences en matière de sécurité des systèmes embar-
qués. Ce département a pour mission de garantir la cybersécurité et la sûreté fonctionnelle
des produits tout au long de leur cycle de vie, en respectant la norme ISO/SAE 21434,
les exigences des OEM ainsi que les processus internes de Lear Corporation.
C’est au sein de ce département stratégique que ce projet de fin d’études a été réalisé,
visant à développer un blueprint pour la gestion des rôles et des permissions (RBAC).Bien
que n’étant pas directement lié aux composants automobiles, ce projet contribue à ren-
forcer la sécurité des systèmes internes de l’entreprise.

1.5 Contexte général du projet

Dans un contexte où les applications d’entreprise deviennent de plus en plus complexes,
la gestion des accès utilisateurs représente un enjeu central en matière de sécurité et de
gouvernance. Qu’il s’agisse d’architectures monolithiques ou microservices, les besoins en
contrôle d’accès évoluent vers des modèles plus granulaires, capables de refléter fidèlement
les responsabilités réelles des utilisateurs au sein du système.
Afin de répondre à ces enjeux, ce projet de fin d’études s’inscrit dans une initiative
visant à concevoir et développer un module blueprint JHipster permettant d’implémenter

5
un modèle RBAC (Role-Based Access Control). Ce blueprint, pensé pour être générique,
est compatible aussi bien avec les projets monolithiques qu’avec les architectures micro-
services, facilitant l’intégration et la réutilisation dans divers cas d’usage rencontrés chez
Lear Corporation.

1.6 Problématique
Face à des exigences de plus en plus strictes en matière de conformité réglementaire
et de cybersécurité, les entreprises sont confrontées à la nécessité de renforcer le contrôle
des accès aux ressources applicatives. Dans un environnement numérique où le volume
de données sensibles ne cesse de croître, la maîtrise fine des droits d’accès devient un
levier stratégique pour prévenir les risques, assurer la confidentialité des informations, et
se conformer aux standards internationaux de sécurité.
Néanmoins, dans de nombreuses organisations, la gestion des droits d’accès reste fré-
quemment manuelle, fragmentée et dénuée de toute standardisation entre les diverses
applications. Cette absence d’uniformité engendre des incohérences, rend la maintenance
plus complexe et accroît l’exposition aux risques de sécurité.
JHipster facilitent la création d’applications web performantes de manière rapide, mais
son mécanisme de gestion des rôles reste souvent basique, se concentrant principalement
sur quelques rôles fondamentaux tels que ROLE-USER et ROLE-ADMIN. Ainsi, il ne
répond pas suffisamment aux exigences lorsqu’il devient nécessaire de mettre en place un
contrôle d’accès plus précis,flexible et plus adaptable aux spécificités de chaque projet
Ainsi, cela soulève la question suivante :
Comment développer une solution centralisée, adaptable et automatisée
pour la génération de la configuration responsable d’assurer la confiden-
tialité des applications basées sur JHipster, tout en assurant une sécurité
granulaire, cohérente et conforme au modèle RBAC ?

1.7 Objectifs du projet

Ce projet a pour objectif de concevoir et de réaliser un blueprint avancé pour JHipster,
permettant de générer automatiquement une infrastructure complète de gestion des accès
basée sur un modèle RBAC (Role-Based Access Control) enrichi. Les objectifs poursuivis
sont les suivants :

• Analyser les dispositifs de sécurité fournis par JHipster afin d’en évaluer les limites,
en particulier celles liées au manque de précision dans la gestion des accès et à
l’absence de contrôle granulaire des permissions.

• Concevoir un modèle RBAC amélioré, reposant sur l’entité Authority existante dans
JHipster, et enrichi par l’ajout d’entités Permission. Ce modèle permettra de gérer
les permissions de manière dynamique et précise pour chaque rôle.

• Créer un module blueprint adaptable et réutilisable, capable d’ajouter automati-

quement la configuration RBAC dans tout projet JHipster, qu’il soit en mode mo-
nolithique ou microservices.

6
 • Automatiser la génération des composants nécessaires,côté backend et côté frontend.

• Garantir une compatibilité native avec le logiciel Keycloak en se basant sur le pro-
tocole OAuth2, tout en respectant les bonnes pratiques en matière de sécurité ap-
plicative.

• Sécuriser les endpoints REST en fonction des permissions associées à chaque rôle et
utilisateur, en garantissant que chaque endpoint est accessible uniquement par les
utilisateurs possédant les permissions nécessaires.

1.8 Méthodologie de travail

Ce projet de fin d’études a été mené en m’inspirant des principes de l’agilité, ce qui
m’a permis d’organiser mon travail de manière structurée, itérative et orientée vers des
résultats concrets et efficace.

• Découpage du projet en sous-objectifs Le projet a été divisé en plusieurs sous-

objectifs fonctionnels. Ce découpage m’a permis de mieux gérer la complexité glo-
bale du blueprint en me concentrant sur le développement de chaque fonctionnalité
individuellement, jusqu’à sa finalisation complète, avant de passer à la suivante

• Analyse des besoins Avant chaque phase de développement, une analyse des besoins
a été effectuée afin de :

– Clarifier les objectifs fonctionnels attendus pour chaque module,

– Identifier les contraintes techniques ou de sécurité associées,
– Identifier les besoins spécifiques des profils utilisateurs visés, tels que les déve-
loppeurs ou les administrateurs

Cette analyse préalable m’a permis de poser une base claire avant toute implémen-
tation.

• Conception technique Une fois les besoins analysés, une phase de conception tech-
nique a été réalisée. Elle a permis de :

– Définir les entités nécessaires

– Anticiper les interactions entre les différents composants

Cette phase a été essentielle pour garantir une cohérence technique dans tout le
blueprint.

• Développement progressif Chaque sous-objectif a ensuite été développé indépen-

damment, en respectant :

– La cohérence avec l’architecture globale du projet,

– La lisibilité et la maintenabilité du code,
– L’organisation modulaire des composants.

Cette approche m’a permis d’avancer de manière progressive et maîtrisée.

7
 • Tests et validation Chaque fonctionnalité développée a été testée pour :

– Vérifier sa conformité par rapport aux attentes,

– S’assurer de son bon fonctionnement et de sa robustesse,
– Identifier et corriger d’éventuelles anomalies.

• Commit et versionnement via Bitbucket Après validation, chaque évolution a été

intégrée au projet principal à l’aide de Git, avec un dépôt distant hébergé sur Bitbu-
cket. Le versionnement a été assuré par des commits clairs, structurés et réguliers,
facilitant le suivi du travail accompli et la traçabilité des modifications.

• Suivi via diagramme de Gantt Un diagramme de Gantt figure 1.3 a été élaboré pour
planifier et visualiser les différentes étapes du projet. Il m’a servi de support pour :

– Suivre l’état d’avancement des tâches.

– Adapter les priorités en fonction de l’évolution du projet.
– Maintenir une planification rigoureuse tout au long de la réalisation.

Fig. 1.2 : Diagramme de Gantt

Conclusion
En résumé, ce chapitre a permis de poser les bases du projet en exposant les enjeux
métiers, les exigences de sécurité, ainsi que les contraintes techniques et organisationnelles.
Cette analyse du contexte constitue une étape essentielle pour comprendre les choix tech-
nologiques et les orientations méthodologiques adoptées dans les chapitres suivants.

8
Chapitre 2

Revue de littérature

Introduction
Ce chapitre offre une analyse approfondie des fondements et des enjeux de la sécurité
informatique, en particulier dans le cadre des applications modernes. Nous y définissons
les principes essentiels de la sécurité, avant d’examiner les principaux modèles de contrôle
d’accès actuellement déployés, notamment RBAC, ABAC, PBAC et CPAC, en évaluant
leurs forces et leurs limites respectives. Cette étude critique permet de justifier le choix
du modèle RBAC pour le développement de notre blueprint JHipster, en tenant compte
des spécificités techniques et fonctionnelles de notre environnement cible.

2.1 La sécurité applicative

La sécurité applicative est un enjeu majeur dans le contexte actuel marqué par la
multiplication des cyberattaques et l’importance croissante des données numé[Link]
couvre l’ensemble des mesures techniques, organisationnelles, juridiques et humaines des-
tinées à protéger les systèmes informatiques, les réseaux et les données contre les accès non
autorisés, les attaques malveillantes, les fuites d’informations ainsi que les destructions
accidentelles ou volontaires. Dans un monde où les cyberattaques se multiplient et où les
données numériques représentent un actif stratégique majeur, la sécurité informatique est
devenue un impératif pour les particuliers comme pour les entreprises.
Cette sécurité repose sur trois objectifs fondamentaux, souvent appelés la triade CID
illustrée à la figure 1.3 :

• La Confidentialité : garantit que seules les personnes autorisées peuvent accéder

aux informations ;

• L’Intégrité : assure que les données ne sont pas modifiées illégalement et restent
fiables .

• La Disponibilité : permet un accès rapide et fiable aux données et services né-

cessaires, même en cas d’incident. À ces trois piliers s’ajoute parfois la notion de
non-répudiation, qui renforce la confiance dans les échanges numériques en vérifiant
l’identité des expéditeurs et destinataires.

9
 Fig. 2.1 : La triade CID

Pour répondre à ces enjeux, la sécurité applicative s’impose comme une composante essen-
tielle de la cybersécurité globale. Elle se concentre sur la protection des logiciels, services
et interfaces exposés aux utilisateurs, notamment les applications web et mobiles. Elle
repose sur plusieurs mécanismes complémentaires, tels que :

• la gestion des accès(authentification, autorisation, contrôle des rôles et permis-

sions),

• la protection contre les vulnérabilités (injections, scripts malveillants, etc.),

• l’intégrité des échanges de données (via le chiffrement et la validation des

entrées),

• la surveillance des comportements anormaux.

Ces mécanismes sont mis en œuvre à travers des outils comme les pare-feu applicatifs, les
gestionnaires d’identité, les frameworks de sécurité (comme Spring Security), ou encore
les modèles de contrôle d’accès tels que RBAC, ABAC et PBAC..

2.2 La gestion de la confidentialité des applications

Dans ce cadre global, la sécurité des applications occupe une place centrale. En effet,
les applications, qu’elles soient web, mobiles ou d’entreprise, sont souvent la porte d’en-
trée privilégiée des cyberattaques. Leur complexité et leur exposition permanente aux
utilisateurs rendent indispensable la mise en place de mesures spécifiques pour prévenir
les vulnérabilités, garantir une authentification robuste, contrôler précisément les accès et
assurer la résilience face aux menaces.
Pour répondre à ces besoins, plusieurs modèles de confidentialité des applications
ont été développés. Ces modèles permettent de gérer finement les droits d’accès et les
autorisations des utilisateurs en fonction de critères variés, afin de protéger efficacement
les données sensibles et les fonctions critiques. On distingue principalement les approches
suivantes :

2.2.1 RBAC (Role-Based Access Control) : Contrôle d’accès basé sur

les rôles
Le modèle RBAC (Role-Based Access Control) consiste à attribuer des autorisations
aux utilisateurs en fonction des rôles qui leur sont assignés au sein de l’organisation.
Chaque rôle regroupe un ensemble de permissions, et les utilisateurs héritent de ces per-
missions en fonction de leur rôle. Par exemple, un employé du service financier aura accès

10
à certains fichiers que d’autres services ne peuvent pas consulter. Ce modèle est simple à
mettre en œuvre et efficace dans des environnements où les responsabilités sont stables.
Cependant, il devient moins adapté lorsque les besoins d’accès évoluent fréquemment ou
nécessitent une personnalisation fine. [6][7][8][9]
Points clés :

• Facile à gérer dans des structures classiques.

• Adapté aux contextes où les responsabilités des utilisateurs sont bien définies et peu
sujettes à des changements.

• Moins adapté aux accès nécessitant une personnalisation dynamique ou spécifique.

2.2.2 ABAC (Attribute-Based Access Control) : Contrôle d’accès basé

sur les attributs
L’ABAC (Attribute-Based Access Control) détermine l’accès en fonction d’attributs
multiples liés à l’utilisateur (poste, département), à la ressource (type, classification), à
l’action (lecture, modification) et au contexte (heure, localisation). Ce modèle permet une
gestion fine et dynamique des accès, adaptée aux environnements complexes ou en évolu-
tion rapide. Contrairement au RBAC, l’ABAC ne se limite pas aux rôles mais prend en
compte un ensemble plus large de critères pour autoriser ou refuser l’accès. [6] [7][10][11][9]
Points clés :

• Très flexible et granulaire.

• Permet d’adapter les règles d’accès à des situations complexes.

• Plus complexe à configurer et maintenir.

2.2.3 PBAC (Policy-Based Access Control) : Contrôle d’accès basé sur

les politiques
Le PBAC (Policy-Based Access Control) utilise des politiques centralisées qui dé-
finissent les règles d’accès en combinant des attributs et des conditions spécifiques. Ces
politiques sont souvent rédigées dans un langage compréhensible par les métiers, facilitant
leur gestion et modification. Le PBAC allie la flexibilité de l’ABAC avec une gestion cen-
tralisée, ce qui est particulièrement adapté aux organisations souhaitant aligner les accès
sur des règles métier évolutives et conformes aux exigences réglementaires. [10][11][12][13]
Points clés :

• Centralisation et automatisation des règles d’accès.

• Politiques compréhensibles et modifiables par les non-techniciens.

• Adapté aux environnements réglementés et métiers complexes.

11
2.2.4 CPAC (Context-Based Access Control) : Contrôle d’accès basé
sur le contexte
Le CPAC (Context-Based Access Control) accorde ou refuse l’accès en fonction du
contexte de la demande, tel que l’heure, la localisation, le type d’appareil ou le comporte-
ment récent de l’utilisateur. Ce modèle est souvent utilisé en complément des autres pour
renforcer la sécurité en tenant compte des conditions réelles d’utilisation. Il est similaire
à l’ABAC, mais met davantage l’accent sur la dimension contextuelle et en temps réel.
[10][11][13]
Points clés :

• Adaptation des autorisations en fonction du contexte.

• Renforcement de la sécurité par la prise en compte des contextes.

2.3 Benchmark des modèles de sécurité des applications

Dans le but d’évaluer les principales méthodes de contrôle d’accès adoptées dans les
systèmes d’information actuels, le tableau ci-dessous propose une analyse comparative
des modèles RBAC, ABAC, PBAC et CPAC. Cette comparaison repose sur plusieurs
critères clés tels que la simplicité de mise en œuvre, la flexibilité, le niveau de sécurité, la
capacité d’adaptation aux environnements dynamiques ainsi que les cas d’usages typiques.
Ce benchmark vise à fournir une vision synthétique des avantages et des limites de chaque
modèle afin, de guider le choix en fonction du contexte organisationnel et des exigences
de sécurité.

Modèle Simplicité Flexibilité Sécurité Adaptabilité

RBAC Facile à mettre Peu flexible, Sécurisé mais ri- Peu adapté aux
en place, gestion rôles statiques. gide. environnements
centralisée. dynamiques.
ABAC Complexe, Très flexible, ba- Très granulaire, Idéal pour des envi-
nécessite une sée sur des attri- contrôle détaillé. ronnements dyna-
gestion fine des buts. miques.
attributs.
PBAC Moyennement Flexible selon les Sécurisé selon Très adapté aux
simple, gestion règles métiers. les politiques règles évolutives.
par politiques. définies.
CPAC Complexe, Flexible mais Sécurisé, adapté Très adapté aux
nécessite une dépendant du au temps réel. environnements
analyse contex- contexte. dynamiques.
tuelle.

Tab. 2.1 : Benchmark des modèles de contrôle d’accès

2.4 Justification du choix

Après avoir comparé les modèles, il convient de justifier pourquoi le modèle RBAC est
privilégié dans notre contexte. Le choix d’adopter le modèle RBAC (Role-Based Access

12
Control) dans notre blueprint JHipster repose avant tout sur sa facilité de mise en œuvre
et sa pertinence dans des environnements où les rôles sont clairement définis et relative-
ment stables. Dans notre cas, les responsabilités des utilisateurs sont bien établies et peu
évolutives, ce qui rend RBAC particulièrement adapté. Ce modèle assure un bon niveau
de sécurité tout en simplifiant la gestion des permissions. Par ailleurs, il facilite les proces-
sus d’audit et de conformité, éléments essentiels dans notre contexte de développement.
Comme le montre le tableau comparatif 2.1, RBAC se distingue par sa simplicité et sa
robustesse, ce qui en fait une solution éprouvée et fiable, fréquemment utilisée dans des
architectures similaires à la nôtre.

2.5 Écosystème technologique de JHipster

2.5.1 JHipster
JHipster (Java Hipster) est un générateur de code open-source permettant de créer
des applications Web modernes et complètes, basées sur des technologies récentes côté
client et serveur. Il s’appuie sur Yeoman pour la génération de projet et permet de choisir
parmi plusieurs stacks front-end (Angular, React, Vue) et back-end (Spring Boot, Micro-
naut, Quarkus…). JHipster est idéal pour les architectures microservices, car il permet
l’intégration fluide d’outils de gestion de la configuration, de la sécurité et du déploie-
ment. Il prend également en charge nativement les conteneurs et l’orchestration, ce qui
le rend particulièrement adapté aux environnements DevOps. JHipster prend en charge
nativement ou via des blueprints :

• L’authentification OAuth2 / JWT via Keycloak,

• Le discovery service via Consul ou Eureka,

• La gestion des conteneurs Docker et le déploiement avec Kubernetes,

• Le monitoring avec Prometheus, Grafana, Zipkin

2.5.2 Les architectures jhipster

JHipster propose, lors de la génération d’un projet, deux types d’architectures princi-
pales : monolithique et microservices, chacune étant construite automatiquement avec un
ensemble d’outils et de configurations adaptés.

[Link] Architecture monolithique

En choisissant une architecture monolithique avec JHipster, on obtient une applica-
tion complète comme illustrée à la figure 2.2 où le backend, construit avec Spring Boot,
et le frontend, développé en Angular sont regroupés dans un seul et même projet. La ges-
tion des données repose sur une base unique, avec Spring Data pour l’accès aux données
et Liquibase pour gérer les évolutions du schéma. La sécurité est directement intégrée
à l’application, utilisant fréquemment Keycloak ou OAuth2 pour l’authentification et la
gestion des accès. JHipster crée tous les fichiers nécessaires (contrôleurs REST, entités
JPA, services) dans une seule base de code. Cette architecture est idéale pour des appli-
cations simples ou pour un développement rapide avant de migrer vers une architecture

13
plus modulaire. La génération inclut aussi les configurations Docker Compose permettant
de lancer l’application localement avec sa base de données et son système de sécurité

Fig. 2.2 : Architecture monolitique standard

[Link] Architecture microservice initiale

Pour l’architecture microservices Fig (2.3), JHipster génère plusieurs projets distincts :
un ou plusieurs microservices backend autonomes, chacun avec sa propre base de données,
et une gateway (passerelle API) qui centralise l’accès aux microservices. La gateway est
aussi une application Spring Boot, souvent intégrée avec Spring Cloud Gateway, et four-
nit des fonctions transversales comme la gestion de la sécurité via Keycloak, le routage
intelligent, la centralisation des logs et la gestion des sessions. JHipster met en place de
manière automatique les mécanismes nécessaires à la découverte des services, utilisant des
solutions telles que Consul ou Eureka, ainsi qu’une configuration centralisée assurée par
Spring Cloud [Link] microservice publie ses API REST dédiées, avec des commu-
nications généralement sécurisées et optimisées via OAuth2 et JWT. La génération inclut
des fichiers Docker Compose qui facilitent le déploiement et la coordination de l’ensemble
des services et de leurs dépendances, incluant la base de données, le registre des services,
le serveur de configuration, et la gateway.

14
 Fig. 2.3 : Architecture microservice standard

2.5.3 JHipster et Consul

Consul est utilisé par défaut comme solution de registre de services dans les architec-
tures microservices générées par JHipster. Comparé à d’autres solutions comme Eureka,
Consul est plus facile à gérer dans un cluster multi-nœuds et assure une meilleure cohé-
rence des états du cluster. Grâce à son interface DNS et à son API HTTP, il permet une
découverte de services fluide et une configuration centralisée via un magasin clé/valeur.

2.5.4 JHipster et Keycloak

JHipster s’appuie sur Keycloak comme solution par défaut pour la gestion de la
sécurité et de l’authentification. Ce serveur compatible OpenID Connect permet d’unifier
la gestion des comptes utilisateurs, des rôles et des droits d’accès. Grâce à son support
des protocoles standards (OAuth2, OpenID), il améliore la sécurité des applications en
centralisant la gestion des accès. JHipster simplifie l’intégration de Keycloak en offrant un
conteneur Docker préconfiguré, ce qui permet de déployer et de gérer rapidement Keycloak
au sein des projets.

2.5.5 JHipster et Docker

Docker et Docker Compose sont largement utilisés dans l’écosystème JHipster
pour simplifier le déploiement et le développement. JHipster génère automatiquement
des configurations Docker Compose pour lancer facilement les applications avec leurs
dépendances (bases de données, registres de services, systèmes de sécurité, etc.). Cette
approche permet de démarrer une infrastructure complète avec une seule commande,

15
adaptée aussi bien au développement qu’à la production, notamment dans les architectures
microservices où la montée en charge et la scalabilité sont essentielles

2.5.6 Spring Boot : le socle backend

Dans l’écosystème JHipster,Spring Boot sert de base essentielle pour le développement
côté serveur .Ce framework facilite la création d’applications Java autonomes grâce à sa
configuration automatique, ses serveurs intégrés , et ses outils intégrés pour la production
(supervision, état de santé, configuration externe, etc.). En tirant parti de l’écosystème
Spring (Spring Security, Spring Data, Spring MVC, etc.), JHipster permet de générer des
backends robustes, modulables et facilement déployables.

2.5.7 Angular : framework frontend moderne

Pour la partie cliente, JHipster intègre Angular, un framework JavaScript moderne et
structuré. Le code client respecte les bonnes pratiques et conventions officielles d’Angu-
lar, assurant une organisation structurée des fichiers et une gestion des routes via Angular
Router. JHipster utilise Angular CLI pour construire et tester les applications, avec des
configurations personnalisées pour améliorer l’expérience développeur (par exemple, inté-
gration de BrowserSync, ESLint). Cette intégration permet de générer des interfaces uti-
lisateur dynamiques et réactives, parfaitement adaptées aux applications web modernes

2.6 Blueprnt Jhipster : Personnalisation avancée

2.6.1 Qu’est-ce qu’un Blueprint dans JHipster ?

Un blueprint JHipster correspond à une extension personnalisée du générateur
principal. Il permet de modifier, compléter ou remplacer le comportement des générateurs
standards (application, entités, client, serveur, etc.) sans altérer directement le code source
principal de JHipster. Grâce à cette approche modulaire, les développeurs peuvent adapter
la génération de projets aux besoins spécifiques de leur organisation ou environnement
technique. [14]

2.6.2 Objectifs des Blueprints JHipster

Les blueprints sont conçus pour :

• Étendre les fonctionnalités existantes : Ajouter le support d’un nouveau langage,

framework ou style d’architecture (par exemple, intégrer un backend Kotlin ou Nest-
JS).

• Modifier les comportements standards : Personnaliser la génération de code côté

client, serveur, ou entités selon des règles spécifiques.

• Isoler les personnalisations : En regroupant les adaptations spécifiques au sein d’un

blueprint, on facilite la gestion des évolutions de JHipster, tout en conservant in-
tactes les personnalisations appliquées au projet.

16
 • Fournir des solutions prêtes à l’emploi : Créer des générateurs spécialisés pour des
cas d’usage précis, comme des applications mobiles ou des microservices avec une
stack technologique alternative. [15]

2.6.3 Exemples de Blueprints Officiels

L’écosystème JHipster inclut plusieurs blueprints maintenus par la communauté ou
l’équipe principale, tels que [16] :

• Kotlin : Substitue le backend Java par Kotlin, en offrant une alternative moderne
et concise pour le développement côté serveur.

• .NET Core : Permet de générer une application serveur en .NET Core en rempla-
cement du backend par défaut basé sur Spring Boot.

• [Link] / NestJS : Propose une architecture backend reposant sur [Link], struc-
turée avec le framework avancé NestJS, conçu pour la modularité et la maintenabi-
lité.

• React Native : génère une application mobile native.

• Quarkus, Micronaut, Svelte, Ionic : introduisent différents frameworks et pa-

radigmes.

2.6.4 Cycle de vie d’un Blueprint JHipster

Un blueprint suit le cycle de génération illustré à la figure (2.4), structuré en plusieurs
phases. À chacune d’elles, il peut injecter du code, modifier les comportements par défaut
ou interagir avec l’utilisateur. [17]

Fig. 2.4 : Cycle de vie du Blueprint Jhipster

• Constructeur : Il s’agit de la phase d’initialisation du blueprint. Celui-ci établit

son environnement, valide qu’il fonctionne bien dans un contexte JHipster, et met en
place les variables globales ainsi que les dépendances utiles pour les étapes suivantes.

17
 • Initializing (Initialisation) : Préparation des données de base et configuration
initiale. Cette étape peut inclure la vérification de dépendances, la lecture de fichiers
de configuration ou la définition d’options par défaut.

• Prompting (Questions) : Interaction avec l’utilisateur pour recueillir ses choix

(technologies, options spécifiques, préférences).

• Configuring (Configuration) : En fonction des réponses précédentes, le blue-

print définit les paramètres de génération : noms de fichiers, technologies utilisées,
structure des répertoires, etc.

• Writing (Création des fichiers) : À cette phase, le blueprint produit les fichiers
du projet. Il génère de nouveaux fichiers, substitue les originaux de JHipster ou
modifie leur contenu selon les spécifications personnalisées.

• Composing (Composition) : Permet au blueprint d’intégrer d’autres générateurs

ou blueprints pour créer des architectures plus complexes ou collaboratives.

• Install (Installation) : Installation des dépendances (npm, Maven, Gradle, etc.).

Le blueprint peut compléter ou modifier cette étape selon les outils utilisés.

• End (Finalisation) : Dernière étape du processus, elle permet d’exécuter des

tâches complémentaires comme l’affichage de messages informatifs, le lancement de
scripts additionnels, ou encore la vérification finale de la configuration générée.

Dans le blueprint que nous avons développé, nous utilisons la phase postWritingEntities,
appartenant à la phase writing du cycle de génération de JHipster. Cette phase inter-
vient après la création initiale des entités et permet d’injecter automatiquement du code
supplémentaire ou de modifier les fichiers générés sans perturber les étapes précédentes.
Cette approche est particulièrement adaptée pour intégrer la gestion fine des permissions
et des relations spécifiques à notre projet, car elle garantit que les personnalisations sont
appliquées de manière cohérente et maintenable, tout en respectant le cycle standard de
génération.

Conclusion
La confidentialité des applications demeure un défi majeur face à la complexité crois-
sante des systèmes et aux menaces évolutives. Les différentes approches de contrôle d’accès
répondent à des besoins variés, alliant contraintes opérationnelles et exigences de sécurité.
Dans ce contexte, le modèle RBAC s’impose comme une solution pragmatique et efficace,
offrant un équilibre pertinent entre granularité et simplicité de gestion. Son adoption dans
le cadre du blueprint JHipster garantit une intégration fluide et une extensibilité adaptée
aux architectures modulaires, répondant ainsi aux exigences spécifiques de notre projet.

18
Chapitre 3

Analyse de besoins et conception

Introduction
Dans ce chapitre, nous présentons la conception globale de la solution à travers deux
axes complémentaires : d’une part, les exigences fonctionnelles de la solution proposée ;
d’autre part, les contraintes critiques imposées par l’architecture initiale de JHipster. En-
suite, nous décrivons la modélisation UML de la solution à l’aide de plusieurs diagrammes :
diagramme de cas d’utilisation, diagramme de classes et diagrammes de séquences. Cette
approche permet de structurer efficacement le développement et de garantir la cohérence
du blueprint tout au long de son intégration dans un projet JHipster.

3.1 Exigences fonctionnelles du projet

Les principales exigences fonctionnelles qui guident le développement du blueprint
sont les suivantes :

• EF1 : La solution doit être pleinement fonctionnelle dans les deux types d’archi-
tectures supportées par JHipster : monolithique et microservice.

• EF2 : Chaque rôle (Authority) doit pouvoir être associé à un ensemble de permis-
sions précises, représentant les actions autorisées sur les ressources métier.

• EF3 : Le blueprint doit générer automatiquement toute la configuration nécessaire

à l’intégration du modèle RBAC.

• EF4 : L’affichage des éléments de l’interface est restreint dynamiquement en fonc-

tion des droits de l’utilisateur, en contrôlant l’accès aux routes et aux composants
selon ses rôles et ses permissions effectifs

3.2 critique de l’architecture initiale de JHipster

Comme présenté précédemment au chapitre 2 (voir Figures 2.2 et 2.3), JHipster pro-
pose deux architectures principales : une architecture monolithique, reposant sur une
application Spring Boot unique intégrant un frontend Angular, et une architecture mi-
croservices, construite autour de Spring Cloud Gateway pour le routage, de Consul pour
la découverte dynamique des services, et d’un frontend Angular interagissant avec les

19
microservices via la passerelle. Dans les deux cas, Keycloak est utilisé comme serveur
d’authentification centralisé, assurant la gestion des utilisateurs et de leurs rôles
Bien que ces architectures reposent sur des technologies éprouvées et largement utili-
sées, elles présentent plusieurs limitations importantes en matière de gestion fine des accès
et de sécurité :
• Modèle de sécurité rigide : Le contrôle d’accès se base sur un modèle RBAC simple,
avec des rôles codés en dur. Ce modèle ne permet ni la définition d’une hiérarchie
entre les rôles, ni une granularité au niveau des permissions spécifiques (telles que
VIEW, EDIT, DELETE). Cela limite fortement la capacité à appliquer des poli-
tiques de sécurité précises et adaptées aux différents profils utilisateurs.

• Interface utilisateur non adaptative : Le frontend Angular ne propose pas de méca-

nisme dynamique pour adapter l’affichage des éléments en fonction des droits réels
de l’utilisateur connecté. Cette absence entraîne une expérience utilisateur moins
sécurisée et moins ergonomique, puisqu’elle peut exposer des fonctionnalités non
autorisées.

• Disparité et duplication de la logique de sécurité : Dans le modèle microservices,

chaque service gère sa propre configuration de sécurité indépendamment, ce qui
engendre une dispersion des règles. Cette fragmentation complique la cohérence
globale de la sécurité, accroît le risque d’incohérences, et complexifie la maintenance
à l’échelle du système.
Ces constats démontrent que, même si les architectures initiales proposées par JHipster
sont robustes et adaptées à des déploiements rapides, elles révèlent rapidement leurs li-
mites lorsqu’il s’agit de mettre en œuvre une gestion des rôles et permissions à la fois fine,
cohérente, centralisée et évolutive dans un contexte réel.

3.3 Diagramme Use Case

Le diagramme 3.1 ci-dessous présente les principaux cas d’usage gérés par notre blue-
print JHipster. Il met en lumière les fonctionnalités offertes aux développeurs lors de
l’intégration du module blueprint Jhipster dans une application, notamment pour la sé-
curisation, la gestion des rôles, et la personnalisation des interfaces utilisateur. Ces cas
d’utilisation correspondent aux actions principales automatisées par le blueprint,limitant
fortement les tâches manuelles habituellement requises par les développeurs.

Fig. 3.1 : diagramme use case

20
 • Sécurisation des endpoints backend : Le blueprint configure automatiquement
tous les éléments nécessaires à la protection des endpoints REST. Cela englobe la
génération et la modification des classes, des services et des fichiers de configuration,
ainsi que l’application précise des règles liées aux rôles et permissions des utilisa-
teurs. Cette automatisation assure un contrôle d’accès fiable et conforme aux droits
définis.

• Protection des routes frontend : Ce cas d’utilisation consiste à contrôler l’accès

aux différentes pages de l’application Angular en fonction des permissions détenues
par l’utilisateur. Le blueprint injecte automatiquement les règles nécessaires dans
les fichiers de routage, en associant chaque chemin à une permission spécifique via
des constantes et des mécanismes de garde personnalisés. Ainsi, toute tentative
d’accès à une route non autorisée est interceptée, assurant une navigation sécurisée
et conforme au profil de chaque utilisateur.

• Personnaliser les interfaces utilisateur : Cette fonctionnalité adapte dynami-

quement les composants frontend pour afficher ou masquer certains éléments d’in-
terface en fonction des permissions de l’utilisateur connecté. Le blueprint prend en
charge la création et l’adaptation des fichiers Angular en y intégrant des règles d’ac-
cès, permettant ainsi d’ajuster l’interface selon les permissions de l’utilisateur, sans
intervention manuelle.

• Gérer le rôle de l’utilisateur : Ce cas d’utilisation permet d’attribuer, modifier

ou retirer des rôles aux utilisateurs. Il constitue une étape préalable indispensable,
puisqu’il permet de sélectionner un rôle existant avant de pouvoir lui associer des
permissions. Le blueprint assure automatiquement la création et l’ajustement des
fichiers Angular nécessaires, en ajoutant des directives pour contrôler l’accès. Cela
permet de restreindre l’affichage de certaines fonctionnalités en fonction des per-
missions, offrant ainsi une interface adaptée au profil de chaque utilisateur.

• Assigner des permissions aux rôles : Accessible via la gestion des rôles, cette
fonctionnalité permet de définir précisément les permissions attachées à chaque rôle.
Après avoir choisi un rôle via l’interface de gestion, l’administrateur peut lui assigner
des permissions spécifiques. Le blueprint prend en charge la génération automatique
des entités, des services, des contrôleurs, ainsi que des interfaces frontend permettant
cette association, garantissant une gestion fine et sécurisée des droits d’accès.
Chaque cas d’utilisation illustre une facette complémentaire de l’automatisation offerte
par le blueprint, qui agit à tous les niveaux de l’application : configuration backend,
sécurisation, adaptation du frontend. L’objectif est clair : fournir une solution clé en main
pour intégrer une gestion fine des permissions, avec un minimum d’effort humain et une
cohérence technique renforcée dans tout le système.

3.4 Diagrammes de séquence du Blueprint

3.4.1 Diagramme de séquence pour sécuriser les endpoints REST

Le diagramme de séquence 3.2 ci-dessous illustre le déroulement des interactions entre
les différents acteurs impliqués dans le processus de sécurisation des endpoints REST,

21
suite à l’intégration de notre blueprint JHipster. Il met en évidence le rôle de chaque
composant — du développeur jusqu’au client final — dans la mise en œuvre et l’exécution
de la logique de contrôle d’accès basée sur les rôles et permissions.

Fig. 3.2 : Diagramme de séquence pour sécuriser les endpoints REST

Le fonctionnement global du mécanisme de sécurité introduit par notre module blue-

print peut être décomposé en plusieurs étapes clés, depuis l’intégration initiale jusqu’au
contrôle d’accès dynamique lors de l’exécution de l’application.

• Déclenchement par le développeur : le processus commence lorsque le développeur

applique le blueprint à une application JHipster existante. Ce blueprint injecte au-
tomatiquement l’ensemble des fichiers nécessaires à la gestion de la sécurité (fichiers
Java, annotations, configurations, directives Angular, etc.).

• Authentification de l’utilisateur : lors de l’exécution de l’application, le client utilisa-

teur s’authentifie en envoyant ses identifiants. L’application valide ces informations
(via JWT ou OAuth2) et lui renvoie un token.

• Accès à un point de terminaison sécurisé : après authentification, le client envoie une

requête vers une ressource protégée. Le token d’accès est automatiquement inclus
dans l’en-tête de cette requête.

• Contrôle des accès : en s’appuyant sur les mécanismes ajoutés par le blueprint, l’ap-
plication analyse le token afin d’identifier les rôles de l’utilisateur, en extrait les
permissions correspondantes, applique la hiérarchie définie, puis vérifie si l’utilisa-
teur possède les droits nécessaires pour accéder à la ressource demandée.
Réponse adaptée :

– Si l’utilisateur détient la permission adéquate, l’accès lui est accordé.

22
 – Sinon, un message d’erreur lui est retourné pour signaler l’absence d’autorisa-
tion suffisante.

3.4.2 Diagrammes de séquences pour sécuriser les routes et personna-

liser les interface
Les diagrammes de séquence 3.3 et 3.4 illustrent le flux général de la sécurisation
des routes et la personnalisation de l’interface dans une application JHipster enrichie par
le module blueprint que nous avons développé. Ce flux couvre à la fois l’architecture
monolithique et microservices, en mettant en évidence les différentes étapes impliquées
depuis la génération de l’application jusqu’au contrôle des accès sur le frontend.

23
24

Fig. 3.3 : Flux de sécurisation des routes (architecture microservice)(1)

25

Fig. 3.4 : Flux de sécurisation des routes (architecture microservice)(2)

26

Fig. 3.5 : Flux de sécurisation des routes (architecture monolithique)

 Le mécanisme de sécurité intégré par notre blueprint suit une séquence structurée
d’étapes, allant de son incorporation initiale dans l’application JHipster jusqu’à la gestion
dynamique des droits d’accès au moment de l’exécution.

• Déclenchement par le développeur : le processus débute lorsque le développeur ap-

plique le blueprint à une application JHipster. Celui-ci automatise la configuration
de la sécurité en injectant tous les mécaniques nécessaires à la gestion des rôles et
des permissions, à la fois côté backend et frontend.

• Authentification de l’utilisateur : lorsqu’un utilisateur tente d’accéder à l’applica-

tion, il fournit ses identifiants via l’interface de [Link] serveur vérifie les
identifiants fournis et, si l’authentification réussit, il délivre un jeton d’accès, le plus
souvent au format JWT ou selon le protocole OAuth2.

• Récupération des permissions :

– Dans le cas d’une architecture microservices, la gateway récupère dynamique-

ment la liste des microservices via le registre de services (Consul), puis les
interroge individuellement afin de collecter les permissions associées à l’utili-
sateur authentifié.
– Dans le cas monolithique, les permissions sont chargées localement sans appel
externe.

• Transmission au frontend : Une fois les permissions récupérées, elles sont incluses
dans la réponse envoyée au frontend pour adapter dynamiquement les interfaces.

• Accès à une route ou action protégée : lorsqu’un utilisateur interagit avec l’ap-
plication (par exemple, lors d’un clic sur un bouton ou d’une tentative d’accès à
une route), les permissions sont vérifiés afin de s’assurer qu’elles correspondent aux
permissions nécessaires pour effectuer l’action demandée

• Contrôle des accès (frontend et backend) :

– Côté frontend : si l’utilisateur n’a pas la permission, l’élément est masqué (ex.
bouton non affiché).
– Côté backend : une fois la requête envoyée, l’application vérifie à nouveau les
rôles et permissions de l’utilisateur via le token d’accès.

• Réponse de l’application :

– Si l’utilisateur possède les droits requis, l’action est autorisée et la ressource

est retournée.
– Sinon, une erreur (généralement 403 - Forbidden) est retournée pour signaler
l’absence de droits suffisants.

27
3.4.3 Diagramme de séquence pour la gestion des rôles et des permis-
sions
La figure suivante 3.5 présente un diagramme de séquence décrivant le processus d’in-
teraction entre les différents acteurs et composants dans le cadre de la gestion des rôles
et des permissions dans une application JHipster générée via un blueprint personnalisé.
Ce diagramme met en évidence les étapes allant depuis la génération du code Angular
jusqu’à l’assignation des permissions à un rôle par l’utilisateur via l’interface.

Fig. 3.6 : Diagramme de séquence pour la gestion des roles et des permissions

Dans un premier temps, le développeur utilise un blueprint JHipster personnalisé qui

injecte automatiquement dans l’application plusieurs composants Angular permettant une
gestion fine et intuitive des rôles et des permissions. Parmi les fichiers générés ou modifiés
automatiquement, on retrouve notamment :

• [Link]/html : interface de gestion et de modification des

rôles existants ;

• [Link]/html : composant permettant d’assigner ou de re-

tirer des permissions à un rôle sélectionné ;

• [Link] et [Link] : services Angular responsables de la commu-

nication avec les APIs REST du backend.

Ces fichiers font partie d’un ensemble plus large de composants Angular générés par le
blueprint pour couvrir l’intégralité de la logique de gestion des accès. Cette automatisation
permet de standardiser l’implémentation de la sécurité dans l’interface utilisateur et de
réduire considérablement le travail manuel du développeur.
Une fois l’application générée et déployée, l’utilisateur final (administrateur) peut
accéder à l’interface web de gestion :

• Il accède à la page de gestion des rôles via le frontend de l’application.

• L’application charge dynamiquement la liste des rôles disponibles depuis le backend.

28
 • Lorsque l’utilisateur sélectionne un rôle, il est redirigé vers une nouvelle interface
affichant les permissions associées à ce rôle.

• L’application récupère à la fois les permissions actuellement associées au rôle ainsi

que toutes les permissions pouvant être attribuées.

• L’utilisateur peut alors assigner ou retirer des permissions à ce rôle à l’aide d’une
interface intuitive (liste à cocher, boutons, etc.).

• Ces opérations entraînent des appels vers le backend qui modifient la base de données
afin de refléter les nouvelles associations entre rôles et permissions.

• Une confirmation ou un message de succès est ensuite affiché pour valider l’opéra-
tion.

[Link] Remarque :
Le blueprint personnalisé n’a besoin d’être exécuté qu’une seule fois, à n’importe
quel moment du cycle de développement. Une fois appliqué, il injecte automatiquement
l’ensemble de la configuration nécessaire — aussi bien côté frontend que backend — sans
nécessiter d’exécution répétée ni d’intervention manuelle supplémentaire.

3.5 Diagramme de classe

Fig. 3.7 : Diagramme de classe

Dans le cadre de l’implémentation d’un contrôle d’accès basé sur les rôles (RBAC –
Role-Based Access Control) avec une gestion fine des permissions, le blueprint JHipster
personnalisé ajoute automatiquement deux tables supplémentaires à la base de données :
permission et jhi-authority-permission.

29
 La table permission permet de définir des autorisations métier précises, tandis que
la table d’association jhi-authority-permission établit une relation many-to-many
entre les rôles (jhi-authority) et les permissions.

Cette extension du modèle de données permet de dépasser les limites du modèle RBAC
standard de JHipster, qui ne prend en charge que les rôles, en introduisant une granularité
plus fine dans le contrôle d’accès aux fonctionnalités de l’application.

L’ajout de ces tables est entièrement automatisé par le blueprint, garantissant une
génération et une intégration systématiques et cohérentes à chaque création ou mise à
jour d’un microservice ou d’une application monolithique.

Conclusion
Ce chapitre a présenté la conception détaillée de notre solution d’intégration d’un
blueprint JHipster dédié à la gestion fine des rôles et des permissions. À travers les dif-
férents diagrammes UML — cas d’utilisation, séquences, et classes — nous avons illustré
la structure fonctionnelle et technique de notre module, depuis l’automatisation de la
sécurisation du backend jusqu’à l’adaptation dynamique des interfaces frontend.

30
Chapitre 4

Réalisation du blueprint coté

backend

Introduction
Ce chapitre met en lumière les principales actions réalisées par le blueprint côté back-
end des applications JHipster. Développé dans le but d’étendre les fonctionnalités stan-
dards de la plateforme, ce module se concentre particulièrement sur les aspects liés à la
sécurité et à la gestion fine des permissions.
Il s’appuie sur une étude comparative entre la configuration de sécurité proposée par
défaut par JHipster et l’architecture enrichie intégrant le blueprint que nous avons conçu.
Les principales évolutions introduites sont détaillées, notamment l’intégration des permis-
sions, la hiérarchisation des rôles, ainsi que la découverte dynamique des microservices
via Consul.
Les sections qui suivent présentent, de manière progressive, la structure, la logique, et
les mécanismes techniques mis en œuvre pour construire une architecture microservices à
la fois sécurisée, cohérente et extensible.

4.1 Intégration du Blueprint dans les architectures JHipster

Pour surmonter les limites observées dans les architectures initiales de JHipster (voir
fig (2.2) et (2.3)), Nous avons conçu et développé un blueprint JHipster personnalisé,
qui s’intègre comme une surcouche modulaire à l’architecture existante, apportant des
enrichissements fonctionnels et techniques, notamment en matière de sécurité et de gestion
des permissions. illustrée dans les figures (4.1) et (4.2).

31
Fig. 4.1 : Intégration du Blueprint dans l’architecture microservice

32
 Fig. 4.2 : Intégration du Blueprint dans l’architecture monolithique

Ce blueprint agit comme une surcouche intelligente et automatisée, injectant des mé-
canismes avancés de gestion des accès dans l’application générée, tout en respectant la
nature de l’architecture choisie. Il complète et renforce les mécanismes de sécurité stan-
dard de JHipster, en apportant une gestion centralisée, hiérarchisée et dynamique des
rôles et des permissions.
Notre blueprint est capable de détecter automatiquement l’architecture (monolithique
ou microservices) de l’application lors de sa génération, et d’adapter dynamiquement les
fichiers générés et modifiés pour assurer une sécurité fine, cohérente et homogène.
Les principales contributions introduites par le blueprint dans ces nouvelles architec-
tures enrichies sont les suivantes :

• Hiérarchisation des rôles et des permissions : Le blueprint met en place un modèle

RBAC avancé où chaque rôle se voit attribuer un ensemble précis de permissions
détaillées. Une hiérarchie configurable permet de définir des niveaux d’autorité,
facilitant la gestion des profils complexes.

• Génération centralisée et automatisée de la logique de sécurité : les règles d’accès

sont générées de manière homogène dans chaque service. Cela inclut les annotations
@PreAuthorize, les fichiers de configuration de hiérarchie des permissions, ainsi que
les constantes de permissions. Cette uniformisation réduit les erreurs et accélère le
cycle de développement.

• Adaptation selon l’architecture :

– Dans une application monolithique (voir Figure 4.2), l’ensemble de la logique

de sécurité est regroupé au sein d’un seul et même service, ce qui facilite la
gestion cohérente des accès et des permissions.
– En revanche, dans une architecture microservices (voir Figure 4.1 ), les règles
de sécurité sont distribuées entre les différents services, mais une collecte cen-
tralisée des autorisations reste assurée grâce à une coordination via le Gateway.

33
 • Récupération dynamique des permissions (pour les microservices) : dans cette ar-
chitecture enrichie, le Gateway interroge Consul pour découvrir dynamiquement les
microservices actifs, puis utilise WebClient pour accéder aux endpoints sécurisés de
chaque service. Cela permet de centraliser la collecte des permissions de l’utilisateur
sans compromettre le découplage entre les services.

• Interface utilisateur adaptative : le blueprint génère des directives Angular permet-

tant de conditionner dynamiquement l’affichage des éléments de l’interface utilisa-
teur en fonction des permissions réellement attribuées à l’utilisateur. Cette fonc-
tionnalité améliore l’ergonomie tout en évitant l’exposition de fonctionnalités non
autorisées.

4.2 Les actions du blueprint sur le backend des applications JHips-

ter
Le graphe présenté ci-dessus illustre les différentes modifications structurelles et ajouts
de fichiers effectués par le blueprint sur la partie backend d’une application JHipster

Fig. 4.3 : carte mentale : action du blueprint sur le backend des applications

Dans cette logique, deux catégories de fichiers se distinguent :

• Les fichiers générés : ce sont des fichiers générés automatiquement par le blueprint à
partir de templates que nous avons développés. Ces modèles ont été développés au
sein du blueprint dans le but de fournir une gestion fine, hiérarchisée et sécurisée des
permissions. Chaque template a été conçu en tenant compte du type d’architecture
cible (monolithique ou microservices), ainsi que de sa configuration initiale. Lors de
la génération d’une application, le blueprint se charge d’injecter ces fichiers dans le
projet, en adaptant leur structure aux paramètres de l’application.

34
 • Les fichiers modifiés : il s’agit de fichiers existants dans l’ossature standard d’un
projet JHipster. Leur contenu est automatiquement ajusté par notre blueprint à
l’aide de fonctions personnalisées que nous avons développées. Ces fonctions per-
mettent d’y insérer dynamiquement les éléments de sécurité nécessaires (relations
entités-permissions, annotations de protection, logique d’authentification, etc.), sans
modifier manuellement le code généré de base.

Fichiers générés automatiquement par le blueprint :

• config/

– [Link] : Classe développée pour définir une hiérarchie lo-

gique entre les permissions des entités. Elle permet de prioriser certaines ac-
tions, ce qui facilite le contrôle d’accès selon le niveau d’autorité.
– [Link] : Fichier contenant les constantes de permissions ([Link]-
DELETE, etc.) générées automatiquement pour chaque entité. Cela garantit
une cohérence du code et simplifie l’utilisation des permissions dans le backend.

• domain/ [Link], [Link], [Link] :

Ces entités ont été spécifiquement conçues pour modéliser un système RBAC avan-
cé :

– Permission : définit chaque action possible sur les entités.

– AuthorityPermission : relie un rôle (Authority) à plusieurs permissions.
– AuthorityPermissionId : identifiant composite de la relation many-to-many.

• repository/

– [Link],[Link] : Re-
positories que nous avons développés pour assurer la persistance des entités de
sécurité. Leur logique respecte le modèle JpaRepository (pour monolithes et
microservices) ou R2dbcRepository (pour le gateway).

• web/rest/

– [Link], [Link] : APIs REST

que nous avons créées pour exposer et gérer les associations entre rôles et per-
missions. Elles permettent d’ajouter, supprimer ou consulter dynamiquement
les permissions affectées aux rôles.
– [Link] : Contrôleur REST présent uniquement dans les
microservices, utilisé pour exposer les autorités (rôles) d’un utilisateur.

• service/

– [Link] : Service conçu pour découvrir dynamiquement

les microservices via Consul et appeler leurs endpoints /permissions/Authori-
ties à l’aide de WebClient. Ce fichier est injecté uniquement dans le gateway,
car il est spécifique à l’architecture microservices.

35
 – [Link] : Service généré uniquement dans les microservices,
qui permet uniquement de récupérer les autorités (rôles) de l’utilisateur.
– [Link] : Service métier généré pour gérer les opérations
CRUD sur les permissions et leurs associations avec les rôles.

• service/dto/

– [Link] : DTO (Data Transfer Object) développé pour exposer

les permissions de manière sécurisée, sans exposer directement les entités JPA.

• resources/config/liquibase/

– [Link] : Fichier généré pour créer la table Permission.

– [Link] : Fichier généré pour créer la table de
jointure entre Authority et Permission

• config/

– [Link] : Classe de configuration que nous avons ajoutée

pour permettre les appels interservices sécurisés via OAuth2. Elle est utili-
sée dans les architectures microservices avec communication entre services via
Feign ou WebClient.

Fichiers modifiés automatiquement par le blueprint :

• web/rest/

– [Link] : Le blueprint ajoute automatiquement les an-

notations PreAuthorize selon les permissions spécifiques à l’entité concernée.

• config/

– [Link] : Fichier modifié pour activer l’authentification

OAuth2 dans les appels Feign entre microservices, en injectant un token JWT.
– [Link] : Étendu pour prendre en compte les permis-
sions effectives de l’utilisateur, en plus de ses rôles. Utilisé à la fois dans les
microservices et dans le gateway.

• domain/

– [Link] : Nous avons ajouté une relation @ManyToMany vers l’en-

tité Permission, pour permettre aux rôles d’avoir des permissions personnali-
sées.(pour monolithique et les microservices).

• service/

– [Link] : Le service a été modifié pour charger dynamiquement les

permissions d’un utilisateur à partir de ses rôles. Cette logique complète le
chargement classique des autorités.

36
 • resources/config/liquibase/

– [Link] : Le blueprint ajoute automatiquement les références vers les

nouveaux changelogs liés aux entités Permission, afin de les inclure dans le
processus de migration Liquibase.

• [Link] Des dépendances nécessaires (comme spring-boot-starter-webflux) sont

injectées automatiquement si l’architecture cible est de type microservices.

4.3 Automatisation de la gestionde la confidentialité apportée par

coté backend

4.3.1 Objectif1 : Sécuriser les endpoints backend

• Motivation :
Dans une application JHipster, qu’il s’agisse d’un microservice, de la passerelle (ga-
teway) ou d’un monolithe, chaque module expose des endpoints REST représentant
des points d’entrée critiques dans le système. Il est donc essentiel de mettre en place
un contrôle d’accès précis et granulaire pour :

– Éviter l’exposition non contrôlée de données sensibles ou critiques,

– Appliquer une politique de sécurité précise au niveau de chaque entité métier
et de chaque type d’opération (Create, Read, Update, Delete — CRUD),
– Garantir la séparation des responsabilités entre services et rôles utilisateurs,
– Consolider la gestion de la sécurité afin de garantir une application cohérente
et facile à maintenir.

JHipster, dans sa configuration standard, gère les accès par rôles via l’entité Autho-
rity. Cependant, cette approche reste relativement limitée, car elle ne permet pas de
distinguer les droits précis sur les opérations (ex. : un rôle ADMIN a tous les droits,
mais un rôle USER ne peut pas avoir l’accès aux opérations de suppression). D’où la
nécessité d’introduire un modèle de permissions dynamiques, plus granulaire, pour
affiner le contrôle d’accès.

• Approche choisie :
Pour répondre à ce besoin, nous avons enrichi le modèle RBAC classique de JHipster
par une nouvelle entité : Permission. Cette entité est associée aux rôles (Authority)
et définit des droits spécifiques sur des opérations CRUD appliquées à des entités
métier.
Cette granularité permet de définir avec précision qui peut faire quoi sur quelles
ressources.
Cette architecture est intégralement automatisée grâce à notre blueprint jhipster,
lequel

– Génère les entités et services backend pour gérer les permissions,

– Sécurise automatiquement tous les endpoints REST exposés,

37
 – Crée une hiérarchie logique et facilement modifiable entre les permissions.

• Automatisations réalisées via le blueprint :

a) Génération de l’entité Permission et de son cycle de vie

Le blueprint génère automatiquement, aussi bien pour les microservices, la
passerelle (gateway) que pour les applications monolithiques, l’ensemble des
composants nécessaires à la gestion des permissions. Ces composants incluent :
– [Link] : entité représentant une permission.
– [Link] : interface de persistance Spring (JPA ou
R2DBC) selon le type de l’application.
– [Link] : service métier chargé de la logique de traite-
ment des permissions,
– [Link] : contrôleur REST pour exposer les opéra-
tions CRUD.
– [Link] : entité représentant l’association entre un
rôle et une permission.
– [Link] : interface pour gérer les liaisons
rôle-permission.
– [Link] : (dans les microservices et les application
monolithique uniquement) classe de clé composée (pour JPA).
– [Link] : classe DTO générée dans le gateway, permettant
de transporter les permissions reçues depuis les microservices via les appels
HTTP. Elle facilite la désérialisation et la manipulation des données côté
gateway.
Le blueprint génère dynamiquement les fichiers nécessaires en s’adaptant au
type de module concerné. Pour les microservices et l’architecture monolithique,
le code repose sur un modèle orienté objet classique basé sur JPA. Pour la pas-
serelle (gateway), qui utilise un modèle réactif, le code est structuré pour fonc-
tionner avec R2DBC. Cette adaptation automatique garantit une cohérence
fonctionnelle entre les modules tout en respectant les spécificités techniques de
chaque environnement.
b) Intégration de la hiérarchie des permissions Deux classes sont générées
pour gérer les définitions et la hiérarchie des permissions :
– [Link] : liste toutes les permissions définies
Ce fichier est généré automatiquement et mis à jour dynamiquement à
chaque ajout d’une nouvelle entité. Les permissions correspondant aux
opérations CRUD sont ajoutées selon une convention de nommage stan-
dard (ROLE-ENTITY-ACTION).
– [Link] : configure la hiérarchie des permissions
1 package com. mycompany . myapp . config ;
2 @Configuration
3 public class RoleConfiguration {
4 @Bean

38
 5 public static RoleHierarchy roleHierarchy () {
6 StringBuilder roleHierarchy = new StringBuilder ();
7 roleHierarchy
8 . append ( AuthoritiesConstants . ADMIN )
9 . append (" > ")
10 . append ( RoleConstants . MODEL_DELETE )
11 . append (" > ")
12 . append ( RoleConstants . MODEL_CREATE )
13 . append (" > ")
14 . append ( RoleConstants . MODEL_UPDATE )
15 . append (" > ")
16 . append ( RoleConstants . MODEL_READ )
17 . append ("\n");
18 return
RoleHierarchyImpl . fromHierarchy ( roleHierarchy . toString ());
19 }
20 }
Listing 4.1: Classe [Link]

Ce fichier est également généré automatiquement. À chaque ajout d’entité, les nouvelles
permissions sont intégrées dans la hiérarchie définie, assurant ainsi une mise à jour cohérente
et continue du modèle de sécurité.
c) Modification de l’entité Authority : (Pour les microservices et les
applications monolithique)
La classe [Link] est modifiée automatiquement pour ajouter la relation
@ManyToMany avec les permissions, permettant ainsi l’association d’un rôle
à plusieurs permissions
d) Génération des fichiers Liquibase Pour maintenir la structure de la base de
données à jour, le blueprint produit automatiquement les fichiers de migration
Liquibase correspondants
– [Link] : création de la table permission,
– [Link] : création de la table d’association entre au-
thority et permission,
– [Link] : mise à jour automatique pour inclure ces nouveaux fichiers.
e) Sécurisation automatique des endpoints REST : Le blueprint analyse
automatiquement tous les contrôleurs REST (*[Link]) et injecte l’an-
notation @PreAuthorize sur les méthodes exposées selon la convention :
– La permission est calculée dynamiquement en fonction de l’entité (ex :
Product) et de l’action (CRUD).

[Link] Avant Automatisation

1 @PostMapping ("")
2 public ResponseEntity < ProduitDTO > createProduit (
3 @RequestBody ProduitDTO produitDTO )

39
4 throws URISyntaxException {
5 LOG. debug("REST request to save Produit : {}", produitDTO );
6 if ( produitDTO . getId () != null) {
7 }

Listing 4.2: Exemple End-point avant l'application du blueprint

[Link] Après Automatisation

1 @PostMapping ("")
2 @PreAuthorize (" hasAuthority ('" + RoleConstants . PRODUIT_CREATE + " ')")
3 public ResponseEntity < ProduitDTO > createProduit ( @RequestBody
ProduitDTO produitDTO ) throws URISyntaxException {
4 LOG. debug("REST request to save Produit : {}", produitDTO );
5 }

Listing 4.3: Exemple End-point après l'application du blueprint

Cette automatisation assure une cohérence dans la sécurisation des endpoints sur l’ensemble du
système. Grâce à la génération dynamique des annotations @PreAuthorize, le développeur n’a
plus besoin d’ajouter manuellement des règles de sécurité spécifiques : elles sont injectées selon
une convention standardisée, garantissant ainsi une gouvernance centralisée et fine des droits
d’accès.
f) Intégration dynamique des permissions dans le contexte de sécurité :
gateway, microservices et monolithique
Afin d’intégrer de manière dynamique les autorisations dans le cadre de la
sécurité Spring Security, des ajustements ont été réalisés sur les fonctions res-
ponsables de la conversion des tokens JWT. Ces modifications varient selon
qu’elles s’appliquent au niveau du gateway , des microservices ou d’application
monolithique . Cette approche permet d’ajouter automatiquement aux rôles
(Authorities) de l’utilisateur les permissions correspondantes dès son authen-
tification, assurant ainsi une gestion précise et évolutive des droits d’accès.
(a) Modification côté gateway : Dans le gateway, la gestion de l’authenti-
fication repose sur le protocole OpenID Connect (OIDC) avec un flux ré-
actif. La méthode principale modifiée est le bean oidcUserService() définie
dans le fichier [Link], qui personnalise la conversion
du token utilisateur OIDC. Cette méthode procède en plusieurs étapes :
– Elle charge l’utilisateur à partir du token OIDC via un service délégué
standard.
– Elle extrait les rôles (Authorities) définis dans les claims du token en
parcourant les autorités OIDC.
– Grâce aux modifications injectées par le blueprint. elle enrichit ensuite
ces rôles avec les permissions dynamiques associées en appelant la mé-
thode addPermissionsToAuthorities(). Celle-ci appele la methode
getPermissionsForAuthorities qui interroge de manière réactive la
base de données afin de récupérer les permissions liées aux rôles via
des relations Authority-Permission.

40
 – La hiérarchie des rôles est appliquée pour prendre en compte les héri-
tages et étendre les droits de l’utilisateur.
– Un nouvel objet DefaultOidcUser est ensuite généré avec l’ensemble
des autorités complétées, garantissant que le SecurityContext dispose
de toutes les permissions nécessaires.
1 @Bean
2 public ReactiveOAuth2UserService < OidcUserRequest , OidcUser >
oidcUserService ( RoleHierarchy roleHierarchy ) {
3 final OidcReactiveOAuth2UserService delegate = new
OidcReactiveOAuth2UserService ();
4
5 return userRequest -> {
6 return delegate
7 . loadUser ( userRequest )
8 . flatMap (user -> {
9 Set < GrantedAuthority > baseAuthorities = new HashSet < >();
10 // Extraction des rôles ( authorities ) présents dans les
claims du token OIDC
11 user. getAuthorities (). forEach ( authority -> {
12 if ( authority instanceof OidcUserAuthority oidcAuth ) {
13 baseAuthorities . addAll (
14 SecurityUtils
15 . extractAuthorityFromClaims (
16 oidcAuth . getUserInfo (). getClaims ()));
17 }
18 });
19 // Ajout asynchrone des permissions associées aux rôles extraits
20 return addPermissionsToAuthorities ( baseAuthorities ).
21 map( grantedAuthorities -> {
22 Collection <? extends GrantedAuthority >
allAuthoritiesWithHierarchy = roleHierarchy .
23 getReachableGrantedAuthorities ( grantedAuthorities );
24 return new DefaultOidcUser (
25 new HashSet <>( allAuthoritiesWithHierarchy ),
26 user. getIdToken () ,
27 user. getUserInfo () ,
28 PREFERRED_USERNAME
29 );
30 });
31 });
32 };
33 }
Listing 4.4: Intégration des permissions coté gateway
En complément de cette méthode principale Listing 4.4 que nous avons
modifiée, elle fait également appel à d’autres méthodes, développées
et intégrées via le blueprint, qui sont :
∗ addPermissionsToAuthorities(Collection<GrantedAuthority>

41
 authorities) : Cette méthode prend la collection initiale des rôles
(Authorities) extraits du token et, de manière réactive, récupère
toutes les permissions associées à ces rôles. Elle fusionne ensuite ces
permissions aux rôles existants pour produire une collection enrichie
qui sera utilisée dans le contexte de sécurité.
∗ getPermissionsForAuthorities(Set<String> authorityNames) :
Cette méthode interroge de façon asynchrone la base de données
pour chaque rôle (authority) reçu, via la relation entre Authority
et Permission. Elle récupère l’ensemble des permissions associées à
ces rôles, élimine les doublons, et retourne un flux réactif des per-
missions. Cette méthode est appelée par addPermissionsToAutho-
rities() pour obtenir la liste précise des permissions à ajouter.
(b) Modification côté Microservice : Dans les microservices, l’authenti-
fication via JWT est gérée de manière synchrone. La fonction modifiée
est la méthode authenticationConverter() du fichier SpringConfigura-
[Link] , qui retourne un convertisseur de type Converter<Jwt, Abs-
tractAuthenticationToken>. Cette méthode réalise les opérations sui-
vantes :
– Elle utilise un convertisseur JWT standard (JwtAuthenticationCon-
verter) pour extraire les rôles de l’utilisateur à partir des claims du
token.
– Grâce aux modifications injectées par le blueprint. elle surcharge le
convertisseur d’autorités pour appeler la méthode addPermissions-
ToAuthorities(), laquelle enrichit la liste initiale des rôles par les
permissions correspondantes.
– La récupération des permissions s’effectue directement via le reposito-
ry PermissionRepository en interrogeant la base de données selon les
noms des rôles via la méthode getPermissionsForAuthorities.
Cet enrichissement des autorités est effectué avant la création du token
d’authentification Spring Security, ce qui garantit que le SecurityCon-
text est correctement alimenté.
1 Converter <Jwt , AbstractAuthenticationToken > authenticationConverter ()
{
2 JwtAuthenticationConverter jwtAuthenticationConverter = new
JwtAuthenticationConverter ();
3 jwtAuthenticationConverter . setJwtGrantedAuthoritiesConverter (
4 new Converter <Jwt , Collection < GrantedAuthority > >() {
5 @Override
6 public Collection < GrantedAuthority > convert (Jwt jwt) {
7 Collection < GrantedAuthority > authorities =
8 SecurityUtils .
9 extractAuthorityFromClaims (jwt. getClaims ());
10 // Enrichissement des autorités avec les permissions
associées
11 return addPermissionsToAuthorities ( authorities );
12 }

42
13 }
14 );
15 setPrincipalClaimName ( PREFERRED_USERNAME );
16 return jwtAuthenticationConverter ;
17 }
Listing 4.5: Intégration des permissions coté microservice

En plus de cette méthode présentée dans le Listing (4.5) que nous avons
modifiée et qui est la méthode principale, elle fait appel à d’autres mé-
thodes que nous avons développées et injectées par le blueprint, qui sont :
– addPermissionsToAuthorities(Collection<GrantedAuthority>
authorities) : Cette méthode est responsable d’enrichir dynamique-
ment les rôles extraits du token JWT. Elle prend en entrée la collection
des autorités (rôles) initialement fournies par le convertisseur JWT,
puis identifie les permissions associées à ces rôles. Après avoir récupéré
ces permissions, elle les convertit en objets de type GrantedAuthority
et les ajoute à la collection existante. Cette liste enrichie, composée à
la fois des rôles et des permissions, est ensuite utilisée pour construire
le SecurityContext de Spring Security, assurant une gestion plus fine
des droits.
– getPermissionsForAuthorities(Set<String> authorityNames) :
Cette méthode est appelée en interne par la précédente. Elle interroge
la base de données à partir des noms de rôles reçus, en s’appuyant sur
la relation définie entre les entités Authority et Permission. Son objec-
tif est de retourner toutes les permissions liées à ces rôles sous forme
d’un ensemble unique, sans doublons. Ces permissions sont ensuite
exploitées pour alimenter la collection finale des autorités, intégrant
ainsi les droits granulaires nécessaires à la sécurisation des endpoints
ou de l’interface utilisateur.
Cette solution permet de combiner efficacement les rôles et les permissions
lors de l’authentification, assurant ainsi une gestion fine et centralisée des
accès dans chaque microservice. Elle garantit que toutes les autorisations
nécessaires sont disponibles dès l’établissement du contexte de sécurité,
renforçant la fiabilité du mécanisme de contrôle d’accès.
(c) Modification côté Monolithique Dans les applications monolithique,
la modification principale se situe dans la méthode getUserFromAuthen-
tication() de la classe [Link]. Cette méthode réalise les opé-
rations suivantes :
– Elle récupère les rôles extraits du token d’authentification OAuth2 ou
JWT.
– Elle appelle la méthode getPermissionsByAuthorities(Set<String>
authorities) du service PermissionService, laquelle interroge la base
de données via le repository pour obtenir toutes les permissions asso-
ciées à ces rôles.
– Elle convertit ces permissions en objets GrantedAuthority de Spring

43
 Security, puis les ajoute à la collection initiale des rôles.
– Elle crée une nouvelle instance d’Authentication enrichie des rôles et
des permissions, et met à jour le SecurityContextHolder avec ce nouvel
objet. Cela permet à toute l’application d’accéder à un contexte de
sécurité qui intègre les rôles et les permissions, facilitant la gestion
fine des droits d’accès via les annotations @PreAuthorize et directives
Angular.

4.3.2 Objectif2 : Communication des permissions entre le Gateway et

les microservices
• Motivation :
Dans une architecture microservices avec un gateway centralisé, il est essentiel que ce
dernier soit capable de connaître les permissions exactes des utilisateurs sur chaque
microservice, afin d’adapter dynamiquement l’expérience utilisateur sur le frontend
et sécuriser les accès. Chaque microservice possède sa propre configuration de rôles
et permissions, rendant leur centralisation non triviale. Une solution manuelle serait
difficilement maintenable à grande échelle.
L’objectif est donc de permettre au gateway de :

– Découvrir dynamiquement les microservices disponibles.

– Interroger dynamiquement les différents microservices pour récupérer les per-
missions liées aux rôles de l’utilisateur.
– Consolider ces permissions au niveau du gateway afin de pouvoir les trans-
mettre par la suite aux micro-frontends des microservices.

• Approche choisie :
L’approche retenue repose sur les composants suivants :

– Consul pour la découverte des microservices.

– WebClient (Spring Reactive) pour effectuer des requêtes dynamiques vers les
API /api/permissions/Authorities de l’ensemble des microservices
– OAuth2/JWT pour sécuriser les appels avec le token d’authentification de
l’utilisateur.
– Agrégation des permissions dans le gateway, en fonction des rôles de l’utilisa-
teur.
Cette approche permet une communication automatique, sécurisée et scalable
entre le gateway et tous les microservices enregistrés.

• Automatisation réalisées via le blueprint : Afin de répondre aux exigences

de dynamique et de scalabilité de la gestion des permissions, le blueprint JHipster
développé automatise plusieurs étapes clés dans le gateway. Ces étapes permettent
de détecter les microservices, de les interroger et de consolider leurs permissions,
sans intervention manuelle.

44
 a) Génération automatique du service DynamicCallerService : Le blue-
print génére automatiquement au sein du gateway un service nommé Dynamic-
CallerService chargé de communiquer avec Consul pour identifier les microser-
vices en cours d’exécution. Ce service filtre les services inutiles, notamment le
gateway, et récupère les adresses réseau des microservices [Link] opéra-
tion est cruciale pour assurer que le gateway puisse détecter automatiquement
tous les microservices actifs, quelle que soit leur configuration ou leur quantité.
Ce service repose sur deux méthodes principales :
– La méthode getMicroservices() interroge Consul afin d’obtenir la liste
complète des services enregistrés, élimine ceux qui ne sont pas nécessaires,
puis pour chaque service filtré, elle fait appel à getServiceAddressesBy-
Name() pour récupérer leurs adresses réseau complètes (IP et port). Les
différentes adresses obtenues sont ensuite fusionnées en une liste unique et
exploitable.
– La méthode getServiceAddressesByName() joue un rôle crucial dans
la découverte dynamique des services auprès de Consul. Pour chaque ser-
vice interrogé, elle récupère les informations détaillées des différentes ins-
tances enregistrées, notamment leurs adresses IP et leurs ports. Ensuite,
elle traite ces données pour filtrer les adresses invalides ou incomplètes,
telles que les entrées vides ou par défaut, afin d’assurer la qualité des infor-
mations utilisées. Par ailleurs, elle élimine les doublons pour ne conserver
qu’un ensemble unique d’adresses réseau valides et exploitables. Cette mé-
thode permet ainsi de fournir une liste propre et fiable des points d’accès
à chaque microservice, facilitant la communication entre composants dans
une architecture distribuée.
1 public Mono <List <String >> getMicroservices () {
2 WebClient webClient =
webClientBuilder . baseUrl ("http :// localhost :8500 "). build ();
3 return webClient
4 .get ().uri("/v1/ catalog / services "). retrieve ()
5 . bodyToMono (new ParameterizedTypeReference <Map <String ,
Object >>() {})
6 . flatMap ( services -> {
7 List <String > microservices = services . keySet (). stream ()
8 . filter ( serviceName ->
! serviceName . equalsIgnoreCase (" gateway "))
9 . collect ( Collectors . toList ());
10 List <Mono <List <String >>> addressMonos = microservices
11 . stream ()
12 .map( serviceName ->
getServiceAddressesByName ( serviceName ))
13 . collect ( Collectors . toList ());
14 return [Link]( addressMonos , results -> {
15 List <String > allAddresses = new ArrayList < >();
16 for ( Object result : results ) {
17 allAddresses . addAll (( List <String >) result );

45
18 }
19 return allAddresses ;
20 });
21 });
22 }
Listing 4.6: Détection et agrégation des adresses des microservices
enregistrés dans Consul.

b) Génération automatique des méthodes de récupération des permis-

sions : Le fichier [Link], généré automatiquement par le blue-
print dans le module gateway, joue un rôle clé dans la gestion des droits d’ac-
cès à l’échelle de l’architecture microservices. Il assure la coordination entre les
composants d’authentification, les microservices et la passerelle pour permettre
une vue consolidée des permissions utilisateur. Trois méthodes principales y
sont intégrées :
– extractToken() : Cette méthode identifie le type de jeton d’authentifi-
cation en cours (JWT classique ou jeton issu d’un provider OAuth2) et
en extrait la valeur. Ce jeton est indispensable pour formuler des requêtes
sécurisées vers les microservices, en garantissant que l’utilisateur est bien
authentifié.
– getPermissionsFromMicroservice() : Elle a pour mission de contacter
dynamiquement chaque microservice enregistré dans Consul. Pour chacun
d’eux, elle envoie une requête au point d’accès /api/permissions/Authori-
ties, en y joignant la liste des rôles actuels de l’utilisateur. Les différentes
réponses sont collectées, interprétées, et fusionnées afin de construire une
liste unique et complète des permissions disponibles pour cet utilisateur
dans l’ensemble du système.
– parsePermissionsFromResponse() : Cette fonction utilitaire convertit
les données JSON retournées par les microservices en objets manipulables
(PermissionDTO). Elle permet d’en extraire facilement les noms de per-
missions, qui sont ensuite utilisés pour alimenter la logique d’autorisation
au sein de l’application.

1 public Mono <Set <String >> getPermissionsFromMicroservice ( String token ,

Set <String > authorities ) {
2 return dynamicCallerService . getMicroservices ()
3 . flatMapMany (Flux :: fromIterable )
4 . flatMap (url -> {
5 WebClient webClient = webClientBuilder . baseUrl ("http ://"
+ url). build ();
6 return webClient .post ()
7 .uri("/api/ permissions / Authorities ")
8 . header (" Authorization ", " Bearer " + token )
9 . bodyValue ( authorities )
10 . retrieve ()
11 . bodyToMono ( String . class )

46
12 . onErrorResume ( error -> {
13 System .err. println (" Erreur lors de l'appel à " +
url + ": " + error . getMessage ());
14 return Mono. empty ();
15 });
16 })
17 . collectList ()
18 . flatMap ( responses -> {
19 Set <String > allAuthorities = new HashSet < >();
20 for ( String response : responses ) {
21 Set < PermissionDTO > permissions =
parsePermissionsFromResponse ( response );
22 allAuthorities . addAll ( permissions . stream ()
23 .map( PermissionDTO :: getName )
24 . collect ( Collectors . toSet ()));
25 }
26 return [Link]( allAuthorities );
27 });
28 }
29 }
Listing 4.7: Méthode responsable de récupérer des permissions

4.3.3 Objectif 3 : Communication entre microservices

• Motivation : Dans une architecture microservices, la capacité pour un service à
communiquer efficacement avec un autre est essentielle au bon fonctionnement glo-
bal du système. Cette communication doit être sécurisée, transparente et compatible
avec les mécanismes d’authentification en place, notamment dans un environnement
basé sur Keycloak et OAuth2. L’objectif ici est de permettre à un microservice d’en-
voyer ou de recevoir des données depuis un autre microservice, sans compromettre
la sécurité ni nécessiter d’interventions manuelles.

• Approche choisie :
L’approche adoptée repose sur la configuration automatique des clients Feign, uti-
lisés dans les microservices pour effectuer des appels HTTP vers d’autres services.
Ces clients doivent être capables d’inclure un jeton d’accès valide dans chaque re-
quête sortante, généré à partir des informations de configuration Keycloak déjà
disponibles dans l’environnement JHipster. De plus, il est nécessaire que le gateway
puisse reconnaître ce jeton pour autoriser ces appels. Pour cela, une configuration
complémentaire est injectée dans le fichier [Link], afin de définir le scope
adéquat pour les communications internes.

• Automatisatios réalisées par le Blueprint :

a) Modification automatqiue du fichier Feign Client : Le blueprint prend

en charge l’ensemble de la configuration nécessaire au sein de chaque microser-
vice. Il génère automatiquement une classe de configuration Feign contenant

47
 les paramètres requis pour l’obtention d’un jeton OAuth2 à l’aide du mé-
canisme client-credentials. Cette classe analyse la propriété issuer-uri afin
d’en déduire dynamiquement l’URL du serveur d’authentification Keycloak
ainsi que le nom du realm, puis construit l’URL d’accès au point d’émission
de [Link] fois la configuration établie, une requête d’authentification est
initiée via WebClient afin de récupérer un jeton d’accès. Le mécanisme repose
sur l’utilisation de WebClient pour initier une demande d’authentification, à
l’issue de laquelle un jeton d’accès est obtenu. Ce jeton est ensuite automati-
quement attaché aux en-têtes des requêtes émises via Feign, par le biais d’un
intercepteur dédié, garantissant ainsi l’envoi sécurisé des appels interservices
sans intervention manuelle.
b) Modification du fichier jhipster-realm En complément, le blueprint mo-
difie automatiquement le fichier [Link] du gateway pour y ajouter
le scope jhipster aux defaultClientScopes du client interne. Cette modifica-
tion garantit que les jetons générés contiennent bien les droits nécessaires à
l’authentification des appels interservices via la passerelle, assurant ainsi une
communication centralisée, sécurisée et cohérente à travers l’ensemble de l’éco-
système microservices.

Conclusion
Ce chapitre a permis d’établir les fondements nécessaires à la compréhension du blue-
print que nous avons conçu, en mettant en évidence les limites des mécanismes standards
proposés par JHipster pour la gestion des rôles et des permissions. Grâce à une démarche
progressive, nous avons présenté en détail les principales améliorations apportées côté ba-
ckend, dans le but d’offrir une gestion des accès plus granulaire, dynamique et sécurisée.

48
Chapitre 5

Réalisation du blueprint coté

frontend et Maintenance

Introduction
Dans la continuité des optimisations réalisées côté backend, ce chapitre se concentre
sur les configurations automatisées par le blueprint au niveau du frontend. L’objectif est
d’assurer une correspondance rigoureuse entre les rôles, les permissions et les éléments
de l’interface utilisateur, tout en garantissant une expérience fluide, sécurisée et adaptée
aux droits de chaque utilisateur. Nous détaillons les fichiers Angular générés ou modifiés
automatiquement, ainsi que la logique conditionnelle mise en place pour adapter dynami-
quement l’affichage en fonction des permissions attribuées. Ce chapitre met également en
lumière les actions de maintenance appliquées à la gestion de la confidentialité, automa-
tisées par le blueprint, dans le but d’améliorer les performances globales des applications
générées.

5.1 Les actions du blueprint sur le frontend des applications JHips-

ter
Le graphe présenté ci-dessus illustre les différentes actions effectuées par le blueprint
sur la partie frontend des applications JHipster, qu’il s’agisse d’une architecture monoli-
thique, microservices ou gateway.

49
 Fig. 5.1 : carte mentale : action du blueprint sur frontend des applications JHipster

• Les fichiers générés : sont un ensemble de templates que nous avons créés au sein
du blueprint. Ils permettent la génération automatique des fichiers dans l’applica-
tion, en s’adaptant au type d’architecture (monolithique, microservices, gateway).

• Les fichiers modifiés : sont ceux déjà présents dans la structure standard de
JHipster. Grâce à des fonctions JavaScript spécifiques développées dans le blueprint,
ces fichiers sont automatiquement mis à jour pour intégrer les éléments de sécurité
nécessaires, sans intervention manuelle sur le code source.

Fichiers générés communs à toutes les architectures

• constant

– [Link] : Ce fichier centralise la hiérarchie des permis-

sions pour chaque entité métier. Il permet à l’interface de vérifier si un uti-
lisateur dispose d’une permission suffisante pour réaliser une action, même
s’il ne possède pas précisément la permission attendue, en s’appuyant sur la
hiérarchie définie.
– [Link] : Généré pour chaque entité, ce fichier contient la liste
exhaustive des permissions spécifiques à l’entité. Ces données sont utilisées
dans les composants et services Angular pour conditionner l’affichage et les
fonctionnalités selon les droits de l’utilisateur.

• route

– [Link] : Ce fichier déclare les routes du fron-

tend permettant d’administrer les permissions. Ces pages sont généralement
accessibles uniquement aux administrateurs du système.

• component :

50
 – [Link] [Link]
Composant Angular dynamique utilisé pour sélectionner les permissions à at-
tribuer à un rôle. Il intervient dans les interfaces de création et modification
des rôles.

• service

– [Link] Service Angular qui communique avec le ba-

ckend pour récupérer les permissions disponibles par entité, assurant la cohé-
rence entre frontend et backend.

• model

– [Link] : Modèle TypeScript définissant la structure d’une per-

mission, utilisé pour typer les objets manipulés dans les composants.

Fichiers générés spécifiques aux microservices

• component

– [Link]
– [Link] Interface complète pour gérer les rôles
locaux d’un microservice, et leur association avec des permissions spécifiques
à ce microservice.

• route

– [Link] Route Angular permettant d’accéder à l’inter-

face de gestion des rôles dans le microservice.

Fichiers modifiés automatiquement par le blueprint :

• route :

– [Link] Les routes Angular relatives aux entités sont enrichies

avec une propriété data : authorities : [...] , définissant les permissions néces-
saires pour accéder à chaque route.

• component

– [Link] L’affichage
des boutons d’action (édition, suppression, etc.) est conditionné par les per-
missions de l’utilisateur grâce à la directive personnalisée hasAnyAuthority.

• service d’authentification

– [Link] Ce service est modifié pour intégrer la hiérarchie des per-

missions définie dans [Link]. Il permet de vérifier si un uti-
lisateur possède une permission spécifique ou une permission supérieure dans
la hiérarchie.

51
 • module partagés

– [Link] Le module partagé déclare la directive HasAnyAuthority-

Directive, indispensable pour afficher ou masquer dynamiquement des éléments
UI selon les permissions de l’utilisateur.

Fichiers modifiés Spécifique au gateway et au monolithique

• route

– [Link] Fichier modifié pour intégrer la gestion des rôles propres

aux architectures monolithique et gateway.

• component

– [Link] modifier pour la gestion des role (Authority) liés

au gateway
– [Link] L’interface du gateway
est enrichie avec des liens et boutons permettant l’accès à la gestion centralisée
des rôles et permissions pour chaque microservice, via des appels dynamiques
au backend.

5.2 Automatisation de la gestion de la confidentialité apportée

coté frontend

5.2.1 Objectif1 : Personnaliser les interfaces utilisateur selon les per-

missions
• Motivation :
Dans les applications générées avec JHipster, la simple protection des endpoints
backend ne suffit pas à garantir une sécurité complète. Il est essentiel de restreindre
également l’interface utilisateur (UI) en fonction des permissions accordées à chaque
utilisateur. Cette approche vise plusieurs objectifs :

– Empêcher l’accès visuel à des fonctionnalités non autorisées (boutons de sup-

pression, liens de navigation, pages de création, etc.), même en cas de tentative
d’accès direct via l’URL.
– Améliorer l’expérience utilisateur en affichant uniquement les actions dispo-
nibles pour chaque profil, évitant ainsi toute confusion ou frustration.
– Assurer une cohérence frontend/backend, avec des règles de contrôle d’accès
alignées.

Or, le mécanisme standard de JHipster repose uniquement sur des rôles globaux
(Authorities), ce qui limite la granularité des permissions.

• Approche choisie :
Le blueprint jhipster que nous avons développé propose une approche automatisée et
granulaire de la personnalisation des interfaces Angular, en fonction des permissions
propres à chaque [Link] repose sur :

52
 – La génération automatisée de fichiers TypeScript dédiés à la centralisation des
rôles et des permissions ;
– L’adaptation des services Angular afin d’y intégrer une logique de hiérarchie
des permissions, permettant une gestion étendue des autorisations ;
– L’injection dynamique de directives dans les fichiers HTML, pour contrôler
l’affichage des composants selon les droits de l’utilisateur ;
– La sécurisation contextuelle des routes Angular, assurant une restriction fine
de l’accès aux pages en fonction des permissions.

• Automatisations réalisées via le blueprint :

a) Génération de [Link] : Pour chaque entité métier , un

fichier TypeScript est généré automatiquement. Ce fichier expose une énumé-
ration typée et centralisée des permissions associées à l’entité, avec un poids
hiérarchique permettant d’établir des relations d’héritage
b) Génération de rô[Link] : Le fichier rô[Link] illus-
trée dans le Listing 5.1 regroupe, pour chaque entité fonctionnelle, les constantes
représentant les permissions disponibles dans l’application, facilitant ainsi leur
intégration dans le frontend. Ce fichier est élaboré automatiquement en ana-
lysant les fichiers *.[Link] associés à chaque entité, lesquels décrivent de
manière centralisée les différentes permissions utilisables côté frontend, tout
en leur attribuant un niveau hiérarchique (poids). À chaque création d’une
nouvelle entité, ce fichier est automatiquement mis à jour, garantissant une
cohérence continue entre la structure métier et les règles de contrôle d’accès.
Son contenu est essentiel pour permettre le traitement dynamique des autori-
sations dans les services frontend, notamment dans le fichier [Link].
1 import { ROLE_MODEL } from
'../ entities / microservices2 / model / model . authority ';
2 import { ROLE_PRODUIT } from
'../ entities / microservices2 / produit / produit . authority ';
3 export const ROLE_WEIGHT : Record <string , object > = {
4 MODEL: ROLE_MODEL ,
5 PRODUIT : ROLE_PRODUIT ,
6 };

Listing 5.1: Exemple [Link]

c) Extension de [Link](Listing 5.2) : logique d’héritage de

permissions Dans le cadre de l’intégration d’un modèle RBAC enrichi, le
fichier [Link] a été étendu afin de prendre en charge la hiérarchie des
rôles et des permissions. Cette extension permet de garantir que les utilisateurs
ayant des permissions supérieurs bénéficient automatiquement des privilèges
associés à des permissions inférieurs, conformément à une logique d’héritage
définie. Trois méthodes ont été injectées dans [Link] :
– getAuthoritiesWithHierarchy() : Cette méthode lance le processus de
constitution complète des droits de l’utilisateur en combinant deux sources
d’autorisations :

53
 ∗ Les autorités fournies directement par le backend via le ga-
teway, qui comprennent à la fois :
· les rôles classiques (comme ROLE-ADMIN, ROLE-USER),
· les permissions spécifiques, ajoutées dynamiquement grâce aux ser-
vices UserService et PermissionService.
∗ Les autorisations complémentaires calculées localement dans
le frontend, basées sur une hiérarchie des permissions. Cette hié-
rarchie permet d’étendre automatiquement les droits de l’utilisateur
en lui attribuant aussi les permissions inférieures associées, selon un
principe d’héritage.
– getExpandedAuthorities() Cette méthode applique la logique d’héri-
tage hiérarchique. Elle s’appuie sur un fichier de configuration(role-hierarchy-
[Link]) dans lequel chaque permission est associée à une valeur nu-
mérique représentant son niveau d’autorité.
Fonctionnement :
∗ Une permission avec une valeur élevée est considérée comme plus puis-
sante.
∗ Lorsqu’un utilisateur détient une permission donnée, toutes celles de
niveau inférieur ou équivalent lui sont automatiquement attribuées.
Ce mécanisme assure une cohérence fonctionnelle : il serait illogique qu’un
utilisateur ait le droit de supprimer une entité sans pouvoir la consulter.
– hasAnyAuthority()(authorities : string[] | string) : La méthode ha-
sAnyAuthority() a été réécrite afin de tirer parti de la logique d’autorités
enrichies. Plutôt que de se baser uniquement sur les autorités renvoyées
par le backend, elle utilise désormais la liste complète construite par ge-
tAuthoritiesWithHierarchy(), intégrant à la fois les permissions explicites
et celles obtenues par héritage. Elle permet de déterminer de manière
fiable si un utilisateur possède une autorité ou une permission, qu’elle soit
directement attribuée ou héritée, afin de gérer dynamiquement l’accès à
certaines fonctionnalités ou éléments de l’interface Angular (notamment
via la directive hasAnyAuthority)
1 hasAnyAuthority ( authorities : string [] | string ): boolean {
2 const userIdentity = this. userIdentity ();
3 if (! userIdentity ) {
4 return false ;}
5 const expandedAuthorities = this. getAuthoritiesWithHierarchy ();
6 if (! Array. isArray ( authorities )) {
7 authorities = [ authorities ]; }
8 return authorities .some( required =>
expandedAuthorities .has( required ));}
9 getExpandedAuthorities ( authorities : string []): Set <string > {
10 const allAuthorities = new Set <string >();
11 const isAdmin = authorities . includes ('ROLE_ADMIN ');
12 if ( isAdmin ) {
13 Object . values ( ROLE_WEIGHT ). forEach ( enumRole => {

54
14 Object .keys( enumRole ). forEach (role => allAuthorities .add(role));
15 });
16 allAuthorities .add('ROLE_ADMIN ');
17 return allAuthorities ;
18 }
19 authorities . forEach ( userRole => {
20 const parts = userRole . split ('_');
21 if (parts. length >= 3) {
22 const entity = parts [1];
23 const enumRole = ROLE_WEIGHT [ entity ];
24 if ( enumRole ) {
25 const currentWeight = ( enumRole as Record <string ,
number >)[ userRole ] ?? 0;
26 Object . entries ( enumRole as Record <string ,
number >). forEach (([ role , weight ]) => {
27 if ( currentWeight >= weight ) {
28 allAuthorities .add(role);
29 }
30 });
31 }
32 }
33 });
34 return allAuthorities ;
35 }
36 getAuthoritiesWithHierarchy (): Set <string > {
37 const account = this. userIdentity ();
38 if (! account || ! account . authorities ) {
39 return new Set ();
40 }
41 return this. getExpandedAuthorities ( account . authorities );
42 }
Listing 5.2: les Modifications effectuées sur le fichier
[Link]

d) UserService : point central d’enrichissement des autorités utilisateur

pour le frontend Dans les applications JHipster, qu’elles soient basées sur une
architecture microservices ou monolithique, le frontend s’appuie sur l’endpoint
/api/account pour récupérer les informations de l’utilisateur connecté. Ce point
d’entrée unique fournit non seulement les données d’identité, mais également
l’ensemble des rôles (Authorities) et permissions associées, nécessaires à la
personnalisation dynamique de l’interface
a) Cas d’architecture microservice : Dans cette architecture microser-
vices, l’ensemble des micro-frontends qu’ils appartiennent au gateway ou
aux microservices, s’appuient sur le gateway pour obtenir les informations
de l’utilisateur via l’API GET /api/account . Cette route est le point
d’entrée unique permettant aux clients frontend de récupérer le profil de
l’utilisateur connecté, incluant ses rôles et droits d’accès. Il est donc es-

55
 sentiel que cette méthode fournisse des données enrichies et cohérentes.
Pour cette raison, la méthode getUserFromAuthentication() du fichier
[Link] a été redéfinie comme illustrée dans le Listing 5.3 auto-
matiquement au niveau du gateway. Elle constitue la base du traitement
de l’appel /api/account, et son adaptation permet d’ajouter dynamique-
ment les permissions aux autorités utilisateur classiques. Cela garantit que
toutes les interfaces frontend disposent d’une vision complète et actualisée
des droits de l’utilisateur, sans avoir à effectuer des requêtes supplémen-
taires vers d’autres services.
1
2 @Transactional
3 public Mono < AdminUserDTO >
getUserFromAuthentication ( AbstractAuthenticationToken authToken ) {
4 Map <String , Object > attributes ;
5 if ( authToken instanceof OAuth2AuthenticationToken ) {
6 attributes = (( OAuth2AuthenticationToken )
authToken ). getPrincipal (). getAttributes ();
7 } else if ( authToken instanceof JwtAuthenticationToken ) {
8 attributes = (( JwtAuthenticationToken )
authToken ). getTokenAttributes ();
9 } else {
10 throw new IllegalArgumentException (" AuthenticationToken is
not OAuth2 or JWT!");
11 }
12 User user = getUser ( attributes );
13 extrayant du token
14 user. setAuthorities (
15 authToken
16 . getAuthorities ()
17 . stream ()
18 .map( GrantedAuthority :: getAuthority )
19 .map( authority -> {
20 Authority auth = new Authority ();
21 auth. setName ( authority );
22 return auth;
23 })
24 . collect ( Collectors . toSet ())
25 );
26 return syncUserWithIdP ( attributes , user)
27 . flatMap (u -> {
28 AdminUserDTO adminUserDTO = new AdminUserDTO (u);
29 return permissionService . extractToken ( authToken )
30 . flatMap ( token ->
31 permissionService
32 . getPermissionsFromMicroservice (token ,
u. getAuthorities (). stream ()
33 .map( Authority :: getName )
34 . collect ( Collectors . toSet ()))

56
 35 . flatMap ( permissions -> {
36 adminUserDTO . getAuthorities ()
37 . addAll ( permissions );
38 return [Link]( adminUserDTO );
39 })
40 permissions , affiche un message et retourne le
DTO sans permissions additionnelles
41 . onErrorResume (e -> {
42 System .out. println (" Error fetching
permissions for user " + u. getEmail () + ":
" + e. getMessage ());
43 return [Link]( adminUserDTO );
44 })
45 );
46 });
47 }
Listing 5.3: Modification appliquée par le blueprint sur [Link]
du gateway

b) Cas d’architecture monolithique Dans le cas d’un monolithe, le prin-

cipe est similaire, à la différence près que le frontend interroge directement
le backend local. Le blueprint applique donc une logique équivalente dans
le UserService du monolithe pour assurer une cohérence totale.
e) Extension de [Link] : La directive HasAnyAuthorityDirec-
tive est déclarée et exportée dans [Link], ce qui la rend accessible
dans l’ensemble de l’application. Cela permet de l’utiliser efficacement lors de
la personnalisation automatique des interfaces, notamment pour afficher ou
masquer des éléments en fonction des permissions utilisateur.
f) Injection automatique de la directive *jhiHasAnyAuthority dans les
templates HTML : Les éléments visuels sont protégés via la directive native
de JHipster

Avant le Bluepirnt :

Dans le listing 5.4, le bouton n’est pas protégé par une directive de contrôle
d’accès ; par conséquent, il est visible par tous les utilisateurs, quels que soient
leurs rôles ou permissions.
1 <a
2 [ routerLink ]="['/ microservices2 /model ', model .id , 'edit ']"
3 class ="btn btn - primary btn -sm"
4 data -cy=" entityEditButton ">
5 <span class ="d-none d-md - inline "
jhiTranslate =" entity . action .edit">Edit </ span >
6 </a>
Listing 5.4: Exemple d'un élément d'action avant l'application du
blueprint

57
 Après le Bluepirnt :

Le listing 5.5 montre le bouton est sécurisé par la directive JhiHasAnyAu-

thority conditionnelle qui empêche son affichage aux utilisateurs ne disposant
pas de la permission appropriée
1 <a
2 * jhiHasAnyAuthorityOnMicroservices2 ="'ROLE_MODEL_UPDATE '"
3 [ routerLink ]="['/ microservices2 /model ', model .id , 'edit ']"
4 class ="btn btn - primary btn -sm"
5 data -cy=" entityEditButton ">
6 <span class ="d-none d-md - inline "
jhiTranslate =" entity . action .edit">Edit </ span >
7 </a>
Listing 5.5: Exemple des éléments d'action après l'application du
blueprint

Grâce à la version modifiée d’[Link], cette directive :

– Tient compte des rôles hérités
– Évite toute duplication de logique dans les composants Angular
– Permet une visualisation contextuelle des éléments autorisés
g) Sécurisation automatique des fichiers *.[Link] : Pour chaque entité
métier, le fichier *.[Link] est enrichis automatiquement par l’ajout de la
propriété [Link] dans les définitions de routes. Cette propriété précise
les permissions requises pour accéder à chaque page, en s’appuyant sur les
autorisations spécifiques à l’entité.

avant le Bluepirnt :

Le listing 5.6 montre que la route n’est protégée que par une authentification
générale, sans filtrage par permission, ce qui la rend accessible à tout utilisateur
connecté.
1 {
2 path: ':id/view ',
3 loadComponent : () =>
import ('./ detail /model - detail . component ').then(m =>
m. ModelDetailComponent ),
4 },

Listing 5.6: Exemple de déclaration de route avant enrichissement par le

blueprint

Après le Bluepirnt

: Le listing 5.7 montre que la route est désormais sécurisée par une vérification
explicite des permissions via l’attribut authorities, ce qui garantit que seuls les
utilisateurs disposant de la permission convenable peuvent y accéder.

58
1 {
2 path: ':id/view ',
3 data: { authorities : [ ROLE_MODEL [ ROLE_MODEL . ROLE_MODEL_READ ]] },
4 loadComponent : () =>
import ('./ detail /model - detail . component ').then(m =>
m. ModelDetailComponent ),
5 },

Listing 5.7: Exemple de déclaration de route après l'application du

blueprint

la modification affectuée permet de conditionner l’accès aux différentes vues de l’application

selon les droits définis pour chaque entité. Le service UserRouteAccessService s’appuie en-
suite sur la méthode personnalisée hasAnyAuthority() pour vérifier si l’utilisateur dispose des
permissions explicites ou héritées via la hiérarchie, assurant ainsi une sécurité cohérente côté
navigation.

5.2.2 objectif 2 : Génération d’interface pour gestion des authorités

• Motivation :
Lorsqu’on utilise JHipster et Keycloak pour sécuriser une architecture basée sur
des microservices, chaque service a la possibilité de gérer ses propres rôles et droits
d’accès. Néanmoins, l’interface de gestion des rôles intégrée par défaut dans JHipster
est uniquement disponible au niveau du gateway, ce qui limite la visibilité et la
gestion des rôles propres à chaque microservice. Afin de couvrir ce besoin, il a fallu
mettre en place les éléments suivants :

– Une interface dédiée à chaque microservice permettant d’afficher ses propres

rôles ;
– Une navigation centralisée depuis le gateway pour accéder facilement à ces
interfaces ;
– Une solution automatisée et homogène pour ne pas avoir à développer manuel-
lement chaque interface dans chaque service

• Approche choisie :

– Cas de gestion des rôles propres au microservice : Nous avons capitalisé

sur l’interface déjà existante dans le frontend du gateway, qui liste l’ensemble
des microservices enregistrés. Le blueprint vient enrichir cette interface en :
∗ Ajoutant un bouton Update devant chaque microservice.
∗ Permettant, via ce bouton, de rediriger l’utilisateur vers une interface dé-
diée dans le frontend du microservice sélectionné.
∗ Cette interface permet d’afficher les rôles configurés spécifiquement au sein
du microservice concerné.
Ainsi, tout en conservant un point d’entrée unique (le gateway), chaque mi-
croservice reste autonome pour la gestion de ses propres rôles.

59
 – Cas de gestion des roles propre au gateway et les architectures mo-
nolithique : Concernant la gestion des rôles au sein du gateway ainsi que dans
l’architecture monolithique, aucune génération de fichiers supplémentaires n’a
été nécessaire. En effet, JHipster fournit déjà une interface d’administration
des rôles complète et fonctionnelle via l’écran standard lié à l’entité Authority.
Toutefois, deux modifications ciblées ont été apportées afin d’intégrer l’inter-
face de gestion des permissions par rôle :
∗ Le fichier [Link] a été modifié pour ajouter un bou-
ton en face de chaque rôle, permettant d’accéder à l’interface de gestion
des permissions associées à ce rôle.
∗ Le fichier [Link] a été enrichi par l’ajout d’une route pointant
vers cette nouvelle interface.
• Automatisations réalisées par le blueprint Le blueprint développé permet
d’automatiser la création des composants indispensables à la gestion des rôles propre
à chaque microservice , aussi bien côté gateway que sur les microservices.

– Frontend du gateway Un bouton « Mise à jour » est automatiquement

ajouté dans l’interface [Link] pour chaque microservice listé,
facilitant ainsi l’accès direct à la gestion des rôles spécifiques à ce microservice.
La navigation vers l’interface du microservice ciblé est configurée de manière
fluide, assurant une intégration cohérente avec le microfrontend principal du
gateway.
– Microservice ciblé Plusieurs fichiers clés sont générés automatiquement
pour gérer les rôles en frontend :
∗ [Link] : ce fichier contient le modèle HTML
du composant Angular chargé d’afficher la liste des rôles. Chaque rôle est
présenté avec un bouton « Associer » qui redirige vers la gestion des
permissions associées.
∗ [Link] : la logique TypeScript de ce compo-
sant Angular s’occupe de récupérer via le service RoleService la liste des
rôles depuis le backend et de la stocker pour affichage. Le chargement des
données se fait automatiquement lors de l’initialisation du composant.
∗ [Link] : ce service gère la communication avec le backend. Il
expose la méthode getAuthorities() qui interroge l’API REST /api/au-
thorities/front afin d’obtenir la liste des rôles disponibles.
∗ [Link] définit la route Angular pour accéder au
composant RoleManagementComponent. Cette route est sécurisée par un
service de garde (UserRouteAccessService) qui restreint l’accès unique-
ment aux utilisateurs disposant du rôle ROLE-ADMIN. De plus, le titre
de la page est configuré dans cette même définition de route. la route
Angular associée est automatiquement insérée dans le module de routage
[Link], ce qui rend l’interface accessible depuis le gateway. Par
ailleurs, le blueprint génère également un contrôleur backend Authority-
Resource qui fournit l’endpoint REST /api/authorities/front servant à
retourner la liste des rôles stockés en base de données.

60
 – Points à noter :
∗ La personnalisation de l’apparence et du design de l’interface utilisateur
n’est pas prise en charge par le blueprint. Cette tâche reste sous la respon-
sabilité du développeur, qui adapte l’interface aux besoins et à la charte
graphique du projet.

5.2.3 Objectif3 : Génération d’interface pour gestion des permissions

• Motivation :
Afin de simplifier et d’optimiser la gestion granulaire des droits d’accès dans l’ap-
plication, il est essentiel de fournir une interface dédiée à l’administration des per-
missions. Cette interface a pour objectif de permettre aux administrateurs système
d’assigner ou de retirer dynamiquement des permissions spécifiques à chaque rôle
sans avoir à intervenir directement dans la base de données ou dans les fichiers de
configuration backend.

• Automatisation réalisées par le blueprint : Le blueprint facilite la généra-

tion complète et automatique des composants frontend et backend nécessaires à la
gestion des permissions, en produisant les mêmes composants pour le gateway et
chaque microservice dans une architecture microservices, ainsi que pour l’applica-
tion monolithique. Cette approche garantit une solution homogène, cohérente et
facilement maintenable, quel que soit le type d’architecture déployée.

– Frontend :
∗ [Link] : Ce fichier, produit au-
tomatiquement, fournit le modèle HTML qui permet de visualiser et de
modifier les permissions liées à chaque rôle, offrant ainsi une interface uti-
lisateur claire et facile à utiliser.
∗ [Link] : Ce fichier est automatique-
ment créé pour gérer la logique Angular du composant, incluant la récu-
pération des permissions depuis le backend ainsi que la gestion des modi-
fications utilisateurs.
∗ [Link] : Ce service Angular, généré par
le blueprint, gère la communication avec les endpoints REST du backend,
facilitant l’échange des données liées aux permissions.
∗ [Link] : Ce fichier, généré automatique-
ment, configure la route Angular sécurisée permettant d’accéder au com-
posant de gestion des permissions.
∗ L’injection de cette route est automatisée dans le fichier global enti-
[Link] (microservices) ainsi que la mise à jour correspondante du
routing dans [Link] (gateway et monolithique), assurant une
intégration fluide et transparente dans l’architecture frontend existante.
– Backend :
La classe RolePermissionResource est créée automatiquement par le blueprint,
exposant les endpoints REST dédiés à l’assignation et à la désassignation des
permissions aux rôles.

61
5.3 Maintenance évolutive

5.3.1 Dépendance au gateway : seulement pour l’architecture micro-

service
• Problème identifié
Dans notre architecture microservices basée sur JHipster, les micro-frontends des
différents services accèdent aux informations de l’utilisateur et à ses permissions
par l’intermédiaire de la passerelle. Le blueprint met en place automatiquement une
configuration permettant à cette dernière de détecter dynamiquement l’ensemble
des microservices, de contacter chacun d’eux pour récupérer les permissions liées à
l’utilisateur actuellement connecté, puis de transmettre ces informations aux micro-
frontends concernés.
Bien que cette automatisation fonctionne correctement et garantisse la cohérence
des données, elle devient de moins en moins performante à mesure que le nombre
de microservices augmente de façon exponentielle. En effet, la multiplication des
appels entre le gateway et les microservices provoque une latence significative, ce
qui dégrade la réactivité globale de l’application

• Solution mise en place :

Pour remédier à cette problématique, une nouvelle approche a été implémentée via
le blueprint. Elle vise à rendre chaque micro-frontend totalement autonome dans la
gestion des informations utilisateur, en supprimant la dépendance au gateway. Voici
les composants générés automatiquement dans ce cadre :

– [Link] : Ce contrôleur REST, généré automatiquement dans

chaque microservice, permet de fournir localement les informations relatives à
l’utilisateur connecté. Contrairement à l’approche classique où ces données
étaient centralisées au niveau du gateway, AccountResource expose un end-
point /api/account spécifique au microservice, qui retourne un objet enrichi
de type AdminUserDTO. Ce dernier contient les informations personnelles de
l’utilisateur, ses rôles, ainsi que l’ensemble de ses permissions. Cette approche
permet à chaque micro-frontend de fonctionner de manière autonome, sans dé-
pendre d’un appel au gateway, ce qui améliore la performance et renforce la
modularité de l’architecture.
– getUserFromAuthentication() dans [Link] Cette méthode, ré-
écrite et enrichie dans le cadre du blueprint, joue un rôle central dans la logique
de sécurité du microservice. Elle extrait l’ensemble des données nécessaires à la
construction complète du profil utilisateur. À partir du token d’authentification
(JWT ou OAuth2), la méthode récupère les rôles de l’utilisateur, synchronise
ses informations avec l’IdP (Identity Provider), puis interroge la base de don-
nées pour obtenir les entités Authority correspondantes. Elle effectue ensuite
une recherche dans la table de liaison permission-authority afin de regrouper
toutes les permissions associées à ces rôles. Le tout est encapsulé dans un objet
AdminUserDTO qui sera transmis au frontend via AccountResource. Cette
réécriture garantit que chaque micro-frontend dispose directement des données

62
 complètes nécessaires pour appliquer un contrôle d’accès fin et dynamique, sans
dépendance extérieure.
– *-[Link] : Ce fichier, que le blueprint génére automatiquement
pour chaque microservice, hérite d’un service [Link] généré grâce
à JHipster par défaut précédemment utilisé pour interroger un endpoint du
gateway. Dans cette nouvelle approche, il est redéfini pour interagir directement
avec le backend local du microservice. Son rôle est de récupérer les informations
de l’utilisateur connecté — telles que les données personnelles, les rôles et les
permissions — sans passer par le gateway. Cela permet une récupération plus
rapide et allège la charge réseau, tout en renforçant l’indépendance des micro-
frontends.
– *-[Link] Ce service, généré automatiquement, étend
le service standard [Link] et s’appuie sur le nouveau account-
[Link]. Il contrôle l’accès aux routes Angular du microservice en fonction
des permissions et rôles de l’utilisateur, garantissant une sécurisation fine et
adaptée des différentes vues et fonctionnalités.
– Directive Angular personnalisée : Une directive spécifique est générée
automatiquement pour chaque microservice et reliée au nouveau service user-
[Link]. Elle permet d’adapter dynamiquement l’affichage des
éléments de l’interface (comme les boutons ou actions) en fonction des per-
missions de l’utilisateur actuellement connecté. Cette directive garantit une
gestion fine des droits d’accès tout en offrant une interface utilisateur cohé-
rente et sécurisée.

• Avantages de cette approche

Cette nouvelle approche permet à chaque micro-frontend de fonctionner de ma-
nière indépendante, en accédant directement aux informations utilisateur depuis le
backend de son propre microservice. Cette autonomie :

– Élimine la dépendance au gateway,

– Réduit considérablement le nombre d’appels réseau,
– Améliore la performance globale du système.

De plus, cette architecture favorise une meilleure scalabilité. L’ajout de nouveaux

microservices n’impacte plus la performance, car chacun d’eux gère directement ses
propres données et permissions.

5.3.2 confusion entre Authority et Permission pour les deux architec-

tures
• Probleme identifié :
Dans une première version, nous avions choisi d’injecter dynamiquement les permis-
sions dans la liste des GrantedAuthority lors de l’authentification, ce qui permettait
d’utiliser les annotations classiques telles que : côté backend :
1 {
2 @PreAuthorize (" hasAnyAuthority (' PRODUIT_DELETE ')")

63
3 },

Listing 5.8: Annotation PreAuthorize avec HasAnyAuthority

côté frontend Angular :

1 *ngIf=" jhiHasAnyAuthority ([' ROLE_PRODUIT_DELETE '])"
Listing 5.9: Utilisation de la Directive hasAnyAuthority

Cependant, cette approche présentait plusieurs limites majeures :

– Mauvaise séparation conceptuelle entre rôles (ex. : ROLE-ADMIN) et permis-

sions métier, car ces dernières étaient directement stockées dans la même table
authority.
– Spring Security ne distinguait pas clairement les rôles des permissions, rendant
la gestion et la maintenance du contrôle d’accès complexes et peu claires.
– Bien qu’une hiérarchisation des permissions ait été mise en place, celle-ci restait
limitée par la conception qui fusionne les rôles et les permissions dans les
authorities, ce qui compliquait l’extension ou la contextualisation métier des
règles d’accès.

• Solutuion mise en place coté Backend :

Pour surmonter les contraintes constatées, nous avons choisi d’implémenter un Per-
missionEvaluator sur mesure, intégré grâce à notre blueprint JHipster.
Cette solution se traduit par plusieurs actions clés :

– Suppression de la configuration précédente dans [Link] qui

combinait directement les permissions avec les GrantedAuthority lors de l’au-
thentification, afin de clarifier et simplifier la gestion des droits.
– Génération automatique par le blueprint JHipster des classes et configurations
nécessaires pour gérer finement les permissions métier, notamment :
∗ La classe CustomPermissionEvaluator, est un bean Spring exposé sous
le nom customPermissionEvaluator illustrée dans le listing 5.10, conçu
pour gérer avec finesse les permissions métier au sein de l’application.
Contrairement à l’approche initiale qui mélangeait rôles et permissions
dans une même structure, ce composant offre une séparation claire, per-
mettant une gestion plus souple et compréhensible des droits d’accès.

Fonctionnement :
Lorsqu’un utilisateur authentifié tente d’accéder à une ressource ou d’exé-
cuter une action protégée, le CustomPermissionEvaluator intervient pour
vérifier s’il possède la permission nécessaire. Le processus suit plusieurs
étapes :
· Récupération des rôles : Le composant extrait les rôles attribués à
l’utilisateur depuis le contexte de sécurité.

64
 · Recherche des permissions associées : À partir de ces rôles, il interroge
la base de données pour récupérer toutes les permissions métier expli-
citement liées à ces rôles. Ces permissions sont souvent plus granulaires
et spécifiques que les simples rôles.
· Application de la hiérarchie métier des permissions : Afin de prendre
en compte les relations d’inclusion entre permissions, CustomPermis-
sionEvaluator utilise une hiérarchie métier définie dans PermissionHie-
rarchy. Cette étape enrichit donc la liste des permissions en ajoutant
toutes celles qui sont implicitement accordées par la hiérarchie.
· Enfin, le composant contrôle si la permission spécifiée dans l’annota-
tion @PreAuthorize est bien incluse dans l’ensemble enrichi des per-
missions. Cette vérification est effectuée par l’appel à la méthode has-
Privilege()
1 @Component (" customPermissionEvaluator ")
2 public class CustomPermissionEvaluator {
3 private final PermissionRepository permissionRepository ;
4
5 public CustomPermissionEvaluator ( PermissionRepository
permissionRepository ) {
6 this. permissionRepository = permissionRepository ;
7 }
8 public boolean hasPrivilege ( String permission ) {
9 if ( permission == null) {
10 return false ;
11 }
12 var authentication =
SecurityContextHolder . getContext (). getAuthentication ();
13 String permissionToCheck = permission . toLowerCase ();
14 Set <String > roles = authentication . getAuthorities (). stream ()
15 .map( GrantedAuthority :: getAuthority ). collect ( Collectors
16 .toSet ());
17 Set <String > permissionsFromDb = permissionRepository
18 . findByAuthoritiesNameIn ( roles )
19 . stream ()
20 .map(p -> p. getName (). toLowerCase ())
21 . collect ( Collectors . toSet ());
22 Set <String > enrichedPermissions =
PermissionHierarchy . enrichPermissions ( permissionsFromDb );
23 return enrichedPermissions . contains ( permissionToCheck );
24 }
25 }
Listing 5.10: Classe CustomPermissionEvaluator générée par le Blueprint

Utilisation de @PreAuthorize avec customPermissionEvaluator Nous utilisons

l’annotation suivante dans les endpoints des fichiers *[Link] des entités pour sécu-
riser les accès en fonction des permissions métier. Pour cela, nous avons modifié la fonction
responsable de l’injection de l’annotation @PreAuthorize dans les endpoints afin d’utiliser

65
 la nouvelle version, comme illustré dans le Listing 5.11 :
1 @PreAuthorize (" @customPermissionEvaluator
2 . hasPrivilege (' ROLE_PRODUIT_DELETE ')")
Listing 5.11: Nouvelle annotation @PreAuthorize

∗ La gestion de la hiérarchie des permissions, également générée par le blue-

print via une classe dédiée PermissionHierarchy. Cette hiérarchie permet
d’enrichir automatiquement l’ensemble des permissions d’un utilisateur en
tenant compte des relations métier entre rôles et permissions.

Cette approche assure une distinction nette entre les rôles et les permissions métier,
améliore la maintenabilité et la scalabilité du système, tout en intégrant correcte-
ment la hiérarchie propre aux autorisations métier.

• Solution mise en place coté Frontend Pour garantir une parfaite cohérence
avec l’architecture backend, où les permissions sont nettement séparées des rôles,
le frontend a été modifié via des ajustements automatiquement produits et inté-
grés par notre blueprint JHipster, afin d’assurer cette séparation entre autorités et
permissions.

– Mise à jour de la récupération des informations utilisateur La mé-

thode responsable de l’extraction des données utilisateur getUserFromAu-
thentication du fihcier userService a été modifiée par le blueprint pour ne
plus fusionner les rôles et permissions. Désormais, les permissions sont col-
lectées indépendamment des rôles, puis transmises séparément dans le DTO
utilisateur.
Cette distinction, prise en charge automatiquement, permet de traiter les per-
missions métier comme des éléments distincts, ce qui simplifie leur gestion et
leur actualisation dynamique côté frontend.
1 @Transactional
2 public AdminUserDTO
getUserFromAuthentication ( AbstractAuthenticationToken authToken ) {
3 Map <String , Object > attributes ;
4 if ( authToken instanceof OAuth2AuthenticationToken ) {
5 attributes = (( OAuth2AuthenticationToken )
authToken ). getPrincipal (). getAttributes ();
6 } else if ( authToken instanceof JwtAuthenticationToken ) {
7 attributes = (( JwtAuthenticationToken )
authToken ). getTokenAttributes ();
8 } else {
9 throw new IllegalArgumentException (" AuthenticationToken is not
OAuth2 or JWT!");
10 }
11 User user = getUser ( attributes );
12 user. setAuthorities (
13 authToken
14 . getAuthorities ()

66
15 . stream ()
16 .map( GrantedAuthority :: getAuthority ).map( authority -> {
17 Authority auth = new Authority ();
18 auth. setName ( authority );
19 return auth;
20 })
21 . collect ( Collectors . toSet ())
22 );
23 user = syncUserWithIdP ( attributes , user);
24 Set <String > authorityNames = authToken . getAuthorities (). stream ()
25 .map( GrantedAuthority :: getAuthority )
26 . collect ( Collectors . toSet ());
27 Set <Authority > authorities = authorityRepository
28 . findAllById ( authorityNames )
29 . stream ()
30 . collect ( Collectors . toSet ());
31 user. setAuthorities ( authorities );
32 Set <Permission > permissions =
permissionRepository . findByAuthoritiesNameIn ( authorityNames );
33 Set <String > permissionNames = permissions . stream ()
34 .map( Permission :: getName )
35 . collect ( Collectors . toSet ());
36 AdminUserDTO userDTO = new AdminUserDTO (user);
37 userDTO . setPermissions ( permissionNames );
38 return userDTO ;
39 }
Listing 5.12: Exemple Méthode getUserFromAuthentication aprés séparaion
des permissios et authorités

– Plutôt que d’utiliser la méthode classique hasAuthority, le blueprint génère

dans le fichier accountService une méthode spécifique appelée hasAnyPer-
mission. Cette méthode permet de vérifier si l’utilisateur possède au moins
une des permissions requises. Elle intègre la hiérarchie métier des permissions
via une fonction auxiliaire nommée getExpandedPermissions. Cette fonc-
tion étend les permissions de l’utilisateur en tenant compte de la hiérarchie
définie selon les rôles et leur poids, ce qui signifie qu’une permission de niveau
supérieur inclut automatiquement les permissions de niveau inférieur associées.
– Le blueprint crée automatiquement un guard Angular appelé UserRouteAc-
cessPermission. Ce dernier s’appuie sur la méthode hasAnyPermission pour
gérer le controle d’accès aux routes en fonction des permissions, au lieu de se
limiter à la simple validation des rôles comme dans le mécanisme classique.
Son rôle consiste à :
∗ Vérifier que l’utilisateur dispose d’au moins une des permissions nécessaires
pour accéder à la route.
∗ Rediriger vers une page d’erreur ou d’accès interdit si les permissions sont
insuffisantes.

67
 – Génération d’une directive Directive Angular Pour permettre l’affichage
ou le masquage dynamique des éléments d’interface en fonction des permis-
sions, le blueprint crée une directive Angular personnalisée nommée jhiHasA-
nyPermission. Cette directive facilite la gestion des contrôles d’affichage liés
aux permissions, en proposant une syntaxe claire et intuitive dans les tem-
plates HTML. Elle s’appuie exclusivement sur les permissions, sans considérer
directement les rôles, afin d’assurer un contrôle d’accès précis et conforme à
la logique métier. Ainsi, plutôt que d’utiliser la directive jhiHasAnyAuthori-
ty, on utilise jhiHasAnyPermission, qui est spécialement conçue pour gérer et
contrôler les permissions.

5.4 Conclusion
Ce chapitre a permis de mettre en lumière les configurations automatisées par le blue-
print au niveau du frontend, en révélant les limites des approches standards de JHipster
concernant l’intégration dynamique des rôles et permissions dans l’interface utilisateur.
Nous avons détaillé les fichiers Angular générés ou modifiés automatiquement, ainsi que
la logique conditionnelle introduite pour adapter l’affichage en fonction des droits des
utilisateurs. Enfin, ce chapitre a souligné les actions de maintenance automatisées visant
à améliorer la gestion de la confidentialité et à optimiser les performances globales des
applications générées.

68
Chapitre 6

Intégration du blueprint dans un

exemple d’application générée par
JHipster

Introduction
L’objectif principal de ce projet était de renforcer la gestion des rôles et des permissions
dans une application générée JHipster quelque soit son architecture, tout en assurant une
personnalisation fine de l’interface utilisateur selon les droits attribués à chaque profil.
Le blueprint développé permet d’automatiser l’intégration de ces règles de sécurité dans
l’ensemble du système, Aussi bien côté backend que côté frontend. Ce chapitre met en
lumière les résultats pratiques obtenus suite à la mise en œuvre du blueprint. Il permettra
de mettre en évidence les effets fonctionnels observés, notamment :

• Comment les interfaces utilisateur s’adaptent dynamiquement selon les permissions

attribuées.

• Comment la sécurité des URL, composants et actions est assurée.

Ces résultats traduisent concrètement l’intérêt de la solution mise en œuvre, en apportant

à la fois sécurité, clarté et ergonomie pour les utilisateurs finaux.

6.1 Contexte des tests et applications utilisées

Afin d’évaluer concrètement l’intégration du blueprint et de mesurer ses effets sur la
gestion des rôles et permissions, deux types d’applications JHipster ont été générées puis
personnalisées :

• Application microservice : une architecture composée d’un gateway et de mi-

croservices métier gérant des entités telles que des produits et des modèles a permis
de tester l’application du blueprint dans un environnement distribué.

• Application monolithique : il s’agit d’une application de gestion de réservations

et de biens. Ce cas d’usage simple permet de démontrer rapidement l’impact des
permissions sur l’affichage des entités, la restriction des actions utilisateur et le
contrôle d’accès visuel.

69
Les interfaces illustrées dans les sections suivantes proviennent directement de ces deux
projets de test. Elles permettent de démontrer de manière concrète l’efficacité du blueprint
dans des contextes applicatifs réalistes.

6.2 Constats sans le blueprint

6.2.1 Architecture Microservices

Dans une architecture microservices générée avec JHipster, l’application Angular four-
nie par le gateway centralise l’accès à l’ensemble des entités du système. Cependant, en
l’absence de contrôle basé sur les permissions, l’interface est strictement identique pour
tous les utilisateurs, quels que soient leurs rôles (ROLE-USER, ROLE-ADMIN, etc.).
Absence de filtrage visuel :

• Tous les profils utilisateurs accèdent à la même interface graphique.

• Les boutons d’action tels que ”Créer”, ”Modifier” ou ”Supprimer” sont affichés pour
tous les utilisateurs.

• Aucun mécanisme conditionnel n’est mis en place pour restreindre l’affichage des
composants selon les rôles ou permissions.

Exemple visuel

• Utilisateur Simple
Interface affichée (6.1) pour un utilisateur simple disposant du rôle ROLE-USER.
On observe que toutes les actions, y compris celles normalement réservées aux ad-
ministrateurs, sont visibles et accessibles.

Fig. 6.1 : Interface vue par un utilisateur simple

• Administrateur Interface affichée (6.2) pour un utilisateur administrateur dispo-

sant du rôle ROLE-ADMIN. L’affichage et les fonctionnalités sont identiques à celles
de l’utilisateur simple, sans distinction ni restriction

70
 Fig. 6.2 : Interface vue par les administrateurs

6.2.2 Architecture Monolithique :

• Une seule interface commune est exposée à tous les profils.

• Pas de filtrage visuel selon le rôle ou les permissions.

• Les utilisateurs ayant ROLE-USER peuvent accéder à toutes les entités et effectuer
des opérations sans restriction apparente.

• Les composants de l’interface (boutons de suppression, modals d’édition, formu-

laires) ne sont jamais conditionnés par des permissions.

Exemple visuel comparatif :

• Utilisateur Simple : Interface affichée fig (6.3) pour un utilisateur simple (ROLE-
USER), présentant toutes les fonctionnalités disponibles sans aucune restriction.

Fig. 6.3 : Interface utilisateur simple avant le blueprint

• Utilisateur administrateur : Interface affichée 6.4 pour un administrateur (ROLE-

ADMIN), identique à celle de l’utilisateur simple, sans différence visible ni fonction-
nelle.

71
 Fig. 6.4 : Interface administrateur

6.3 Constats après le Blueprint

6.3.1 Architecture Microservice

Grâce à l’intégration du blueprint, l’interface utilisateur Angular générée devient dy-
namique et sensible aux permissions de l’utilisateur connecté. Le rendu graphique et fonc-
tionnel s’adapte en temps réel selon les permissions attribuées, assurant une meilleure
sécurité et une meilleure expérience utilisateur.
• Filtrage basé sur les permissions :

– Chaque bouton, menu ou action est désormais conditionné à une permission

explicite (ex : product : delete, order : create, etc.).
– Les utilisateurs avec un rôle simple (ROLE-USER) ne voient que les actions
qui leur sont autorisées.

• Blocage des accès directs non autorisés :

Même si un utilisateur tente d’accéder manuellement à une route protégée (via
l’URL par exemple), l’accès est automatiquement bloqué si la permission requise
n’est pas présente. Ce filtrage est assuré côté frontend (via les guards) et renforcé
côté backend (via les annotations de sécurité @PreAuthorize).
Exemple visuel comparatif :
• L’interface 6.5 affiche un Aperçu des permissions attribuées à un utilisateur ayant
le rôle ROLE-USER.

Fig. 6.5 : Aperçu des permissions de l’utilisateur

72
• Interface utilisateur 6.6 est générée pour ce même utilisateur, affichant uniquement
les actions autorisées, conformément aux permissions et à leur hiérarchie.

Fig. 6.6 : Interface personnalisée selon les permissions de l’utilisateur

• Comme illustré dans l’interface 6.5, l’utilisateur dispose de la permission explicite

update, ce qui lui donne accès à l’action ”Éditer”. Conformément à la hiérarchie des
permissions définie dans le système, cette permission inclut également la permission
read, permettant ainsi l’affichage de l’action ”Voir”. L’interface est donc générée
dynamiquement en fonction des permissions effectivement détenues et héritées par
l’utilisateur.

• L’image 6.7 illustre le cas d’un utilisateur qui tente d’accéder directement, via l’URL,
à une interface pour laquelle il ne dispose d’aucune permission. Grâce au système
de sécurité mis en place par le blueprint, l’accès est immédiatement bloqué, et un
message d’erreur ou un redirectionnement est déclenché.

Fig. 6.7 : accès bloqué à une route sécurisé

6.3.2 Architecture Monolithique

Dans le cas d’une architecture monolithique, l’intégration du blueprint apporte le

même niveau de personnalisation dynamique de l’interface utilisateur basé sur les
permissions et leur hiérarchie.

– Affichage conditionné selon les permissions effectives :

∗ L’utilisateur connecté ne voit que les actions qui lui sont explicitement ou
implicitement autorisées selon la hiérarchie des permissions.
∗ Les composants tels que les boutons ”Éditer”, ”Voir”, ou ”Supprimer”
sont affichés uniquement si les permissions correspondantes (update, read,
delete) sont présentes.
– Blocage des accès directs non autorisés :
Même si un utilisateur tente d’accéder manuellement à une route protégée

73
 (via l’URL par exemple), l’accès est automatiquement bloqué si la permission
requise n’est pas présente. Ce filtrage est assuré côté frontend (via les guards)
et renforcé côté backend (via les annotations de sécurité @PreAuthorize).

Exemple visuel comparatif :

– L’interface 6.8 affiche les permissions associées a l’utilisateur ROLE-USER

Fig. 6.8 : liste des Permissions de l’utilisateur

– Interface Angular personnalisée dynamiquement pour cet utilisateur :

Fig. 6.9 : Interface personnalisée selon les permissions et leurs hiérarchie

– l’interface 6.9 affiche

∗ Le bouton ”Créate” est affiché grâce à la permission créate.
∗ Le bouton ”Voir” et ”update” est affiché grâce aux permissions héritées
read et update.
∗ L’actions non autorisée ( ”Supprimer”) est absente de l’interface.
– la figure 6.10 illustre le cas d’un utilisateur qui tente d’accéder directement,
via l’URL,à une interface pour laquelle il ne dispose d’aucune permission dans
une application monolithique

74
 Fig. 6.10 : Accès bloqué à une route sécurisé dans une application monolithique

6.3.3 Autre Interfaces génrées ou modifiées par le blueprint

• Cas du gateway et/ou monolithique

– Interface [Link] : Cette interface fig 6.11, présente

par défaut dans les applications JHipster monolithiques ou de type gateway,
affiche la liste des rôles (Authorities) attribués aux utilisateurs. Le blueprint y
ajoute un bouton ”Associer” pour chaque rôle, permettant d’ouvrir une inter-
face de gestion des permissions.

Fig. 6.11 : liste des autorités du (gateway ou monolihique)

∗ Interface [Link] : Cette interface (fig 6.12) existe

par défaut dans le gateway généré par Jhipster a été modifiée par le blue-
print pour intégrer un bouton ”Mettre à jour” devant chaque microservice
listé. Ce bouton permet d’accéder à la gestion des rôles du microservice
ciblé .

Fig. 6.12 : Aperçu des microservices accessible

– Cas du microservice
∗ Interface [Link] : Cette interface est générée dyna-
miquement par le blueprint pour chaque microservice. Elle permet de gé-
rer les rôles internes au microservice et elle est accessible depuis le bouton
”Mettre à jour” du gateway (cf. Fig. 6.12).

75
 Fig. 6.13 : Interface de gestion des rôles pour les microservice

∗ [Link] : À partir de l’interface 6.13, le bouton

”Associer” permet d’accéder à une version dédiée de l’interface de gestion
des permissions. Cette version affiche les permissions disponibles au niveau
du microservice, que l’administrateur peut attribuer ou retirer aux rôles
du microservice. Cette interface est également générée dans le gateway et
dans l’application monolithique, mais dans ces deux cas, elle est accessible
via le composant [Link] (fig 6.11)

Fig. 6.14 : Interface permission-management propre aux microservices

Conclusion
L’intégration du blueprint développé a permis de transformer en profondeur la gestion
des rôles et des permissions dans les applications JHipster, qu’elles soient en architecture
microservices ou monolithique. Grâce à une interface utilisateur désormais conditionnée
par des permissions explicites et hiérarchisées, chaque utilisateur bénéficie d’une expé-
rience adaptée à ses droits, garantissant à la fois la confidentialité et la clarté. Le système
mis en place empêche efficacement les accès non autorisés, même en cas de tentative
directe via l’URL, tout en assurant un rendu graphique cohérent et ergonomique. Ce tra-
vail illustre ainsi l’impact concret d’une gestion centralisée et granulaire des droits sur la
robustesse et la personnalisation des applications web générées avec JHipster.

76
Conclusion

Ce projet de fin d’études s’est articulé autour d’une problématique actuelle et stra-
tégique : automatiser la gestion fine des accès dans les applications JHipster, tout en
garantissant un haut niveau de sécurité et une adaptabilité aux architectures modernes.
Face aux limites du mécanisme RBAC standard de JHipster — souvent rigide, peu granu-
laire et difficilement extensible — la conception d’une solution personnalisée, centralisée
et hiérarchisée s’est imposée comme une nécessité.

L’objectif métier principal consistait à doter Lear Corporation d’un blueprint modu-
laire, réutilisable et automatisé, capable de générer dès la création d’un projet JHipster
une couche de sécurité complète et cohérente. L’enjeu était double : réduire significati-
vement les tâches de configuration manuelle et renforcer la cohérence, la traçabilité et
la conformité des accès, dans des environnements aussi bien monolithiques que microser-
vices, avec une intégration fluide de Keycloak et OAuth2.

Sur le plan technique, le travail accompli a permis de :

• concevoir et développer un blueprint avancé, intégrant un modèle RBAC enrichi par

une gestion fine des permissions et une hiérarchie configurable ;

• automatiser la sécurisation des endpoints backend et des routes frontend ;

• générer dynamiquement des interfaces d’administration des rôles et permissions ;

• adapter l’interface utilisateur en fonction des autorisations effectives ;

• valider la solution au sein d’une application de test générée avec JHipster.

Au-delà des réalisations techniques, ce projet m’a offert une expérience concrète et
professionnalisante. Il m’a permis de consolider mes compétences en sécurité des systèmes
d’information, en architecture logicielle, et en automatisation des processus de développe-
ment, tout en développant une approche rigoureuse, structurée et orientée vers les enjeux
métier.
En contribuant à un projet à fort impact pour l’entreprise, j’ai pu poser les bases solides
de ma future carrière dans le domaine des systèmes d’information et de la transformation
digitale, avec la satisfaction d’avoir conçu une solution à la fois technique, pragmatique
et durable.

77
Perspectives et travaux futurs

Pour approfondir et enrichir ce projet, plusieurs axes d’amélioration et d’extension

peuvent être envisagés :

• Automatisation et extension des tests : Afin d’assurer la robustesse et la fiabilité de

la solution, il est important d’augmenter la couverture des tests. Cela passe par la
création systématique de tests unitaires et d’intégration pour toutes les nouvelles
fonctionnalités introduites par le blueprint. Pour cela, l’automatisation de la généra-
tion des fichiers de tests pour les composants Angular, services et contrôleurs Spring
Boot modifiés ou ajoutés serait un gain considérable en termes de productivité et
de qualité. De plus, les tests initiaux inclus par défaut dans les projets JHipster
doivent être ajustés afin d’intégrer les modifications introduites par le blueprint.
Cette adaptation garantirait que toutes les modifications fonctionnent correctement
sans casser les fonctionnalités existantes, tout en facilitant la maintenance évolutive
du blueprint.

• Extension du blueprint aux autres frameworks frontend proposés par JHipster À

l’heure actuelle, le blueprint a été conçu spécifiquement pour fonctionner avec An-
gular côté client. Toutefois, JHipster offre également la possibilité de générer des
interfaces avec d’autres frameworks populaires tels que React ou [Link], qui pré-
sentent chacun leurs avantages en matière de performance, de modularité et de
flexibilité.
Pour accroître la portée et la réutilisabilité de la solution, une évolution pertinente
serait d’adapter le blueprint afin qu’il prenne en charge ces différentes technologies
frontend. Cela permettrait d’assurer une gestion cohérente et sécurisée des rôles
et permissions, indépendamment du framework sélectionné lors de la création de
l’application.

En somme, ces perspectives visent à renforcer la qualité, la couverture fonctionnelle et

l’adaptabilité du blueprint, contribuant ainsi à une meilleure intégration dans des envi-
ronnements professionnels variés et évolutifs.

78
Bibliographie

[1] Reference for Business. Lear Corporation History. Consulté en avril 2025. 2023.
url : https : / / www . referenceforbusiness . com / history / Ja - Lo / Lear -
[Link].
[2] Lear Corporation. Advanced Seating Innovation - INTU. Consulté en avril 2025.
2023. url : [Link]
innovation/intu.
[3] Lear Corporation. E-Systems Technology. Consulté en avril 2025. 2023. url :
[Link]
[4] Lear Corporation. Official Website. Consulté en avril 2025. 2023. url : https:
//[Link]/.
[5] Charika. Lear Corporation Engineering Morocco - Fiche signalétique. Consulté en
avril 2025. 2023. url : [Link]
engineering-morocco-793976.
[6] Okta. Contrôle d’accès basé sur les rôles (RBAC) vs. contrôle d’accès basé sur les
attributs (ABAC). Consulté en avril 2025. 2023. url : [Link]
fr/identity-101/role-based-access-control-vs-attribute-based-access-
control/.
[7] OneLogin. RBAC vs ABAC : Quelle est la différence ? Consulté en avril 2025.
2023. url : [Link]
[8] LinkedIn. Avantages et inconvénients de RBAC vs ABAC. Consulté en avril 2025.
2023. url : https : / / fr . linkedin . com / advice / 1 / what - pros - cons - role -
based-access-control-rbac-versus?lang=fr.
[9] Logto. Comprendre RBAC et ABAC. Consulté en avril 2025. 2023. url : https:
//[Link]/fr/rbac-and-abac.
[10] Kiteworks. Contrôle d’accès basé sur les attributs (ABAC). Consulté en avril
2025. 2023. url : https : / / www . kiteworks . com / fr / glossaire / controle -
access-base-attributs/.
[11] Ping Identity. Méthodes d’autorisation : ABAC, RBAC, PBAC, ReBAC. Consulté
en avril 2025. 2023. url : https : / / www . pingidentity . com / fr / resources /
identity-fundamentals/authorization/[Link].
[12] Frontegg. RBAC vs ABAC vs PBAC : Quelle est la meilleure approche ? Consulté
en avril 2025. 2023. url : [Link]
pbac.

79
[13] Styra. Qu’est-ce que RBAC, ABAC et PBAC ? Consulté en avril 2025. 2023. url :
[Link]
[14] JHipster Team. JHipster Documentation – Blueprints. Consulté en mai 2025. 2024.
url : [Link]
[15] JHipster Team. Why use a blueprint – JHipster Documentation. Consulté en mai
2025. 2024. url : [Link]
#why-use-a-blueprint.
[16] JHipster Team. Liste des blueprints dans l’écosystème JHipster. Consulté en mai
2025. 2024. url : https : / / github . com / jhipster / generator - jhipster #
blueprints.
[17] JHipster Team. Blueprint generator phases – JHipster Documentation. Consulté
en mai 2025. 2024. url : [Link]
blueprint/#blueprint-generator-phases.

80