End-Of-study Project Fakri Mohamed Ali

HASSAN II University
Faculty of Sciences and Technology Mohammedia
Department of Mathematics
END-OF-STUDIES PROJECT
Presenting
For the attainment of State Engineer's Degree
By: FAKRI Mohamed Ali

Specialization: Mathematics and Computer Science
Redesign of the management system for

applications intended for smart card identity
documents
« AMS »
Presented on 22 June 2023 before the jury:
Pr. Asmaa ABASSI FST Mohammedia
Pr. Elmostafa HANINE FST Mohammedia
Pr. Nabil AZOUAGH FST Mohammedia
M. Ouadi BELMOKHTAR IDEMIA
Academic year: 2022/2023

End-Of-Studies Project 1
Dedication
I dedicate this humble work:

To God,
To my dear family,
No dedication can express my respect, eternal love, and gratitude for the sacrifices made
for my education and well-being. May God, the Almighty, keep you, grant you health,
happiness, and a long life so that you remain the guiding light illuminating my path.
To my dear friends,
You have contributed to my success.
To all my colleagues,
To all the people who have inspired me,
To all the people who have brought me moments of happiness,
Thank you for all the unforgettable moments.
To all my teachers from elementary school, middle school, high school, and the Faculty of
Sciences and Technology of Mohammedia,
For generously imparting their knowledge and experiences to me.
Mohamed Ali
Acknowledgment
I would like to express my gratitude to God, the Almighty, who blesses us with His
blessings at every moment and every instant.
First and foremost, I would like to thank my supervisor at FST Mohammedia, Asmaa
ABASSI, who accompanied me throughout the stages of this dissertation. I thank her for their
guidance and methodological advice she provided me.
I extend my heartfelt thanks to my internship mentors, Mr. Ahmed Ziad BELABYED, Mr.
Ali MAATALA, and Mr. BELMOUKHTAR Ouadi, for their guidance, valuable advice,
continuous availability throughout my internship, and their contribution to the completion of
this work.
I would like to extend my thanks to the members of the jury Elmostafa HANINE and Nabil
AZOUAGH who will be present in the presentation for attainment of state engineer’s degree.
I would also like to acknowledge the assistance provided by individuals who contributed to
the realization of this work, and their contributions will be recognized in this dissertation.
Lastly, I would like to thank everyone who has played a role in making this internship a
success.
Abstract
This report presents the results of an end-of-studies internship conducted at IDEMIA, a

leading company specializing in identity management solutions. The focus of the internship
was the redesign of the Application Management System (AMS) that is installed on the chip
of the identity card document. The AMS is an essential component of IDEMIA's IDway, a
comprehensive identity management solution designed to manage a population's identity
throughout life.
The report consists of four main stages. Firstly, a general overview of the project and the
problem to be addressed is provided. Secondly, a detailed functional and technical study is
conducted to gain an in-depth understanding of the existing AMS. Thirdly, an analysis and
design study is carried out, incorporating the existing system and proposing a new modeling
approach for the project. Finally, the report discusses the development tools utilized to
implement the redesigned AMS.
Throughout the project, the SCRUM agile methodology was employed, adapted to the
specific needs of the internship. This agile approach facilitated efficient project management
and iterative development, ensuring the smooth progression of the project.
The redesigned AMS aims to enhance the management of applications within organizations,
providing improved functionality and usability. The internship provided valuable practical
experience, allowing for the identification and resolution of challenges encountered during
the redesign process.
Keywords: Redesign, Application Management System, Identity Card Document, IDEMIA,
IDway, AMS, SCRUM, Agile Methodology.
Résumé
Ce rapport présente les résultats de mon stage de fin d'études réalisé chez IDEMIA, qui est
une entreprise spécialisée dans les solutions de gestion d'identité. L'objectif du stage est la
refonte du système de gestion d'applications destinées aux documents d'identité à puce
(AMS). L'AMS est un composant essentiel de la solution IDway d'IDEMIA, c’est une
solution complète de gestion d'identité conçue pour gérer l'identité d'une population tout au
long de la vie.
Le rapport comprend quatre étapes principales. Tout d'abord, une présentation générale du
projet et du problème à résoudre est fournie. Ensuite, une étude fonctionnelle et technique
détaillée est réalisée pour comprendre en profondeur l'AMS existant. Ensuite, une étude
d'analyse et de conception est menée, intégrant le système existant et proposant une nouvelle
approche de modélisation pour le projet. Enfin, le rapport aborde les outils de développement
utilisés pour mettre en œuvre le AMS réaménagé.
Tout au long du projet, la méthodologie agile SCRUM a été utilisée, adaptée aux besoins
spécifiques du stage. Cette approche agile a facilité la gestion efficace du projet et le
développement itératif, garantissant une progression fluide du projet.
La refonte de l’AMS vise à améliorer la gestion des applications au sein des organisations,
en offrant une fonctionnalité et une convivialité améliorées. Le stage a permis d'acquérir une
expérience pratique précieuse, permettant d'identifier et de résoudre les défis rencontrés lors
du processus de réaménagement.
Mots-clés : Refonte, Système de Gestion des Applications, Document de Carte d'Identité,
IDEMIA, IDway, AMS, SCRUM, Méthodologie Agile.
List of Contents
Dedication ........................................................................................................ 2
Acknowledgment .............................................................................................. 3
Abstract ........................................................................................................... 4
Résumé ............................................................................................................ 5
Introduction .................................................................................................... 15
General Context .............................................................................................. 16
1.1 Host organization .................................................................................. 16
1.1.1 IDEMIA .................................................................................. 16
1.1.2 IDEMIA Morocco ................................................................... 18
1.2 Project Presentation .............................................................................. 20
1.2.1 General context of the Project .................................................. 20
1.2.2 Problematic ............................................................................. 23
1.2.3 Objectives ................................................................................ 23
1.2.4 Project Planning and Management ........................................... 25
1.3 Conclusion ............................................................................................ 29
Functional and Technical Study ........................................................................ 30
2.1 Global architecture ................................................................................ 30
2.2.1 High level architecture for AMS2.0 ......................................... 31
2.2 Functional requirement......................................................................... 31
2.2.1 Application module ................................................................. 32
2.2.2 Rule module ............................................................................ 34
2.2.3 Pending Operations module ..................................................... 35
2.3 Non-functional requirement ................................................................. 35
2.3.1 Performance ............................................................................... 35
2.3.2 Security ...................................................................................... 35
2.3.4 Reliability and Availability ......................................................... 36
2.3.5 Scalability................................................................................... 36
2.3.6 Usability ..................................................................................... 36
2.3.7 Compliance ................................................................................ 36
2.4 Technical requirements ........................................................................ 37
2.5 Conclusion ........................................................................................... 44
Analysis and Design ........................................................................................ 45
3.1 Needs analysis ....................................................................................... 45
3.1.1 Identification of actors ................................................................ 45
3.1.2 Use Case Diagrams..................................................................... 46
3.2 Sequence diagrams ............................................................................... 51
3.2.1 Application management module ............................................... 52
3.2.2 Rules management module ......................................................... 61
3.3 Class diagram ........................................................................................ 64
3.4 Conclusion ............................................................................................ 65
Project implementation .................................................................................... 66
4.1 Project implementation planning ........................................................... 66
4.1.1 JIRA as Project Management Tool ............................................ 66
4.2 Analyze and improving of existing AMS project.................................. 68
4.3 DataModel of AMS2.0 ......................................................................... 69
4.4 Document in confluence pages ............................................................. 70
4.5 Dockerization ........................................................................................ 72
4.5.1 AMS-backend Dockerfile ........................................................... 72
4.5.2 AMS-frontend Dockerfile ........................................................... 73
4.6 Continuous Integration CI ..................................................................... 73
4.6.1 Git repository.............................................................................. 73
4.6.2 AMS 2.0 Jenkins jobs ................................................................. 73
4.7 Internationalization of the AMS2.0 ......................................................... 75
4.8 GUI presentation .................................................................................. 77
General conclusion .......................................................................................... 88
Bibliography: .................................................................................................. 89
List of Figures
Fig 1: IDEMIA Logo ................................................................................................. 16

Fig 2: Distribution of IDEMIA offices worldwide ................................................... 17
Fig 3: Key numbers of IDEMIA ............................................................................... 18
Fig 4: IDway's components ....................................................................................... 20
Fig 5: ICMS's components ........................................................................................ 21
Fig 6: Document nominal lifecycle ........................................................................... 22
Fig 7: Project team..................................................................................................... 25
Fig 8: Scrum Framework as a Glance ....................................................................... 26
Fig 9: Gantt chart ....................................................................................................... 28
Fig 10: AMS v2 High Level architecture .................................................................. 31
Fig 11: Spring boot .................................................................................................... 37
Fig 12: Maven............................................................................................................ 37
Fig 13: Angular.......................................................................................................... 37
Fig 14: Keycloak ....................................................................................................... 38
Fig 15: Docker ........................................................................................................... 38
Fig 16: Nginx ............................................................................................................. 38
Fig 17: PostgreSQL ................................................................................................... 39
Fig 18: Oracle ............................................................................................................ 39
Fig 19: OpenStack ..................................................................................................... 39
Fig 20: IntelliJ IDEA ................................................................................................. 40
Fig 21: Visual Studio Code ....................................................................................... 40
Fig 22: Docker Hub ................................................................................................... 40
Fig 23: DBeaver ........................................................................................................ 41
Fig 24: Swagger ......................................................................................................... 41
Fig 25: Postman ......................................................................................................... 41
Fig 26: Git.................................................................................................................. 42
Fig 27: Jira ................................................................................................................. 42
Fig 28: Confluence .................................................................................................... 42
Fig 29: Bitbucket ....................................................................................................... 43
Fig 30: Jenkins ........................................................................................................... 43
Fig 31: SonarQube ..................................................................................................... 43
Fig 32: Nexus IQ ....................................................................................................... 44
Fig 33: JUnit ............................................................................................................. 44
Fig 34: Application Management Use Case Diagram ............................................... 46
Fig 35: Deployment Rules Use Case Diagram .......................................................... 49
Fig 36: Statistics Use Case Diagram ......................................................................... 50
Fig 37: Authentication Sequence Diagram ............................................................... 51
Fig 38: Add new application Sequence Diagram ...................................................... 53
Fig 39: Add new application’s version Sequence Diagram ...................................... 54
Fig 40: Change application version status Sequence Diagram ................................. 55
Fig 41: Application version status lifecycle Sequence Diagram............................... 57
Fig 42: Change Application status Sequence Diagram ............................................. 58
Fig 43: Retrieve the Pending Operations Sequence Diagram ................................... 59
Fig 44: Add new Deployment rule Sequence Diagram............................................. 61
Fig 45: Edit Deployment rule Sequecne Diagram .................................................... 62
Fig 46: Class Diagram of AMS v2 ............................................................................ 64
Fig 47: Jira scrum board ............................................................................................ 67
Fig 48: Burndown Chart ............................................................................................ 67
Fig 49: Project Epics ................................................................................................. 68
Fig 50: SQL scripts .................................................................................................... 70
Fig 51: DataModel of AMS2.0.................................................................................. 70
Fig 52: location of AMS2.0 in Confluence ............................................................... 71
Fig 53: Example of confluence page ......................................................................... 72
Fig 54: Jenkins Continuous Integration..................................................................... 74
Fig 55: Keycloak interaction with AMS ................................................................... 75
Fig 56: Display Deployment Rules management ...................................................... 77
Fig 57: The details of a Deployment Rule ............................................................... 78
Fig 58: Add new Deployment Rule ........................................................................... 78
Fig 59: Edit conditions before adding Deployment Rule .......................................... 79
Fig 60: Confirmation popup ...................................................................................... 80
Fig 61: Edit Deployment Rule button ....................................................................... 80
Fig 62: Edit Deployment Rule................................................................................... 81
Fig 63: Application management .............................................................................. 81
Fig 64: Add new Application .................................................................................... 82
Fig 65: Save the Application ..................................................................................... 82
Fig 66: Application details ........................................................................................ 83
Fig 67: Add application version ............................................................................... 83
Fig 68: Example of adding application version ........................................................ 84
Fig 69: Added Application version ........................................................................... 84
Fig 70: Make the version status under test ................................................................ 85
Fig 71: The next two statuses of under test ............................................................... 85
Fig 72: Status Active of the version .......................................................................... 86
Fig 73: Status enable of the Application ................................................................... 86
Fig 74: Status DISBLED of application .................................................................... 87
Fig 75: Status DELETED of version ......................................................................... 87
List of Tables
Tab 1: Glossary.......................................................................................................... 14
Tab 2: Sprints presentation ........................................................................................ 28
Tab 3: Actors identification ....................................................................................... 45
Tab 4: Add new Application Use Case ..................................................................... 47
Tab 5: Add new Application's version Use Case ...................................................... 47
Tab 6: Change Application version status Use Case................................................. 47
Tab 7: Change Application Use Case........................................................................ 48
Tab 8: Download version's package Use Case .......................................................... 48
Tab 9: View Pending Operation Use Case ................................................................ 48
Tab 10: Add deployment rule Use Case .................................................................... 50
Tab 11: Activate deployment rule Use Case ............................................................. 50
Tab 12: View statistics Use Case .............................................................................. 51
Glossary
Term Definition
ICMS Idemia Credential Management System :
 Manage production order
 Manage the ID card lifecycle
 Manage box lifecycle
IDPS Idemia Document Personalization System:

 Manage stock of blank documents
 Personalize documents
 Perform documents quality control
 Manage the box preparation and shipment
 Manage the box status
IDAP Idemia Administration Platform: frame work developed by IDEMIA
MasterData Microservice contain the referential data

CMS Credential management system
AMS Application management system
Credential profile Is the type of the card ex: ID Card, ePassport
Application version Every card application must have a version
Ex. Application a version 1, Application a Version 2
Pending Operations The pending operation(s) available on AMS are the following:
 New application
 Newer application version
 Application deleted
Post-issuance Manage Post Issuance requests sent by Web Portal then PI proxy
Scrum Frame work of Agile methodology
Epics large feature is required
CI Continuous Integration
Realm self-contained security and authentication domain that encapsulates
users
GUI graphical user interface
HTTP Hypertext Transfer Protocol to transform and receiving data
REST Representational State Transfer
API Application Programming Interface
JSON JavaScript Object Notation
Tab 1: Glossary
Introduction
In a world where digitalization of services and seamless interactions between citizens and
administrations are increasingly prevalent, the reliance on web-based platforms has become
essential. As governments and organizations strive to establish robust identification systems,
they face a multitude of policy and technological choices. Once these choices are made,
implementers are often confronted with significant implementation challenges.
The focus of my end-of-studies project is the redesign of the Application Management
System (AMS) to manage the applications that can be installed on the chip of the identity
card document. This system plays a critical role in IDEMIA's IDway, a comprehensive
identity management solution designed to manage an individual's identity throughout their
life.
This report encompasses several phases of the project. The first chapter provides an
introduction of the host organization, IDEMIA, and outlines the project's overall context,
including its challenges and significance. The second chapter delves into the functional and
technical study, which includes specifying the architecture to be integrated, along with
functional and non-functional requirements. The analysis and design study are presented in
the third chapter, offering detailed insights into the use case diagrams, sequence diagrams,
and class diagrams. Lastly, the fourth chapter focuses on the implementation phase, providing
a comprehensive account of the project's development process.
In order to ensure effective project management and iterative development, the project
adopted the SCRUM agile methodology, tailored to meet the specific requirements and
objectives.
The objective of the redesigned AMS is to enhance the management of applications within
organizations, aiming to improve functionality and usability. This report highlights the
various stages of the project, including the challenges encountered and the strategies
employed to address them.
Chapter 1: General Context
Chapter 1
General Context
This chapter establishes the general context of the end-of-stud project by first
introducing the host organization and then describing the project framework, its objectives,
and the approach to its management.
1.1 Host organization
1.1.1 IDEMIA
Fig 1: IDEMIA Logo

IDEMIA is a multinational company specializing in security and identity solutions. It
is a global leader in Augmented Identity, providing a wide range of products and services
related to secure identity verification, biometrics, digital security, and authentication.
IDEMIA offers innovative solutions that enable individuals, businesses, and governments
to authenticate identities, secure transactions, protect data, and ensure privacy. Their
products and services include:
- Biometric Solutions: IDEMIA develops and deploys biometric technologies such as

fingerprint recognition, facial recognition, iris recognition, and voice recognition.
These solutions are used for secure access control, identity verification, law
enforcement, and border control applications.
- Identity and Document Management: IDEMIA provides solutions for identity

document issuance, such as passports, national ID cards, driver's licenses, and smart
cards. They offer technologies to enhance document security, including anti-
counterfeiting features and secure personalization.
- Payment solutions: IDEMIA offers payment solutions, including SIM cards, mobile
banking and payment solutions, and secure elements for smartphones. They also
provide mobile identity verification and authentication solutions.
- Digital Security: IDEMIA provides digital security solutions for protecting data,
securing transactions, and ensuring privacy. This includes encryption, tokenization,
digital signatures, and secure authentication mechanisms.
- Public Security Solutions: IDEMIA works with law enforcement agencies and
governments to provide secure solutions for public safety, border control, and
citizen services. This includes biometric-based identification systems, crime
investigation tools, and secure document verification systems.
IDEMIA serves various sectors, including government, financial institutions,
telecommunications, healthcare, and transportation. With a wide range of expertise in
identity and security technologies, IDEMIA aims to provide trust and security in an
increasingly digital and connected world.
Fig 2: Distribution of IDEMIA offices worldwide
IDEMIA is the world leader in trusted identities in a world of increasingly digital, with a
customer base in more than 180 countries. The next reports some key numbers that can
describe IDEMIA in a way more quantitative.
Fig 3: Key numbers of IDEMIA
1.1.2 IDEMIA Morocco
IDEMIA Morocco is a thriving center with a strong focus on Research and

Development. Currently, it boasts a talented team of over 190 engineers who contribute to
the growth of IDEMIA worldwide, particularly in the Africa, Middle East, and South
America regions. This center excels in system development, integration, and client support,
enhancing IDEMIA's capabilities across various sectors.
IDEMIA Morocco has played a significant role in numerous civil and criminal projects in
multiple countries. Here are some notable examples:
- Morocco: IDEMIA Morocco actively participated in the successful implementation

of the national electronic identity card in 2019. This project showcased the center's
expertise in advanced identity solutions.
- Morocco: IDEMIA Morocco has also been involved in the development and
implementation of the national population registry (NPR).
- Nepal: The center has collaborated with the Ministry of Foreign Affairs and the
Passport Department in Nepal to deliver secure and reliable passport solutions.
- Chile: IDEMIA Morocco has contributed to identity passport cards and foreign
resident cards projects in Chile, ensuring robust identity verification and document
security.
- Qatar: IDEMIA Morocco has supported Qatar's police criminal systems, leveraging
its expertise in developing advanced law enforcement solutions.
- United Arab Emirates: IDEMIA Morocco has played a role in enhancing border
control systems in the United Arab Emirates
Additionally, IDEMIA Morocco has been involved in projects in other countries, including
Argentina, Brazil, Peru, and more. This demonstrates the center's extensive reach and its
contributions to identity and security solutions worldwide.
IDEMIA operates in various sectors, each with specific responsibilities:
The "E-documents" sector operates in:
• Telecommunications: Offering secure solutions to protect data, transactions, and

identification information for the mobile communications ecosystem.
• Identity and Travel Documents: Manufacturing and personalizing highly secure
identity documents (identity cards, passports, driver's licenses, and health cards) for the
public sector.
• Payments: Pioneering solutions and chip card systems for electronic payments.
The "Detection" sector specializes in:
• Goods and People Security: Providing a wide range of qualified and certified
products for explosive and threat detection in the aerospace and public transportation
industries.
• Defense and Sensitive Infrastructures: Optimized detection products for military
applications.
• Public Events and Emergency Services: Detection of substances or threats.
The "Identification" sector focuses on:
• Identity Solutions: Delivering highly secure national identity cards, resident cards,
and tamper-proof passports.
• Criminal Identity: Providing a range of biometrics-based products to support law
enforcement from crime scene to court.
• Border Control: Using biometrics to reconcile the seemingly contradictory goals of
increased security and reduced passenger and personnel waiting times.
• Biometric Access Control: Unique multi-biometric products using fingerprint,
finger vein and fingerprint combination, or facial recognition.
• Transportation Security: In the road and rail sectors.
1.2 Project Presentation
1.2.1 General context of the Project
Our project entitled “Redesign of the management system for applications intended
for smart card identity documents” was proposed as part of the development of a corporate
end-of-study internship. Included in the training of mathematics and computer science of
FST Mohammedia. This internship was carried out within the company IDEMIA.
The purpose of this end-of-study project is to redesign and enhance the Application
Management System (AMS) within IDEMIA's IDway solution. The IDway solution
encompasses various components aimed at providing a comprehensive and robust
identification framework. One of these components is the Identity Credential Management
System (ICMS), within which the AMS resides.
- IDway solution
The IDway solution is a comprehensive integrated product provided by IDEMIA,

specializing in delivering Identity Documents. IDway is designed to address various aspects
of identity management, including the issuance and verification of identity documents. It
provides a comprehensive platform that encompasses features such as biometric data capture,
document personalization, secure credential issuance, and identity document verification.
IDway offers robust security measures and advanced technologies to ensure the integrity and
authenticity of identity documents, contributing to enhanced identity management and secure
identification processes.
Fig 4: IDway's components

This figure illustrates the components of the IDway system and depicts the interactions
between them.
- Idemia Credential management system ICMS

ICMS in the IDway solution consists of two main parts: CMS (Credential Management
System) and AMS (Application Management System). In the context of the solution, the
AMS is specifically responsible for application management.
Fig 5: ICMS's components

ICMS, which stands for Idemia Credential Management System, is a component of the
IDway solution. Its primary features include:
Data Preparation: ICMS prepares data for personalization, ensuring that the necessary
information is ready for the issuance of identity documents.
Identity Document Life Cycle: ICMS follows the complete life cycle of identity documents,
managing their creation, activation, and deactivation processes.
GUI for Identity Document Status: ICMS provides a graphical user interface (GUI) that
allows for the easy updating of the status of identity documents. This includes functionalities
to terminate an identity document when necessary.
GUI for Identity Document Box Status: ICMS also offers a user-friendly interface for
updating the status of identity document boxes. This includes tracking and updating their
status as received, stolen, or lost.
These features make ICMS a vital component within the IDway solution, enabling efficient
data preparation, effective management of identity document life cycles, and convenient
status updates for both individual identity documents and document boxes
Fig 6: Document nominal lifecycle

In the usage phase, the citizen has his identity document. When a citizen needs to add apps
to their ID card, they will go to a service office after issuance. So here AMS will intervene
- Application management system AMS

The AMS plays a critical role in the management and deployment of card applications on
the chip of identity card documents. Its primary function is to facilitate the lifecycle
management of document applications, including provisioning, tracking, and updating.
By effectively managing these applications, the AMS ensures the smooth operation of
the entire IDway system and provides clear visibility into the applications deployed
across all issued cards.
1.2.2 Problematic
The current implementation of the AMS within IDway is based on outdated

technologies, which pose several challenges. The use of obsolete technologies limits the
system's performance, scalability, and ability to integrate with modern systems and
frameworks. This hinders the system's capability to adapt to evolving requirements and
industry standards.
Furthermore, the existing implementation of the AMS has identified security vulnerabilities
and bugs that need to be addressed. These security concerns undermine the system's ability
to provide a robust and secure environment for managing card applications. It is crucial to
rectify these issues to ensure the confidentiality, integrity, and availability of sensitive data
and to comply with industry regulations and best practices.
Addressing the issues related to outdated technologies and security vulnerabilities is essential
for the AMS to meet the increasing demands of application management, data privacy, and
security in today's digital landscape. The project will focus on redesigning and enhancing the
AMS to overcome these challenges and provide a more reliable, secure, and future-proof
solution.
1.2.3 Objectives
The objectives of our project, which focuses on redesigning the AMS to enhance its
technologies and align it with the IDway solution, are as follows:
Priority 1: Limitation of the current existing version

 Identify and analyze the limitations and shortcomings of the current AMS
implementation.
 Evaluate the existing technologies and identify areas for improvement to enhance the
performance, scalability, and security of the AMS.
Priority 2: Study on requirements
 Conduct a comprehensive study of the requirements for the redesigned AMS.
 Gather input from stakeholders, users, and the IDway solution team to understand
their needs and expectations.
 Define functional and non-functional requirements that the enhanced AMS should
meet.
Priority 3: Design UML diagrams + Deployment pattern and target
 Develop UML diagrams (such as use case diagrams, class diagrams, and sequence
diagrams) to model the system's structure and behavior.
 Determine the appropriate deployment pattern and target environment for the
enhanced AMS, considering factors like scalability, availability, and performance.
Priority 4: Creation of DevOps pipeline (GIT + Jenkins)
 Establish a DevOps pipeline using tools such as Git and Jenkins.
 Implement version control and automated build processes to facilitate collaboration
and streamline the development and deployment of the enhanced AMS.
Priority 5: Realization (Dev + tests + Build publish)
 Implement the redesigned AMS, adhering to best coding practices and industry
standards.
 Conduct thorough testing, including unit testing, integration testing, and system
testing, to ensure the reliability and functionality of the enhanced AMS.
 Build and publish the new version of the AMS, ready for deployment.
Priority 6: Auto install
 Develop an automated installation process for the enhanced AMS, simplifying the
deployment and configuration steps.
 Ensure seamless installation and integration of the AMS within the IDway solution
environment.
Priority 7: Integrate with MasterData
 Integrate the enhanced AMS with the MasterData system, ensuring seamless data
exchange and synchronization.
 Enable efficient management and retrieval of essential information within the AMS.
Priority 8: End-to-end integration
 Perform end-to-end integration testing to validate the interoperability and
functionality of the enhanced AMS within the broader IDway solution.
 Ensure smooth integration with other components and systems, including identity
management systems, authentication services, and data repositories.
1.2.4 Project Planning and Management
1.2.4.1 Project team
The organizational aspect of the project is illustrated in the image below:
Fig 7: Project team
1.2.4.2 Method of project management
To ensure the smooth progress of the project, meeting the expected outcomes,
avoiding any delays in project completion, and overcoming potential challenges and
unforeseen circumstances that may jeopardize the project's progress, we have chosen to adopt
a project management methodology that allows for organized work advancement, keeping
up with the needs and requirements, while also being flexible and agile enough to
accommodate any necessary changes.
Considering the factors of Quality, Cost, and Time, we have selected SCRUM as the
methodology of choice for this project, which we have adapted to derive maximum benefit.
We will outline the approach followed for task development and allocation within the
allocated project timeline.
SCRUM is defined by its creators as a "framework for addressing complex and changing
problems, while delivering products of the highest possible value in a productive and creative
manner." Its strongest aspect is that the client plays a collaborative role, being involved in all
phases of development to ensure that the final product aligns with their needs.
In the SCRUM methodology, three key roles are defined: the "Product Owner" who carries
the vision of the product to be realized (typically representing the client), the "Scrum Master"
who ensures adherence to the Scrum methodology, and the development team responsible
for creating the product. The core element of SCRUM are sprints, which is a time-boxed
iteration typically lasting between 2 to 3 weeks. Each sprint includes a set of planned features
and is supported by regular meetings to keep the work on track. These features make up the
"sprint backlog." For our project, we have opted for sprints of 2 to 3 weeks. It is important to
distinguish the sprint backlog from the "product backlog," which represents all the expected
features of the product across all sprints.
Fig 8: Scrum Framework as a Glance
1.2.4.3 Project Planning
In order to have an overall vision of the project’s progress and to undertake well-
thought-out planning, we feel it necessary to cut the project into a “sprint” for the
development of a Backlog Product as below:
Sprints Date
Sprint 0 13/02/2023 → 20/03/2023 (Skills development)
Tasks
- Formation on IDEMIA’s civil tribe
- Formation on IDway Components
- Formation on technical stack
Sprint 1 20/03/2023 → 03/04/2023

Tasks - Initialize Git repository / Jenkins jobs
- Gather AMS requirements
- Initialize DataModel of AMS 2.0
Sprint 2 03/04/2023 → 17/04/2023

Tasks
- Prepare dev environment
- Backend implementation: add new Rule
- Backend implementation: add REST services to retrieve Rule's attributes and
operators
- Frontend implementation: add new Rule
Sprint 3 17/04/2023 → 01/05/2023

Tasks
- Create Docker files for AMS backend and frontend
- Config Sonar + NexusIQ jobs
- Backend implementation: create new application
- Backend service: retrieve credential profile list
- Backend implementation: retrieve applications list
- Frontend implementation: display applications list
- Frontend implementation: create new application
Sprint 4 2/05/2023 → 15/05/2023

Tasks
- Adjust frontend to meet IDEMIA graphical charter
- Backend implementation: add application's version endpoint
- Adopt a strategy for logging and exception handling
- Backend implementation: retrieve application's details endpoint
- Frontend implementation: display application's details
- Frontend implementation: add application's version
Sprint 5 15/05/2023 → 29/05/2023

Tasks
- Change version's status
- Change application's status including push to IDPS

- Rule condition CRUD operations
- Edit rules
- Frontend implementation: display details of an application version
- Backend implementation: retrieve details of an application version
Sprint 6 29/05/2023 → 12/06/2023

Tasks
- Support i18n in AMS2.0 Frontend
- Retrieve Pending Operations from AMS
- Prepare Keycloak installation script
- Prepare users and roles scripts for Keycloak
- Connect AMS GUI to Keycloak
Tab 2: Sprints presentation
Gantt chart:
Fig 9: Gantt chart
1.3 Conclusion
In this chapter, we have provided an overview of the general framework of the project.
After introducing the hosting organization and presenting the project, we have outlined the
scope of this end-of-study project and discussed the methodology adopted to ensure effective
project management.
The next chapter will focus on the functional and technical analysis of the project, where we
will delve deeper into understanding the specific requirements and technical aspects
involved.
Chapter 2: Functional and Technical Study
Chapter 2
Functional and Technical Study
This chapter is dedicated to the preliminary study, which primarily involves the initial
assessment of needs. It encompasses the analysis and diagnosis of the overall information
system, as well as the identification and modeling of the contextual factors.
2.1 Global architecture

The architecture of our project is built on a microservices approach. This architectural
style emphasizes the development of the application as a collection of small, independent
services that communicate with each other through well-defined APIs. These microservices
are designed to be loosely coupled, allowing for flexibility, scalability, and ease of
maintenance.
By breaking down the application into smaller services, each responsible for a specific
functionality, we can achieve better modularity, fault isolation, and independent deployment.
This microservices-based architecture enables us to enhance agility, promote rapid
development, and facilitate the integration of new features or updates into the system.
Additionally, it provides the ability to scale individual services independently based on their
specific demands, optimizing resource utilization and overall performance.
2.2.1 High level architecture for AMS2.0
Fig 10: AMS v2 High Level architecture

AMS 2.0 microservice is a part of ICMS components. It provides services for both AMS
GUI and IDPS post-issuance operations.
2.2 Functional requirement
This section focuses on analyzing the application's requirements following the

presentation of the problem, objectives, and a brief introduction to the business in the
previous chapter. We will now delve into the functional requirements of AMS2.0. To
facilitate a comprehensive analysis of the project's needs, it is divided into four core
modules: Application, Rules, Statistics, and Pending Operations.
By examining these modules individually, we can gain a deeper understanding of the

specific requirements associated with each and ensure a thorough analysis of the project's
overall needs.
2.2.1 Application module
Web service:
The Application Management System (AMS) should provide an API that enables users to
load different versions of an application. This API allows users to upload and store multiple
versions of an application within the system.
- The AMS should provide an API that allows users to download different versions of
an application. With this API, users can access and retrieve specific versions of an
application based on their needs or preferences.
- The AMS should provide an API that enables users to query the system and determine
which versions of an application are currently available. This API allows users to
obtain a list of all available application versions, facilitating visibility and selection.
- The AMS should provide an API that allows users to query the system and determine
the status of different versions of an application. Users can utilize this API to retrieve
information about the current status (e.g., active, tested, deleted…) of various
application versions.
- The AMS should provide an API that allows authorized users to update the status of
various versions of an application. This API grants authorized users the ability to
modify the status of specific application versions, ensuring accurate and up-to-date
information regarding their availability and development status.
- The AMS should provide an API that allows users to register deployment rules for
different versions of an application. This API enables users to define specific rules or
configurations for deploying and managing different versions of an application,
ensuring consistency and adherence to defined guidelines.
- The Application Management System (AMS) should provide an API that allows users
to retrieve all applications within the system. This API ensures that users can obtain
a comprehensive list of all applications available, facilitating efficient management
and oversight of the entire application inventory.
- The AMS should have an API to retrieve all versions of a specific application. This
API enables users to access a complete history of different versions associated with a
particular application. By retrieving this information, users can track the evolution
and progression of the application over time.
- The AMS should provide an API that allows users to retrieve an application based on
its unique identifier (ID). This API allows users to query the system with a specific
application ID and obtain detailed information about that particular application. This
functionality provides a straightforward and efficient method for retrieving specific
applications when their ID is known.
- The AMS should have an API to retrieve all the status information associated with an
application. This API enables users to retrieve the status of a particular application,
providing valuable insights into its current state. By querying the system for the status
of an application, users can quickly determine if it is active, inactive, under
development, or in any other relevant state.
These descriptions highlight the key functionalities and capabilities expected from the web
service in the application module of the AMS.
GUI:
The Application Management System (AMS) should incorporate a Web GUI that offers a
user-friendly interface for performing various functions. The GUI should enable users to
access the following features:
- Application Listing: The GUI should display a comprehensive list of all applications
available in the AMS. This listing can include key information such as application
names, versions, and statuses.
- Application Details: When a specific application is selected from the list, the GUI
should provide detailed information about that application. This may include its
description, release notes, associated documentation, and any related resources, and
also in this GUI the user can manage the version of the application by editing the
status of the version and also can update the status of an application with specific
cases.
- Add Application: The GUI should include a form or interface that allows users to add
a new application to the AMS. Users can input details such as the application name,
description, and other relevant information. Upon submission, the GUI should
validate the inputs and trigger the creation of a new application in the AMS.
- Add Version of Application: Within the GUI, users should have the ability to add new
versions to existing applications. This feature can be implemented through a form
where users can provide version-specific details, such as version number, binary file
and text file. After validating the inputs, the GUI should initiate the addition of the
new version to the corresponding application in the AMS.
- Version Application Details: The GUI should display detailed information about a
selected version of an application. This can include attributes like version number,
file AID, module AID, and the users can download the specific versions of the
application via version application details GUI. This functionality implemented
through a download link within the application version details page.
By integrating these features into the Web GUI, the AMS offers users an intuitive and
visually appealing interface for managing applications. The GUI acts as a front-end for
interacting with the AMS's underlying functionalities, providing a seamless and efficient
user experience.
2.2.2 Rule module
Web service:
For the web service in the rules module, the following descriptions can be used for each
requirement:
- The Rules module of the web service should provide an API that allows users to add
deployment rules for an application. This API enables users to define specific rules
and there conditions.
- The web service should include an API that allows users to edit existing deployment
rules. This API enables users to modify and update the fields of the rule and the
conditions of this rule.
- The web service should have an API that allows users to delete deployment rules.
This API enables users to remove specific deployment rules that are no longer needed
or relevant. It helps in maintaining a clean and up-to-date set of rules for application
deployment.
- The web service should provide an API that allows users to retrieve a list of all
deployment rules. This API enables users to obtain an overview of all the existing
deployment rules associated with applications. It facilitates easy access to rule details.
- The web service should include an API that allows users to change the status of a
deployment rule. This API enables users to update the status of a specific rule, such
as activating or deactivating it. It provides control over the execution and applicability
of deployment rules for an application.
These descriptions highlight the key functionalities and capabilities expected from the web
service in the rules module. They ensure efficient management and control of deployment
rules for applications within the system.
GUI:
The GUI of rules are:
- Add Rule: The GUI should include a form where users can input the necessary details
to add a deployment rule for an applications. This form include fields such as rule
name, rule comment and description, the conditions.
- Edit Rule: When a user selects a specific deployment rule from the list, if we do not
have an application use this rule, the GUI should display an edit button to modify the
existing rule. Users can modify the desired fields for this rule. After making the
necessary changes, they can save the updates, which triggers the API call to edit the
rule.
- Delete Rule: The GUI should display a list of existing deployment rules, when we
select a rule if the applications exist does not use this rule we can display delete
button. In addition, the users can delete the rule.
- Get List of Rules: The GUI should present a table of existing deployment rules. The
table include the name column when the user select a the rule he can see all the
information for this rule like the description and comments how create the rule …
The GUI design should aim for a user-friendly and intuitive interface, allowing users to easily
add, edit, delete, view, and change the status of rules. It should provide clear feedback on the
success of each action and ensure a smooth user experience.
2.2.3 Pending Operations module
Web service:
- The AMS Should provide an API that can sent all the versions of the applications can
be added or updated or deleted
2.3 Non-functional requirement
2.3.1 Performance
- The AMS system should be able to handle a high volume of concurrent requests
without significant degradation in response time.
- The system should have efficient data processing and retrieval mechanisms to ensure
fast and smooth operations.
- The system should be scalable to accommodate future growth and increasing user
demand.
2.3.2 Security
- The AMS system should implement robust security measures to protect sensitive data
and prevent unauthorized access.
- The system should support secure communication protocols to ensure the

confidentiality and integrity of data exchanged between the components.
- Access to system functionalities and data should be controlled based on user roles
and permissions.
2.3.4 Reliability and Availability
- The AMS system should have a high level of reliability, ensuring minimal downtime
and maximum availability.
- The system should have backup and recovery mechanisms in place to safeguard
against data loss and ensure business continuity.
2.3.5 Scalability
- The AMS system should be designed to handle increasing data volumes, user loads,
and application complexity over time.
- The system should support horizontal and vertical scalability to accommodate

growing needs and ensure optimal performance.
2.3.6 Usability
- The AMS system should have a user-friendly and intuitive interface, making it easy
for users to navigate and perform tasks efficiently.
- The system should provide clear and concise documentation, including user guides
and manuals, to assist users in understanding system functionalities.
2.3.7 Compliance
- The AMS system should adhere to relevant industry standards, regulations, and legal
requirements pertaining to data privacy, security, and application management.
- The system should support audit trails and logging mechanisms to facilitate
compliance monitoring and reporting.
These are just a few examples of non-functional requirements that can be considered for the
AMS system. It is important to tailor these requirements to specific organizational needs and
industry standards to ensure the successful implementation and operation of the system
2.4 Technical requirements
In this section, we will present the technical requirements and tools utilized in the
implementation of this project. These specifications arise from specific constraints that exist
within the project's context.
Fig 11: Spring boot

Spring Boot is a Java framework that simplifies the development of standalone,
production-ready applications. It provides automatic configuration, eliminating the need for
manual setup. With built-in features like embedded servers, dependency management, and
auto-configuration, developers can rapidly create robust applications with minimal effort.
Spring Boot embraces convention-over-configuration, enabling developers to focus on
writing business logic rather than dealing with tedious infrastructure tasks.
Fig 12: Maven

Maven is a build automation tool for Java projects that simplifies dependency
management and project configuration. It uses XML-based project descriptors to define
project structure and dependencies. With its centralized repository and standardized project
layout, Maven streamlines the build process and facilitates project collaboration.
Fig 13: Angular

Angular is a popular framework for building dynamic web applications. It follows the
component-based architecture, allowing developers to create reusable UI components.
Angular provides a powerful toolkit for data binding, routing, and dependency injection,
enabling efficient development and testing. With its extensive ecosystem and community
support, Angular is widely used for creating modern and scalable web applications.
Fig 14: Keycloak

Keycloak is an open-source identity and access management solution. It provides
features for user authentication, authorization, and single sign-on (SSO) across multiple
applications. Keycloak supports various protocols like OAuth 2.0 and OpenID Connect,
making it easy to secure and manage user identities in a standardized way. With its extensible
architecture and robust security features, Keycloak is widely used for securing modern web
and mobile applications.
Fig 15: Docker

Docker is an open-source platform that allows developers to automate the deployment
and management of applications in lightweight, isolated containers. It provides a consistent
environment for running applications across different systems. Docker simplifies the
packaging and distribution of software, making it easier to build, ship, and run applications
in a scalable and portable manner. With its efficient resource utilization and easy scalability,
Docker has revolutionized the way applications are developed and deployed.
Fig 16: Nginx

Nginx is a high-performance web server and reverse proxy server that excels in
handling concurrent connections and efficiently serving static content. It is known for its
scalability, low memory footprint, and efficient resource utilization. Nginx also offers
advanced load balancing and caching capabilities, making it ideal for high-traffic websites
and applications. With its robust feature set and widespread adoption, Nginx has become a
popular choice for powering modern web architectures.
Fig 17: PostgreSQL

PostgreSQL is a powerful open-source relational database management system
(RDBMS) known for its stability, reliability, and extensibility. It offers advanced features
like support for complex queries, transactions, and concurrency control. PostgreSQL
supports a wide range of data types and provides comprehensive data integrity and security
mechanisms. With its active community and continuous development, PostgreSQL is a
popular choice for data-intensive applications and enterprise-grade solutions.
Fig 18: Oracle

Oracle Database is a powerful relational database management system (RDBMS). It
provides a comprehensive and feature-rich platform for storing, managing, and retrieving
structured data. With its robust transaction management, data integrity mechanisms, and SQL
support, Oracle Database is widely used in enterprise applications and data-driven solutions
Fig 19: OpenStack

OpenStack is an open-source cloud computing platform that provides a set of software
tools for building and managing public and private clouds. It offers a flexible and scalable
infrastructure-as-a-service (IaaS) solution with components for compute, storage,
networking, and orchestration. OpenStack allows organizations to deploy and manage virtual
machines, storage volumes, and network resources in a highly customizable and
interoperable manner. It is widely adopted by enterprises and service providers to create and
operate cloud environments.
Fig 20: IntelliJ IDEA

IntelliJ IDEA is a popular integrated development environment (IDE) developed by
JetBrains. It provides a comprehensive set of tools and features to support software
development in various programming languages, including Java, Kotlin, Scala, and more.
IntelliJ IDEA offers advanced code editing, debugging, refactoring, and version control
integration, making it a powerful tool for developers. It also includes features like intelligent
code completion, code analysis, and built-in support for frameworks and technologies,
enhancing productivity and facilitating efficient development workflows.
Fig 21: Visual Studio Code

Visual Studio Code, is a lightweight and versatile source code editor developed by
Microsoft. It is widely used by developers across different platforms and supports a wide
range of programming languages. VS Code offers a rich set of features, including smart code
editing, syntax highlighting, code refactoring, and debugging capabilities. It also supports
extensions, allowing developers to customize and enhance the editor's functionality
according to their specific needs. With its intuitive interface and extensive community
support, VS Code has gained popularity for its flexibility and productivity in modern software
development.
Fig 22: Docker Hub
Docker Hub is a cloud-based repository provided by Docker that allows developers

to store, share, and access container images. It serves as a central hub for the Docker
community, providing a platform for users to publish and discover containerized applications
and services. Docker Hub hosts a vast collection of public container images, making it easy
for developers to find and utilize pre-built images for their projects. It also offers features
like versioning, security scanning, and automated builds, simplifying the management and
distribution of Docker images.
Fig 23: DBeaver

DBeaver is a popular and powerful database management tool that supports various
database systems. It provides a unified interface for connecting to and interacting with
databases such as PostgreSQL, Oracle, SQL Server, and more. DBeaver offers features like
SQL query editing, data visualization, schema browsing, and database administration tasks.
It supports both graphical and command-line interfaces, making it suitable for both beginner
and advanced users. With its extensive plugin ecosystem and cross-platform compatibility,
DBeaver is widely used by developers, database administrators, and data analysts for efficient
database management and exploration.
Fig 24: Swagger

Swagger is an open-source framework that allows developers to design, build,
document, and consume RESTful APIs easily. It provides a set of tools and specifications for
defining APIs using a YAML or JSON format. With Swagger, developers can create
interactive documentation, generate client SDKs, and test APIs, making the API development
process more efficient and collaborative.
Fig 25: Postman
Postman is a popular API development and testing tool that simplifies the process of
building and consuming APIs. It offers a user-friendly interface for sending HTTP requests,
inspecting and manipulating responses, and automating API workflows. With features like
collections, environments, and tests, Postman enables developers to streamline API
development, documentation, and collaboration, making it an essential tool in the API
development lifecycle.
Fig 26: Git

Git is a distributed version control system used for tracking changes in software
development projects. It provides a reliable and efficient way to manage source code,
allowing multiple developers to work on the same project simultaneously. Git offers features
like branching, merging, and conflict resolution, facilitating collaboration and ensuring code
integrity. It also allows for easy reverting to previous versions, making it a powerful tool for
version control and project management.
Fig 27: Jira

Jira is a popular project management tool that helps teams plan, track, and manage
their work efficiently. It offers features for issue tracking, task management, and agile project
management methodologies like Scrum and Kanban. Jira allows teams to create and assign
tasks, set priorities, track progress, and collaborate effectively. It provides customizable
workflows, reporting capabilities, and integration with other tools, making it a versatile
solution for organizing and managing projects of various sizes and complexities.
Fig 28: Confluence

Confluence is a collaboration and documentation tool that enables teams to create,
organize, and share knowledge effectively. It provides a platform for creating and editing
rich content, such as project documentation, meeting notes, and team knowledge bases. With
features like page linking, commenting, and version history, Confluence promotes
collaboration and encourages team members to contribute and share information. It also
offers integration with other tools, allowing seamless integration of content and enhancing
team productivity and communication.
Fig 29: Bitbucket

Bitbucket is a web-based version control repository hosting service that facilitates
collaborative software development. It supports both Git and Mercurial version control
systems, providing teams with a platform to store, manage, and collaborate on source code.
Bitbucket offers features like branch management, pull requests, code reviews, and issue
tracking, enabling teams to work together efficiently and maintain code quality. It also
integrates with other development tools, such as Jira and Jenkins, for seamless workflows
and continuous integration/continuous deployment (CI/CD) pipelines.
Fig 30: Jenkins

Jenkins is an open-source automation tool used for continuous integration and
continuous delivery (CI/CD). It provides a platform to automate the building, testing, and
deployment of software projects. Jenkins allows developers to integrate their code changes
frequently, detect issues early, and deliver software updates quickly and reliably. It supports
various plugins and integrations, making it highly customizable and adaptable to different
project requirements.
Fig 31: SonarQube

SonarQube is a code quality management platform that analyzes code for bugs,
vulnerabilities, and code smells. It provides insights and metrics to help improve code quality
and maintainability. SonarQube scans source code, identifies issues, and generates detailed
reports with recommendations for code improvements. It supports multiple programming
languages and integrates into the development workflow to ensure high-quality code
standards are maintained.
Fig 32: Nexus IQ

Nexus IQ is a component intelligence tool that helps organizations identify and
manage open source components and their associated risks in software development. It
analyzes the components used in applications, identifies security vulnerabilities, license
compliance issues, and provides recommendations for remediation. Nexus IQ integrates with
build systems and repositories, providing developers with real-time feedback and policy
enforcement to ensure secure and compliant software delivery. It helps organizations
maintain control over their software supply chain and make informed decisions regarding
component usage
Fig 33: JUnit

JUnit is a popular open-source testing framework for Java applications. It provides a
simple and standardized way to write and execute unit tests. With JUnit, developers can
define test cases, assertions, and test fixtures to verify the correctness of their code. It supports
annotations for test configuration and execution, allowing developers to easily organize and
run tests. JUnit also provides features for test reporting, test suites, and test runners, making
it a powerful tool for automated testing and test-driven development (TDD). It promotes the
principles of test isolation, readability, and maintainability, enabling developers to create
robust and reliable test suites for their Java projects.
2.5 Conclusion
In this chapter, we have covered the gathering of functional, non-functional, and technical
requirements. The next chapter will be devoted to the analysis and design of the project,
detailing the use case diagrams, sequence diagrams, and class diagrams.
Chapter 3: Analysis and Design
Chapter 3
Analysis and Design
3.1 Needs analysis

This stage involves analyzing and dissecting the needs to derive a representation in
formalized diagrams.
3.1.1 Identification of actors
An actor refers to a human, machine, or system that is not part of the solution to be
implemented but participates in the overall functioning of the solution through interaction.
Below are the different actors involved in the identification system, along with their
roles.
Actor Functions
Administrator A super user with full access to all functionalities of the AMS.
Issuer The individual or organization responsible for loading applications into the
AMS system.
Tester The person or organization who assists in testing the loaded applications
after they are downloaded from the system
Operator Has an overview of the system, but does not have the ability to make
modifications
IDPS System that communicates with the AMS through web services to manage
post-issuance requests
Tab 3: Actors identification
3.1.2 Use Case Diagrams
After identifying the actors of our application, it is necessary to determine the

dedicated use cases for each module.
Use cases help represent the system's functionality from the user's perspective,
providing a view of the system in its external environment.
In the following, we will analyze each functionality and its use cases.
3.1.2.1 Application management module
The Application Management Use Case Diagram provides a visual representation of

the various interactions and functionalities associated with application management within a
system. It outlines the various use cases or specific tasks that different actors can perform,
highlighting the relationships and dependencies between them.
Fig 34: Application Management Use Case Diagram
This use case diagram presents an overview of the various actors and their associated use
cases in relation to application management.
Let's take a few examples of use cases:
- Add new application
Use Case Add new Application

Actor Administrator, Issuer
Description This use case enables both the administrator and the issuer to create a new
application and associate it with a deployment rule and a credential profile
Precondition Authentication
Tab 4: Add new Application Use Case
- Add new application’s version
Use Case Add new Application’s Version

Actor Administrator, Issuer
Description This use case allows both the administrator and the issuer to upload a new
version of an application onto the AMS by using a binary file. This use
case grants the administrator and the issuer the ability to select a specific
application and then load a new version of that application into the system.
Precondition Authentication, view application’s details
Tab 5: Add new Application's version Use Case
- Change application version status
Use Case Change Application’s version status

Actor Administrator, Tester
Description This use case allows both the administrator and the tester to modify the
status of an application version, while adhering to the defined version
status lifecycle.
Tab 6: Change Application version status Use Case
- Change application status
Use Case Change Application status

Actor Administrator
Description This use case enables the administrator to change the status of an
application, while adhering to the defined conditions for changing the
application status.
Tab 7: Change Application Use Case
- Download version’s package
Use Case Download version’s package

Actor Administrator, Tester, Operator
Description This use case enables the administrator, the tester and operator to
download the binary file of a version.
Precondition Authentication, view version’s details
Tab 8: Download version's package Use Case
- View Pending Operations list
Use Case View Pending Operations list

Actor IDPS
Description This use case is to provide the IDPS with a comprehensive list of pending
operations related to card processing. This allows the IDPS to monitor and
manage the necessary updates, additions, and removals of applications on
the cards efficiently.
Tab 9: View Pending Operation Use Case
3.1.2.2 Deployment Rules management module
The Deployment Rules Management use case diagram offers a comprehensive

overview of the interactions and functionalities involved in effectively managing deployment
rules within a system. Deployment rules serve as essential guidelines that govern the
deployment process of applications.
Fig 35: Deployment Rules Use Case Diagram

This use case diagram presents an overview of the various actors and their
associated use cases in relation to rules management.
- Add deployment rule
Use Case Add deployment rule

Actor Administrator
Description This use case allows the administrator to add a new deployment rule along
with its corresponding conditions.
Tab 10: Add deployment rule Use Case
- Activate Deployment Rule
Use Case Activate Deployment Rule

Actor Administrator
Description This use case allows the administrator to enable a deployment rule,
granting the application the ability to utilize this specific deployment rule
Precondition Authentication, View selected rule’s details
Tab 11: Activate deployment rule Use Case
3.1.2.3 Statistics reports module
The Statistics Report use case diagram provides a visual representation of the
different actors and their associated use cases related to generating statistical reports within
a system.
Fig 36: Statistics Use Case Diagram
This use case diagram presents an overview of the various actors and their
associated use cases in relation to statistics reports.
- View statistics report:
Use Case View statistics report

Actor Administrator, Operator
Description This use case grants both the Administrator and the Operator access to
view statistical reports generated by the system. This use case facilitates
the extraction of valuable insights and analysis based on the collected data,
empowering users to make informed decisions. Users can retrieve
statistical information pertaining to two key metrics, namely application
usage and credential profiles. By leveraging this use case, users can
explore and analyze the statistical data to gain a comprehensive
understanding of application usage patterns and the distribution of
credential profiles
Tab 12: View statistics Use Case
3.2 Sequence diagrams
The sequence diagram represents the interaction of actors with our system in a
chronological sequence. This means that representing use cases using sequence diagrams
allows us to illustrate the collaboration between system objects from a temporal
perspective. In the following, we will present sequence diagrams related to some use cases.
3.2.1 Authentication
Fig 37: Authentication Sequence Diagram
Description:
1. The actor initiates the authentication process by providing their login and password.
2. The Keycloak identity system validates the login and password provided by the
actor, and return the access token.
3. The actor includes the access token in a request sent to the AMS server.
4. The AMS server receives the request and verifies the validity of the access token
with the Keycloak identity system.
5. If the access token is valid, the AMS server proceeds to process the request and
return a response to the actor.
6. If the access token is found to be invalid during the verification process, the AMS
server sends an "unauthorized" error response to the actor, indicating that the
authentication has failed.
3.2.1 Application management module
In this section, we present a series of sequence diagrams that depict the interactions
and chronological flow of events related to application management in our system. These
sequence diagrams provide a visual representation of the collaboration between actors and
objects, highlighting the dynamic behavior of our application management feature.
3.2.1.1 Add new application
The sequence diagram below outlines the process for adding a new application to
our system.
Fig 38: Add new application Sequence Diagram

Description:
7. The actor initiates the process by providing the required details for the new
application.
8. The user selects the appropriate deployment rule and credential profile associated
with the new application.
9. The system validates the user's input, conducting necessary checks to ensure data
integrity and security.
10. If the input passes all validations, the system automatically sets the status of the new
application as "created" and adds it to the corresponding database table.
11. A confirmation message is generated and sent to the actor, indicating the successful
addition of the new application.
3.2.1.2 Add new application’s version
The sequence diagram below outlines the process of adding a new version of an
application.
Fig 39: Add new application’s version Sequence Diagram

Description:
1. Actor displays application details.
2. The system gets a list of versions of the application and sends the result to the actor.
3. Actor sends a request to the application object to add a version of the selected
application.
4. Application object checks the existence of the application.
5. If the version does not exist, the application object uploads the file of the version to
the database and sets the version status as created.
addition of the new application.
3.2.1.3 Change application version status
The sequence diagram below outlines the process of changing the status of an
application's version.
Fig 40: Change application version status Sequence Diagram

Description:
1. The actor initiates the process by requesting to view the application details.
2. The application object retrieves the list of existing versions of the application and
provides it to the actor.
3. The application version object checks the application details to determine if the
application is disabled.
4. If the application is disabled, the actor is allowed to change the version status while
adhering to the defined version status lifecycle.
5. Once the actor selects a version and updates its status, the application version object
verifies the change against the predefined version status lifecycle.
6. This verification ensures that the requested status transition is valid and follows the
defined rules for version status changes.
7. Finally, a confirmation message is generated by the system and sent back to the actor,
indicating the successful change in the application version status.
3.2.1.4 Application version status lifecycle
The sequence diagram showcases the lifecycle of an application version,

illustrating the various statuses it goes through from creation to removing.
Fig 41: Application version status lifecycle Sequence Diagram

Description:
1. The actor sends a request to change the application version status to the desired stage,
such as "under test."
2. The application version status object validates the status change request (e.g., from
"created" to "under test") to ensure it meets the defined version status rules.
3. If the validation is successful, the application version status is changed to the
requested stage (e.g., from "created" to "under test").
status change.
These steps are repeated for status transitions like "under test" to "tested," "tested" to "active,"
and "active" to "deactivated".
The following additional conditions apply:
 If the status is "under test," the actor has the ability to change the status to "rejected."
Once the status is changed to "rejected," the actor loses the ability to change the status
further.
 If the status is "active," there is a loop where the actor can activate the "deactivated"
status. Similarly, if the status is "deactivated," the actor can activate it. The loop
continues until the status is changed to "deleted," which marks the end of the version
lifecycle.
3.2.1.5 Change Application status
The sequence diagram below outlines the process of changing the status of an
application.
Fig 42: Change Application status Sequence Diagram

Description:
1. The actor initiates the process by displaying the details of an application.
2. The application object requests the versions of the application from the versions
object.
3. The versions object returns the versions to the application object.
4. The application object displays the application details for the actor.
5. If the application has an active version, the actor can send a change application status
request.
6. The application object validates the new status.
7. If the new status is "enable," the application object sends the active version to the
IDPS.
8. If the new status is "disable," the application object changes the application status
without involving the IDPS.
9. Finally, the application object sends a confirmation message to the actor indicating
the application status change.
10. If the application has no active version, the application object sends an error message
to the actor.
3.2.1.6 Retrieve the Pending Operations
The sequence diagram below outlines the process of retrieving the Pending
Operations from AMS
Fig 43: Retrieve the Pending Operations Sequence Diagram
Description:
1. The IDPS component is called by the PI Web portal and Proxy to retrieve card status,
application identifiers, and citizen data using the card number. It calls the CMS
subsystem for this information.
2. The CMS subsystem returns the card status, card application(s) identifiers, and citizen
data.
3. If the card status is valid, the IDPS component checks for any pending operations on
the AMS.
4. The AMS checks for pending operations.
5. If the AMS finds a list of pending operations, the AMS subsystem checks the
deployment rule for each card application to determine the proper action:
 Rule 1: Deployment with no condition
 Rule 2: Deployment with conditions based on citizen demographic data
6. If the card application has a deployment rule with no condition, the AMS sends the
list of pending operations to the IDPS to perform.
7. Once the operation has been performed on the card, the IDPS component notifies the
CMS subsystem with the card application identifiers available on the card to update
the database.
8. If the card application has a deployment rule with conditions, the AMS uses the
citizen data sent by the IDPS to check if the conditions are fulfilled.
9. If the AMS finds that the rule conditions apply by comparing the retrieved citizen
data with the rule conditions, it sends the list of pending operations to the IDPS to
perform.
10. Once the operation has been performed on the card, the IDPS component notifies the
CMS subsystem with the card application identifiers available on the card to update
the database.
11. If the AMS finds that the rule conditions do not apply by comparing the retrieved
citizen data with the rule conditions, it will not be possible to perform update
operations on this card.
12. The AMS sends a message indicating that no pending operations are available.
13. If no pending operations have been found, the AMS sends a message indicating that
no pending operations are available.
14. If the card status is invalid, it will not be possible to perform any pending operations
on this card.
15. The AMS sends an error message back to the IDPS.
3.2.2 Rules management module
In this section, we present a series of sequence diagrams that depict the interactions
and chronological flow of events related to application management in our system. These
sequence diagrams provide a visual representation of the collaboration between actors and
objects, highlighting the dynamic behavior of our deployment rules management feature.
3.2.2.1 Add new Deployment rule
The sequence diagram below outlines the process of adding a new deployment
rule.
Fig 44: Add new Deployment rule Sequence Diagram

Description:
1. The actor initiates the process of adding a new deployment rule and provides the
necessary information, such as the rule name and its associated conditions.
2. The Rule object creates a new instance of the Condition class for each condition
associated with the rule.
3. The Rule object automatically sets the rule status as "created."
4. The Rule object sends a message to the actor, indicating that the rule has been added
successfully.
3.2.2.2 Edit Deployment rule
The sequence diagram below outlines the process of editing deployment rule.
Fig 45: Edit Deployment rule Sequecne Diagram

Description:
1. The actor initiates the process by requesting to display the existing rules.
2. The Rule object returns a list of existing rules.
3. The actor selects the rule they want to edit.
4. The Rule object retrieves the list of conditions and the list of applications associated
with the selected rule.
5. The Rule object returns the details of the selected rule.
6. If the rule is not used in any application, the actor can send an edit rule request, and
the Rule object performs the editing.
7. The Rule object sends a confirmation message indicating that the rule has been
successfully edited.
8. If the rule is used in some applications, the Rule object returns an error message to
the actor, indicating that the rule is already in use.
3.3 Class diagram

The modeling of any system essentially involves a class diagram that encompasses
the different entities and their relationships. A class diagram provides a visual representation
of the structure and organization of the system. It depicts the classes, their attributes, and the
relationships between them, such as associations, aggregations, and inheritances.
By using a class diagram, we can gain a better understanding of the system's components and
their interactions. It helps to identify key classes, their properties, and methods that they own.
Additionally, class relationships highlight how data flows through the system and how
different components work together to achieve specific functionality.
The Class diagram below shows the various classes and their relationships in the AMS
system.
Fig 46: Class Diagram of AMS v2
3.4 Conclusion
Before starting the implementation phase, it is essential to define the objectives and
functionalities of the system. This step aims to identify the usage boundaries, services, and
solutions that the system offers to the user. By the end of this chapter, we were able to
modeling the system's functionality. This was accomplished through various diagrams that
accurately specify the composition and behavior of the system. In the next chapter, we will
proceed with the implementation and transformation of these models in order to execute the
proposed solution.
Chapter 4: Project Implementation
Chapter 4
Project implementation
This chapter aims to present the technical tools utilized for project implementation, as well
as addressing various aspects involved in the realization of our project.
4.1 Project implementation planning
In this section, we will outline the planning process for the implementation of the
redesigned Application Management System (AMS) using the Agile Scrum methodology
and the JIRA platform.
4.1.1 JIRA as Project Management Tool
JIRA played a pivotal role in our project as the primary project management tool for
planning, tracking, and collaborating on the implementation phase. We leveraged the
capabilities of JIRA to streamline our project management processes. The following aspects
highlight our use of JIRA:
- Backlog management and prioritization:
JIRA allowed us to effectively manage and prioritize our product backlog. Each user
story or feature was created as an issue in JIRA, capturing the necessary details, acceptance
criteria, and any related attachments. The backlog was visually represented, making it easy
to visualize the scope of work and prioritize the most valuable items. Using JIRA's
customizable workflows, we tracked the progress of each item as it moved through different
stages, from "To Do" to "In Progress" and finally to "Done".
- Task assignment and tracking:
JIRA facilitated efficient task assignment and tracking within the development team. As user
stories were broken down into tasks, they were assigned to team members, ensuring clear
ownership and accountability. JIRA's user-friendly interface allowed team members to
update the status of their tasks, log time spent, and add comments or attachments to provide
necessary context. This real-time visibility into the progress of tasks enabled effective
collaboration and coordination among team members.
Fig 47: Jira scrum board
- Progress monitoring and reporting:
JIRA provided comprehensive progress monitoring and reporting capabilities. We

utilized JIRA dashboards and reports to track the overall progress of the implementation
phase. Customizable dashboards allowed us to visualize key metrics such as sprint burndown
charts, velocity, and work distribution. These insights helped us identify any bottlenecks,
adjust resource allocation if necessary, and make informed decisions to ensure timely
delivery of features.
Fig 48: Burndown Chart

In Jira, we have organized our project into several epics to manage and track the major
functionalities and features of our Application Management System (AMS) redesign project.
Each epic represents a high-level user requirement or a significant component of the system.
The epics help us prioritize and plan our development efforts, allowing us to break down the
project into manageable pieces.
Fig 49: Project Epics
Within our project, we have adopted a structured approach to implementation, as depicted in

the figure. Our initial focus was on design and project setup, ensuring a solid foundation for
the development process. Subsequently, we proceeded with the implementation of the core
epics, namely application management and rules management. By prioritizing the
development tasks before addressing security aspects, we aimed to streamline the
development process and gain clarity on the specific resources requiring protection within
the security layer.
4.2 Analyze and improving of existing AMS project
Before proceeding with the implementation phase of the project, it was crucial for us
to initiate a thorough analysis of the existing AMS project. This initial step involved delving
into the various aspects of the project, including obtaining and scrutinizing all the pertinent
documents that would provide valuable insights into the functionalities of the previous
version of AMS. These documents served as a vital resource for us to gain a comprehensive
understanding of how the system operated and the features it offered.
In addition to studying the documentation, we dedicated significant time and effort to

comprehend the intricacies of the APIs employed in the project. By thoroughly examining
the API specifications and functionality, we were able to familiarize ourselves with the
integration points and the interactions with external systems or components. This in-depth
understanding of the APIs paved the way for seamless integration and ensured the smooth
operation of the new version of AMS.
To gain hands-on experience and further explore the data structure, we executed the SQL
script of the previous AMS version on our local development environment using DBeaver, a
robust database management tool. This allowed us to generate the data model tables and
analyze the structure, relationships, and constraints within the database.
During the data model analysis phase, we identified areas where the database schema could
be enhanced. By carefully scrutinizing the existing structure, we identified potential
improvements and optimizations that could be implemented to enhance performance, data
integrity, and overall efficiency. These proposed enhancements would enable the new version
of AMS to better cater to the evolving needs of the system and provide an improved user
experience.
Once we completed the comprehensive understanding of the existing functionalities and

gained valuable insights into the data model, the ICMS teams took the initiative to deploy
the AMS project in a testing environment. This provided us with a unique opportunity to
delve deeper into the system and explore various use cases that would be encountered in the
new version. Through rigorous testing, we were able to validate and refine our understanding
of the system's behavior, uncover potential edge cases, and identify areas for improvement.
This testing phase played a pivotal role in shaping the development roadmap and ensuring
that the new version of AMS would meet the desired functional and non-functional
requirements.
4.3 DataModel of AMS2.0
Creating SQL scripts for both Oracle and PostgreSQL databases. These scripts were
designed to generate the DataModel, which would establish the foundation for linking the
database layer with the backend layer of the AMS project. This deliberate separation between
the two layers was a strategic decision aimed at simplifying our development process and
ensuring modularity and scalability.
By creating dedicated SQL scripts for each database platform, we ensured compatibility and
flexibility, allowing the AMS application to seamlessly integrate with either Oracle or
PostgreSQL databases based on specific deployment requirements. This approach not only
facilitated easier migration and database management but also enhanced the overall
performance and maintainability of the system.
The SQL scripts were carefully crafted to define the necessary tables, relationships,
constraints, and indexes required for the AMS DataModel. By leveraging the power and
expressiveness of SQL, we were able to accurately represent the various entities and their
attributes, ensuring data consistency and integrity throughout the application.
The DataModel generated from the SQL scripts served as a blueprint for the database layer,
providing a clear structure and organization for storing and retrieving data. This separation
of concerns between the database layer and backend layer allowed for easier development
and testing, as well as future-proofing the system by enabling seamless migration to
alternative databases if needed.
Fig 50: SQL scripts

Here is the dataModel of AMS2.0 associated to the scripts that we created:
Fig 51: DataModel of AMS2.0
4.4 Document in confluence pages
The AMS2.0 project has a dedicated location within the Confluence, serving as a
central repository for documenting both specific and non-specific functionalities, as well as
best practices in development. This documentation initiative is aimed at ensuring that future
team members or stakeholders can easily access and reference the necessary information.
By maintaining a comprehensive documentation section, we foster knowledge sharing and

provide a valuable resource for developers joining the project at a later stage. This
documentation covers a wide range of topics, including project-specific functionalities,
system architecture, coding conventions, and implementation guidelines.
Fig 52: location of AMS2.0 in Confluence

The AMS located in the ICMS HOME we have two directories for the AMS v2, one for
Architecture & designs and the other for development,
The AMS project, specifically the AMS v2, is housed within the ICMS HOME directory.
Within this directory, we have established two distinct directory to organize and manage
different aspects of the project: Architecture & Designs and Development.
The Architecture & Designs directory serves as a repository for all architectural artifacts and
design documentation related to the AMS v2. This includes DataModel, functional
requirement, high-level architecture, and others. By this mechanism, we ensure that all team
members have easy access to the latest architectural decisions and designs, facilitating a clear
understanding of the system's structure and components.
The Development directory, on the other hand, is designated for best practice that we need
to do in our code, scripts, and development-related resources for the AMS v2 project. This
directory serves that the team members can develop the project with the best practice.
Fig 53: Example of confluence page
The purpose of this page is to focus on the architecture and layer structure of the AMS project,
as well as the relationships between these layers. The goal is to provide a comprehensive
understanding of how the different components and layers interact to form a cohesive system
4.5 Dockerization
In the AMS project, we need to containerize both the backend and frontend projects.
This involves creating Docker images for both the frontend and backend and pushing them
to a registry. To achieve this, we utilize Dockerfiles, with one dedicated to the backend and
another for the frontend.
4.5.1 AMS-backend Dockerfile
First, we started by creating the Dockerfile for the backend. We began by pulling the
Alpine image with the tag 3.17.2. Then, we defined the repository snapshot name and the
repository hostname as arguments. Next, we added a certificate file from a specific URL to
the /etc/ssl/certs/idemia-root-ca.crt path in the container. After that, we appended the contents
of a certificate file to the /etc/ssl/certs/ca-certificates.crt file and updated the CA certificates.
We proceeded by installing OpenJDK 17 and upgrading the packages in the container. Then,
we set the environment variable myEnv to /tmp/ams/, exposed port 8080, set the working
directory to /tmp/ams/, and copied the contents of the current directory (the JAR file) to
/tmp/ams/. We created directories, set ownership and permissions, and switched to a non-
root user. Finally, we set the entrypoint command to run the ams-backend.jar file with Java.
4.5.2 AMS-frontend Dockerfile
The Dockerfile for the frontend starts by using the nginx:1.23.3-alpine image from the
Docker registry. It removes the existing content in the /usr/share/nginx/html/ directory,
creates directories for SSL and nginx configuration, and copies the nginx configuration files
from the nginx/ directory. It also copies the contents of the dist/ directory to
/usr/share/nginx/html. Additionally, it adds a shell script called replaceBackendUrls.sh and
sets it as the entrypoint. The script is responsible for replacing backend URLs. The container
runs the Nginx server in the foreground. Afterwards, it upgrades the packages in the container
using the apk command. Then, it creates a user group called appgroup and a non-root user
called appuser, assigns ownership to specific directories, and switches to the appuser.
4.6 Continuous Integration CI
4.6.1 Git repository
Upon completing the extensive analysis of the existing AMS project, we proceeded
with setting up a dedicated repository in Bitbucket to serve as the central code repository for
AMS. This repository served multiple purposes, including establishing a seamless integration
with Jenkins, facilitating collaborative code sharing among the team members, and
distinguishing it from other projects within ICMS. We aptly named this repository "AMS" to
clearly identify it amidst the various ongoing projects.
4.6.2 AMS 2.0 Jenkins jobs
In parallel, we took the initiative to configure Jenkins, a powerful automation server, to

streamline our development and deployment processes. We defined several Jenkins jobs
specifically tailored for AMS 2.0.
Fig 54: Jenkins Continuous Integration

The "AMS2.0_AFTER_COMMIT" job was created to automatically trigger a build process
each time code changes were committed to the Bitbucket repository. This job played a crucial
role in ensuring the continuous integration and validation of the project.
Additionally, we established the "AMS2.0_CLM" job within Jenkins to leverage Nexus IQ

for comprehensive component lifecycle management. This job enabled us to perform
thorough security and license scans on the project dependencies, ensuring compliance and
mitigating potential risks.
To streamline the release process, we implemented the "AMS2.0_RELEASE_DOCKER"

job. This job is related to releasing a specific version of (AMS 2.0) of a software application
using Docker. It implies that the software has reached a stable state and is ready for
deployment or distribution.
Furthermore, we introduced the "AMS2.0_SNAPSHOT_DOCKER_DEPLOY" job,

dedicated to deploying the snapshot version of the Docker image to the target environment.
This job ensured that the latest version of AMS was readily available for testing and
validation purposes.
In addition to the build and deployment processes, we recognized the importance of

maintaining code quality and adhering to industry best practices. To achieve this, we
integrated the "AMS2.0_SONAR_BUILD_JAVA17" job, which facilitated the analysis of
the code-base using SonarQube. This job enabled us to assess code quality, identify potential
bugs or vulnerabilities, and enforce coding standards, ultimately improving the overall
maintainability and reliability of the AMS system.
4.7 Internationalization of the AMS2.0
The current version of the AMS support two languages: French and English. The
default language of the AMS depends on the language of the user's browser. The user can
change the language by using a scroll-down list that displays both languages (EN and FR).
We have implemented these functionalities using the i18n directory in the asset, we have
created two files, en.json and fr.json, which represent the key-value pairs. The keys are the
same, but the values differ depending on the language.
4.8 Security Layer

In the security layer, we have utilized the Keycloak framework.
Fig 55: Keycloak interaction with AMS

The nominal lifecycle of keycloak that we will use in AMS:
The AMS application integrates with Keycloak using the Keycloak Adapter.
- When a user tries to access a protected resource or perform an action that requires
authentication, the AMS application redirects the user to the Keycloak login page.
- The user enters their credentials (username and password) on the Keycloak login
page.
- Keycloak validates the credentials and, if successful, issues an ID token and an

access token to the Angular application.
- The Angular application can store these tokens in local storage or session storage
for subsequent authenticated requests.
- When the Angular application makes requests to the backend APIs, it includes the
access token in the Authorization header. Keycloak verifies the access token to
ensure the user is authorized to access the requested resource.
- If the access token expires, the AMS application can request a new one using the
refresh token provided by Keycloak
To install Keycloak, we have used a Docker Compose configuration file that pulls the
Keycloak image. Once Keycloak is installed, we execute a shell script that waits for the
installation to complete. Subsequently, we run a script, which handles TLS configuration.
Following that, we execute a script responsible for creating clients and another script that
adds users along with their respective roles.
Within the AMS, we have defined specific user roles such as issuer, operator, tester, and
admin. These roles are established within the user and role creation script, ensuring
appropriate access and permissions for each role.
Fig: scripts to install keycloak
Fig: scripts to create user and roles
4.8 GUI presentation
In this section, we will showcase the implemented GUIs of the project, providing an
overview of their functionalities and purpose. Each GUI will be thoroughly explained,
highlighting its specific features and intended user interactions.
By presenting these GUIs, we aim to offer a comprehensive understanding of the visual

interfaces within the project and their corresponding functionalities.
Fig 56: Display Deployment Rules management

This tab is dedicated to rule management, providing an organized view of all existing rules
in the database. The rules are displayed in a table for easy visibility. Additionally, there are
two sections: one for rule details and the other for rule conditions. At the bottom, there is an
"Add Rule" button for creating new deployment rules. To view rule details or associated
conditions, the user must first select a rule to see the details linked to this rule and the
conditions of the rule as we will see next. This layout enhances usability and facilitates
efficient rule management within the system.
Fig 57: The details of a Deployment Rule

When a rule is selected, its detailed information is displayed. For example, when the
"HEALTH_RULE" is selected, the rule's name, description, comment, status, creation date,
and the user who created it are shown. Additionally, the associated conditions for this rule,
such as the "health_condition," are displayed. Furthermore, a small table indicates if the rule
is used by any applications. In this case, "HEALTH_RULE" is used by two applications,
namely "HEALTH_APP" and "VOTE_APP." As previously mentioned, if a rule is being
used by any application, its information can be viewed, but editing is restricted to prevent
unintended impacts on the associated applications
Fig 58: Add new Deployment Rule
When the "Add Rule" button is clicked, a form component is displayed, allowing the user to
input the rule name and description. Additionally, conditions specific to the rule can be
added. The user can enter the condition name, select the holder attribute (e.g., Age, Sex,
Birthday), specify the query type (e.g., Equal, Greater, Greater or Equal, Different), and
provide the condition value. For example, if "Age" is selected as the holder attribute,
"Greater" is chosen as the query type, and the age is set to 18, the condition would be
formulated as "Age must be greater than 18 years old." Multiple conditions can be added to
the rule, enabling complex rule definitions as per requirements.
Fig 59: Edit conditions before adding Deployment Rule

When adding conditions to a rule, the GUI provides an option to edit or delete conditions in
case of any mistakes. Within the GUI, there is a column named "Actions," which contains
icons for editing and deleting conditions. By clicking on the edit icon, the user can make
modifications to the condition locally, ensuring accuracy before saving the rule. This
functionality allows for convenient and error-free rule creation by allowing adjustments to
be made prior to finalizing the rule.
Fig 60: Confirmation popup

After clicking the "Save" button to add a rule, there is a possibility that the user may have
made a mistake. To address this scenario, a popup has been implemented to confirm the user's
intention to add the rule. This popup serves as an additional safeguard, ensuring that the user
is certain about adding the rule before it is permanently saved. By prompting for
confirmation, it helps prevent accidental or unintended additions of rules, providing an extra
layer of assurance in the rule management process.
Fig 61: Edit Deployment Rule button

We have added the rule successfully and the rule is not used by any application so we can
display edit rule button else the user cannot see the edit rule, when we click in the edit rule
button we display other component
Fig 62: Edit Deployment Rule

This is the page when we click in edit rule we can edit the rules and also the conditions of
the rule.
Search by Keyword
Fig 63: Application management

In the "Applications" tab, we present a comprehensive view of all the applications stored in
the database. The applications are organized in a table format for easy readability. The table
includes various details such as the application's identifier name, name, credential profile,
version, deployment status, version status, deployment rule, issuer, and the last update of the
application. On the right side of the table, an icon is provided to access the details of each
application, including the associated versions. At the bottom of the page, there is an "Add
Application" button, which allows users to add new applications to the system. This intuitive
GUI design facilitates efficient application management and enables seamless navigation and
interaction with the AMS system.
Fig 64: Add new Application

If the user clicked in the “add application” button he can see this page to add the an
application, he need to write the name, identifier, issuer, select deployment rule in the
deployment rule he can select one rule exist in the database and have the status enabled, select
the credential profile (existing in the database), write a description and a comment
Fig 65: Save the Application

After the user fills in all the required fields, upon clicking the save button, we implement an
important step to ensure accuracy. A popup dialog is displayed to confirm the user's intention
to add the application. If the user chooses to cancel by clicking the cancel button, the
application is not added. However, if the user confirms by proceeding with the save action,
the application is added to the system. Upon successful addition, the user is automatically
redirected to the application details page for further information and management
Fig 66: Application details

After successfully adding the application, we are redirected to the application details page.
Here, we have access to comprehensive information about the application, including all the
mandatory fields. Additionally, we can view the table displaying the application versions.
Since we haven't added any versions yet, we can change the default status of the application,
when we add the application the default status "created," and we are unable to enable it. To
address this, we can add a new version of the application by clicking the "Add Version"
button. This allows us to activate the version and progress further in managing the
application's lifecycle.
Fig 67: Add application version

Now, to add a concrete application version, we can specify the version number and upload
the corresponding binary file. When entering the version number, we validate it to ensure it
doesn't already exist within the application. If a duplicate version is detected, an error
message is displayed. As for the binary file, we simply need to upload it, and the system will
automatically calculate the size on card and the checksum. These two fields are pre-filled and
cannot be manually edited. Similarly, for the Application AID, Module AID, and Load File
AID, we only need to upload the file.txt, and the system will extract the necessary values
from it for our convenience.
Fig 68: Example of adding application version
Fig 69: Added Application version

After adding the application, its default status is set to "created," indicating that it is in the
initial stage. Additionally, we have added the first version of the application, which is labeled
as 1.0. However, we have the flexibility to add additional versions such as 2.0 in the future.
To make the application active and enable a specific version, we have implemented
intermediate statuses. At this point, we can display the "active" status, which allows us to
activate the application and utilize its respective version.
Fig 70: Make the version status under test

When we clicked in the change status we can chose the status of under_test as we can see
Fig 71: The next two statuses of under test

As we see when the tester finish testing the application he can make is as tested or rejected
for our case we can make it test to make the version active, if we make it rejected we cannot
change the status other time of the version
Fig 72: Status Active of the version

Now when the status of the application is active we can enable application by clicking enable
this application button if we clicked in the button we can see the confirmation popup as
always if the user confirm and the push of the application to IDPS was successfully we can
enable the application
Fig 73: Status enable of the Application

The application is in the "ENABLED" state, indicating that it is active and operational.
However, if we wish to disable the application temporarily, we have the option to do so. It is
important to note that while the application is enabled, we cannot modify the status of its
versions. Thus, in order to make changes to the version status, we must first disable the
application.
Fig 74: Status DISBLED of application

When the application is disabled, its state changes to "DISABLED." This indicates that the
application is currently inactive and not available for use. In this state, we have the flexibility
to modify the status of its versions. We can update the status of each version based on our
requirements, such as marking a version as "DEACTIVETED”, this allows us to manage and
control the availability and status of individual versions within the disabled application.
Fig 75: Status DELETED of version

Once the application version is set to "DISABLED," we have the ability to edit the status of
the version to "DEACTIVATED." This status indicates that the version is no longer actively
used or available. When it is DEACTIVATED we can change the version to "DELETED,"
it becomes a permanent state and cannot be modified further. The "DELETED" status
signifies that the version has been removed or deleted and is no longer accessible. Therefore,
any changes to the status of a version that is in the "DELETED" state are not allowed.
General conclusion
My end-of-study internship has been instrumental in the acquisition of both technical

and managerial skills, greatly impacting me on a personal level as well. The culmination of
my studies was marked by the completion of a final project conducted at IDEMIA Morocco.
The project began with an exploration of the global architecture. We delved into both
functional and non-functional requirements, ensuring that the application module, rule
module, and pending operations module met the necessary criteria.
Following the needs analysis, we identified the actors involved and constructed use case
diagrams to capture the system's behavior. Sequence diagrams were also used to illustrate the
flow of actions within the application management module and the rules management
module. Additionally, a class diagram was created to represent the relationships and structure
of the system.
To facilitate the implementation of the project, we developed a detailed implementation plan

using JIRA as the project management tool. We analyzed and improved the existing AMS
project, implementing continuous integration techniques. The DataModel of AMS 2.0 was
initialized, and comprehensive documentation was created in Confluence pages.
Furthermore, we ensured the internationalization of AMS 2.0 and presented a user-friendly
graphical user interface.
In conclusion, our vision for this project extends beyond the current work we have
accomplished. We recognize that there are numerous opportunities for further enhancement
and development. As we move forward, we have identified the following tasks as potential
future improvements:
1. Implementation statistics
2. Implementation of continuous deployment (CD) to support Auto Install of AMS in a

Kubernetes cluster. This would streamline the deployment process and ensure
seamless updates to the system.
3. Externalization of any referential data used by AMS in a MasterData external system.

By separating the referential data from the application, we can achieve better
maintainability and flexibility.
By pursuing these future developments, we aim to continuously refine and optimize the
management system for applications intended for smart card identity documents. Our
commitment to improvement and innovation remains unwavering, and we look forward to
exploring these opportunities in the future.
Bibliography:
IDEMIA:
 https://www.idemia.com/
 https://www.idemia.com/wp-content/uploads/2022/09/idemia-leader-identity-
technologies-brochure-202209.pdf
Confluence pages in IDEMIA
 Le lien est accessible seulement dans réseau interne idemia.
Learn Docker
 https://docker-curriculum.com/
OpenStack horison
 https://wiki.openstack.org/wiki/Horizon
Scrum Documentation
 https://www.atlassian.com/fr/agile/scrum
Production-Grade Container Orchestration, Kubernetes
 https://kubernetes.io/

End-Of-study Project Fakri Mohamed Ali

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

End-Of-study Project Fakri Mohamed Ali

Uploaded by

Copyright:

Available Formats

HASSAN II University

Faculty of Sciences and Technology Mohammedia

By: FAKRI Mohamed Ali

Redesign of the management system for

Academic year: 2022/2023

I dedicate this humble work:

This report presents the results of an end-of-studies internship conducted at IDEMIA, a

Fig 1: IDEMIA Logo ................................................................................................. 16

IDPS Idemia Document Personalization System:

MasterData Microservice contain the referential data

1.1 Host organization

Fig 1: IDEMIA Logo

- Biometric Solutions: IDEMIA develops and deploys biometric technologies such as

- Identity and Document Management: IDEMIA provides solutions for identity

Fig 2: Distribution of IDEMIA offices worldwide

Fig 3: Key numbers of IDEMIA

1.1.2 IDEMIA Morocco

IDEMIA Morocco is a thriving center with a strong focus on Research and

- Morocco: IDEMIA Morocco actively participated in the successful implementation

IDEMIA operates in various sectors, each with specific responsibilities:

The "E-documents" sector operates in:

• Telecommunications: Offering secure solutions to protect data, transactions, and

The "Detection" sector specializes in:

1.2 Project Presentation

1.2.1 General context of the Project

The IDway solution is a comprehensive integrated product provided by IDEMIA,

Fig 4: IDway's components

- Idemia Credential management system ICMS

Fig 5: ICMS's components

Fig 6: Document nominal lifecycle

- Application management system AMS

The current implementation of the AMS within IDway is based on outdated

Priority 1: Limitation of the current existing version

1.2.4 Project Planning and Management

1.2.4.1 Project team

The organizational aspect of the project is illustrated in the image below:

Fig 7: Project team

1.2.4.2 Method of project management

Fig 8: Scrum Framework as a Glance

1.2.4.3 Project Planning

Sprint 1 20/03/2023 → 03/04/2023

Sprint 2 03/04/2023 → 17/04/2023

Sprint 3 17/04/2023 → 01/05/2023

Sprint 4 2/05/2023 → 15/05/2023

Sprint 5 15/05/2023 → 29/05/2023

- Change application's status including push to IDPS

Sprint 6 29/05/2023 → 12/06/2023

Tab 2: Sprints presentation

Fig 9: Gantt chart

2.1 Global architecture

2.2.1 High level architecture for AMS2.0

Fig 10: AMS v2 High Level architecture

2.2 Functional requirement

This section focuses on analyzing the application's requirements following the

By examining these modules individually, we can gain a deeper understanding of the

2.2.1 Application module

2.2.2 Rule module

2.2.3 Pending Operations module

2.3 Non-functional requirement

- The system should support secure communication protocols to ensure the

2.3.4 Reliability and Availability

- The system should support horizontal and vertical scalability to accommodate

2.4 Technical requirements

Fig 11: Spring boot