Aziz Guebsi February 2023

pfe
Aziz Guebsi
February 2023
Contents
1 Project background and scope 6

1.1 introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Overview of the host company . . . . . . . . . . . . . . . . . . 6
1.2.1 Digitalberry Presentation . . . . . . . . . . . . . . . . 6
1.2.2 Organisational chart of the host company . . . . . . . 6
1.3 Unveiling our Project: Insights and Innovations . . . . . . . . 7
1.3.1 project background . . . . . . . . . . . . . . . . . . . . 7
1.3.2 A look into the existing solutions . . . . . . . . . . . . 7
1.3.3 Criticizing the existing solution . . . . . . . . . . . . . 8
1.3.4 Our solution . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 Working methodology . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1 Agile approach . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2 Crystal approach . . . . . . . . . . . . . . . . . . . . . 13
1.4.3 Dynamic Systems Development Method (DSDM) . . . 13
1.4.4 Selection of Scrum . . . . . . . . . . . . . . . . . . . . 14
1.4.5 Scrum principle . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Digital Trust and Security Fundamentals 17

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.2 Area of use . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 Security qualities . . . . . . . . . . . . . . . . . . . . . 18
2.3 Public key infrastructure(PKI) . . . . . . . . . . . . . . . . . . 18
2.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Components of the public key infrastructure . . . . . . 18
2.3.3 Asymetric Key Ciphers . . . . . . . . . . . . . . . . . . 19
2.4 X509 certificate . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.2 Structure of a certificate . . . . . . . . . . . . . . . . . 21
1
CONTENTS
2.5 Certificate Signing Request . . . . . . . . . . . . . . . . . . . . 22

2.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.2 Structure of a CSR . . . . . . . . . . . . . . . . . . . . 23
2.6 Digital Signature . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.1 overview . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6.2 Production steps . . . . . . . . . . . . . . . . . . . . . 23
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Sprint 0 : Planning and architecture 26

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2 Gaps and Opportunities: An In-Depth Needs Analysis . . . . 26
3.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Meeting User Requirements: A Comprehensive Analysis of
Functional and Non-Functional Needs . . . . . . . . . . . . . . 26
3.3.1 major parties identification . . . . . . . . . . . . . . . . 27
3.3.2 Identifying and Addressing Functional Needs . . . . . . 27
3.3.3 Identifying and Addressing Non-Functional Needs . . . 28
3.4 Product backlog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5 Dividing the project into Sprints . . . . . . . . . . . . . . . . . 31
3.6 Global use case diagram . . . . . . . . . . . . . . . . . . . . . 31
3.7 Application Architecture . . . . . . . . . . . . . . . . . . . . . 31
3.7.1 Microservice architecture . . . . . . . . . . . . . . . . . 32
3.7.2 Three-tier architecture . . . . . . . . . . . . . . . . . . 33
3.7.3 Django MTV pattern . . . . . . . . . . . . . . . . . . . 34
3.8 Working Environment . . . . . . . . . . . . . . . . . . . . . . 35
3.8.1 Hardware Environment . . . . . . . . . . . . . . . . . . 35
3.8.2 Software Environment . . . . . . . . . . . . . . . . . . 35
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4 Sprint 1 : Authentication and Registration 38

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Analysing Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.1 Global use case diagram for sprint 1 . . . . . . . . . . . 39
4.3.2 Description of the ”authenticate” use case . . . . . . . 39
4.3.3 Authentication sequence diagram . . . . . . . . . . . . 40
4.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Login and register interfaces . . . . . . . . . . . . . . . 41
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2
CONTENTS
5 Sprint : Communication between microservices 44

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 RabbitMQ: Overview and Benefits . . . . . . . . . . . . . . . 44
5.2.1 RabbitMQ mechanism . . . . . . . . . . . . . . . . . . 44
5.3 Sprint Planning and Goals . . . . . . . . . . . . . . . . . . . . 45
5.4 Digitalberry Approach . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Company Approach: Internal Requests and RabbitMQ . . . . 46
5.5.1 Advocating for RabbitMQ Integration . . . . . . . . . 46
5.6 RabbitMQ Implementation . . . . . . . . . . . . . . . . . . . . 47
5.7 Sprint Execution and Challenges . . . . . . . . . . . . . . . . 47
5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Sprint 2: Requests and Signature 48

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.3 Analysing Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1 Gloabal user case diagram for Sprint 2 . . . . . . . . . 50
6.3.2 Description of the ”requests and signature” use case . . 51
6.3.3 Request and signature class Diagram . . . . . . . . . . 52
6.3.4 Sequence diagram for requests and signature microservice 52
6.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.4.1 Request and signature interfaces . . . . . . . . . . . . . 52
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7 Sprint 3:Notification and dockerizing 56

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.2 Sprint backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.3 Analysing sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . 57
7.3.1 Global user case diagram for Sprint 2 . . . . . . . . . . 57
7.3.2 Description of the notification use case . . . . . . . . . 58
7.3.3 Notification class Diagram . . . . . . . . . . . . . . . . 59
7.4 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.5 Implemention . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.6 Dockerization . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.6.1 Assessing Application Components . . . . . . . . . . . 61
7.6.2 Creating Dockerfile . . . . . . . . . . . . . . . . . . . . 61
7.6.3 Containerizing Services . . . . . . . . . . . . . . . . . . 62
7.6.4 Defining Docker Compose Configuration . . . . . . . . 62
7.6.5 Building and Deploying Docker Images . . . . . . . . . 63
7.6.6 Testing and Validating Containers . . . . . . . . . . . . 63
7.6.7 Monitoring and Scaling . . . . . . . . . . . . . . . . . . 63
3
CONTENTS
7.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A Appendix 66
4
CONTENTS
General Introduction
Computer science is a dynamic branch of study that focuses on computer
system design, development, and application. Algorithms, data structures,
programming languages, software engineering, computer architecture, and
artificial intelligence are among the subjects covered.
Electronic signatures have become a vital aspect of our lives in the digital
era, allowing us to sign papers and perform commercial transactions remotely.
Electronic signatures are pieces of data connected to electronic documents
that signify the signer’s intent to sign them. However, as electronic signa-
tures grow more common, so do the security threats and problems.
Identity theft, hacking, and fraud pose major financial and reputational
risks to firms that employ electronic signatures. As a result, the significance
of security in the realm of electronic signatures cannot be understated. To
safeguard sensitive data and maintain the integrity and validity of electronic
signatures, robust security mechanisms such as encryption, authentication,
access control, and intrusion detection are required.
Furthermore, electronic signature service providers must be educated in

the design and implementation of secure systems capable of withstanding
assaults and preventing data breaches. Finally, electronic signatures are es-
sential for current company activities, and their security must be addressed.
To guard against the risks and difficulties of the digital era and to ensure the
integrity and trustworthiness of electronic signatures, robust security mea-
sures and sufficient training are essential.
In conclusion, computer science is a critical field that has revolutionized

the modern world. However, with the widespread use of computer systems,
cybersecurity has become an increasingly pressing issue. Prioritizing cyber-
security is crucial to protect against the risks and challenges of the digital
age and to maintain the integrity and reliability of computer systems.
5
Chapter 1
Project background and scope
1.1 introduction
In this chapter, we will provide a comprehensive overview of the project.
First, we will introduce the host company, followed by an exploration of the
problem at hand and the proposed solution. To conclude, we will detail the
methodology that we will employ for this project.
1.2 Overview of the host company

1.2.1 Digitalberry Presentation
Digitalberry is a French company that focuses on IT security with a branch
located in Tunisia. Their main goal is to provide services such as certificate
management, electronic signature, legal archiving, and strong authentica-
tion. By prioritizing IT security, Digitalberry is committed to ensuring the
integrity and confidentiality of their clients data. With a presence in both
France and Tunisia, Digitalberry is well-positioned to provide their services
to a broad audience across multiple regions.
1.2.2 Organisational chart of the host company

In this section, we will present the organizational chart for Digitalberry’s
Paris office and its branch located in Tunisia.
6
CHAPTER 1. PROJECT BACKGROUND AND SCOPE
Figure 1.1: Digitalberry Tunis
1.3 Unveiling our Project: Insights and In-

novations
1.3.1 project background
This project is the culmination of our Bachelor’s degree in Computer Sci-
ence at the Faculty of Sciences in Tunis. In today’s world, technology has
revolutionized every aspect of our lives, leading to a digital transformation
that has eliminated the need for paper and pen. However, in Tunisia, we
have yet to fully embrace this technological revolution. To address this gap,
Digitalberry established a branch in our country with the aim of removing
paper from our daily lives. In pursuit of this goal, our project aims to develop
a digital signature solution that prioritizes security.
1.3.2 A look into the existing solutions

Despite the remarkable progress made in digitization, a significant number
of Tunisian administrations continue to rely on outdated paper and pen
methods for signing and verifying documents. Unfortunately, the existing
solutions in the country are not tailored to the needs of businesses and gov-
ernment entities, resulting in a lack of privacy and security. Notably, widely
used options like Tido and ngsign do not offer the necessary level of confi-
dentiality.
7
1.3.3 Criticizing the existing solution

Although ngsign offers a commendable user flow and robust security mea-
sures, it suffers from a significant drawback - frequent bugs. In my research,
I encountered a specific issue while attempting to sign a document using
ngsign. Despite receiving an email confirming successful signing, the up-
loaded document remained unaltered. Such technical glitches can discourage
users from utilizing these platforms. Another aspect that requires improve-
ment in ngSign is its login page. In my opinion, the user interface is subpar,
resulting in a lackluster experience. In most cases, users expect a straight-
forward ”Login” or ”Sign In” button for authentication. However, ngSign
deviates from this convention by using the term ”Authenticate.” Moreover,
the excessive white space on the page further hampers the overall visual
appeal.
By addressing these issues, ngsign can enhance its reliability and user
experience, ultimately attracting and retaining more users. Now, let’s talk
Figure 1.2: Login NgSign
8
about the dashboard. The design feels outdated, and in today’s world, users
expect a more visually appealing design to attract them. However, this is
not the case with ngSign, as the UI/UX falls short in the following areas:
• The color palette
• Excessive white space
• The signature form
Figure 1.3: NgSign signature form
Figure 1.4: NgSign Dashboard
9
When it comes to tido.tn, the landing page boasts an impressive UI design.

However, I encountered a challenge when attempting to access the services.
Unfortunately, I was unable to navigate to any other page or utilize any
service beyond the landing page. Despite the informative content provided,
including platform definitions, solutions, and statistics, clicking on any but-
ton consistently redirected me back to the home page. This behavior appears
unusual and disrupts the user experience.
To improve the usability of tido.tn, it is crucial to ensure that users can
seamlessly access the services and explore the various functionalities. By
addressing the issue of being stuck on the landing page, tido.tn can provide
a more satisfying and intuitive browsing experience, allowing users to fully
utilize the platform’s services and features.
1.3.4 Our solution

Our project is driven by the fundamental goal of resolving the previous issues
and developing a highly adaptable platform specifically designed for business
use. Our platform is dedicated to facilitating the acquisition of signatures
from specific agents as and when required. To achieve this, our solution
places utmost emphasis on the following crucial aspects:
• Design: We adhere to ergonomic principles to ensure an intuitive and

user-friendly UI/UX design. By prioritizing user experience, we aim
to enhance overall usability and make interactions with the platform
seamless and efficient.
• Performance: Our platform is optimized for exceptional performance,

enabling swift and smooth operations. We focus on minimizing re-
sponse times, reducing latency, and providing a highly responsive in-
terface to enhance productivity.
• Scalability: Recognizing the evolving needs of businesses, our plat-

form is built to scale effortlessly. It can accommodate increased user
demands and handle growing volumes of transactions without compro-
mising performance or stability.
• Resiliency: We prioritize building a robust and resilient platform that

can withstand unexpected challenges. By implementing redundancy,
fault tolerance mechanisms, and disaster recovery strategies, we ensure
uninterrupted service availability and data integrity.
10
Figure 1.5: Tido design 1
11
• Optimizing Business Functionality: Our platform is specifically tai-

lored to address the unique requirements of businesses. We offer com-
prehensive features and capabilities that streamline business processes,
automate workflows, and maximize efficiency.
1.4 Working methodology

To ensure optimal project management, it is crucial to select a methodology
that maximizes productivity and can adapt to evolving priorities and user
needs.
1.4.1 Agile approach

Agile project management methodology places a strong emphasis on team-
work, adaptability, and ongoing progress. The Agile Manifesto’s guiding
principles—which prioritize people and interactions, functional software, cus-
tomer collaboration, and adapting to change—form the foundation of this
system. Iterations and sprints, which are smaller, more manageable units
that enable frequent feedback and modification, are the primary unit of
measurement for agile projects. Also, the strategy places a high value on
openness and communication, encouraging team members to work closely
together and to candidly discuss successes and setbacks. Teams are able to
adjust swiftly to changes in requirements or priorities because to this collabo-
12
rative and iterative approach, which results in the quicker and more effective
delivery of high-quality goods or services.
1.4.2 Crystal approach

The Crystal approach is a family of agile methodologies that focus on adapt-
ing the project management process to the specific characteristics of the
project. Crystal methodologies recognize that different projects have differ-
ent needs and constraints, and therefore, they offer a set of methodologies
with varying levels of formality and control. The Crystal methodologies em-
phasize the importance of frequent communication, close collaboration, and
team empowerment.
The Crystal approach places great emphasis on people and their skills, as
well as the dynamic nature of projects. It promotes the idea that a small team
of highly skilled individuals can achieve remarkable results by leveraging their
expertise and working closely together. Crystal methodologies also prioritize
delivering working software frequently, ensuring that the project remains on
track and aligned with the customer’s needs.
1.4.3 Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method (DSDM) is an agile project
management framework that focuses on delivering business value in a timely
manner. It provides a structured and disciplined approach to project man-
agement, allowing for flexibility and adaptability to changing requirements.
DSDM is particularly suitable for projects with high business and time con-
straints.
DSDM follows an iterative and incremental development approach, di-
viding the project into manageable increments or timeboxes. Each timebox
has a fixed duration and aims to deliver a prioritized set of requirements.
Throughout the project, regular reviews and stakeholder involvement ensure
that the delivered product meets the evolving needs of the business.
DSDM also emphasizes collaboration and empowerment of the develop-
ment team. It encourages active participation from all stakeholders and
promotes effective communication and decision-making. By involving the
right people at the right time, DSDM aims to ensure that the project stays
aligned with business objectives.
13
1.4.4 Selection of Scrum

After considering various project management methodologies, including Crys-
tal and DSDM, we chose Scrum as our working methodology for several rea-
sons. First and foremost, Scrum aligns well with our project requirements
and team dynamics. Its emphasis on transparency, inspection, and adapta-
tion resonated with our goal of delivering a high-quality product that meets
the client’s needs.
Furthermore, Scrum’s iterative and incremental approach enables fre-
quent feedback and allows us to adapt to changing priorities or requirements
throughout the project. The regular sprint cycles and daily stand-up meet-
ings promote collaboration, communication, and accountability within our
team.
We also considered the popularity and widespread adoption of Scrum in
the industry. Its well-defined roles, ceremonies, and artifacts provide a clear
structure for project management, making it easier to onboard new team
members and ensure consistency in our approach.
In summary, Scrum’s compatibility with our project requirements, its
emphasis on collaboration and adaptability, and its widespread adoption in
the industry were the key factors that led us to choose Scrum as our working
methodology for this end-of-studies project.
Figure 1.8: Scrum
1.4.5 Scrum principle

The Scrum methodology complements what is referred to as the agile ap-
proach to project management – a means of “breaking down large projects
14
into more manageable tasks, which are completed in short iterations through-
out the project life cycle.” The Scrum framework relies on constant collab-
oration, so teams can easily complete a task within an allotted time before
moving on to the next project phase.
The group mindset and teamwork involved when players from a rugby
Scrum inspired the word’s use in the modern workforce. As a framework,
Scrum has its roots in the 1986 Harvard Business Review article “The New
New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka,
which advanced the idea that companies can achieve more by adopting “a
holistic method – as in rugby, the ball gets passed within the team as it
moves as a unit up the field.”
Scrum was further popularized in the early 1990s by Jeff Sutherland and
Ken Schwaber, who sought to expand and apply the concept to software
development. The pair have continued to update and publish their framework
and ideas in the Official Scrum Guide, which can be downloaded online.
In order to employ Scrum successfully, Sutherland and Schwaber argue,
those involved must adhere to five values: commitment, focus, openness,
respect, and courage.
“These values give direction to the Scrum team with regard to their work,
actions, and behavior,” the authors explain. “The decisions that are made,
the steps taken, and the way Scrum is used should reinforce these values, not
diminish or undermine them.”
When these values are embodied by the team, Sutherland and Schwaber
add, the pillars, or principles of Scrum “come to life building trust.”
The Six Principles of Scrum
• Control over the empirical process
In Scrum, the empirical process is based on observation of hard evidence
and experimentation rather than theory. There are three main ideas to
empirical process control: transparency, inspection, and adaptation.
• Self-organization
As the Scrum process relies on many individuals, self-organization is
essential. Everyone involved is empowered to work independently, and
the self-organization principle allows for greater buy-in among all par-
ties, while making it easier to assess individual contributions.
• Collaboration
Scrum is a collaborative process, as evidenced by the many roles in-
volved (more on that below). This principle also focuses on three di-
mensions of collaboration: awareness, articulation, and appropriation.
15
• Value-based prioritization
This principle involves organizing and prioritizing tasks based on their
value and how they need to be completed.
• Time-boxing
In Scrum, tasks are completed in “sprints,” with specific lengths of time
assigned to each one. Other elements, including “sprint planning” and
daily meetings, are also given specific start and stop times. This time-
boxing ensures that all involved know how much time is allocated to
each step, with the goal of eliminating wasted time and delays.
• Iterative development
This final principle speaks to the understanding that a project may need
to be refined multiple times during the development process. Iterative
development allows the team to make adjustments and manage change
easier..[1]
1.5 Conclusion
This chapter introduced Digitalberry’s project to develop a digital signa-
ture solution for Tunisia. Existing solutions were found lacking in privacy,
security, and user experience. To address these issues, our project focuses
on adaptability, design, performance, scalability, and business functionality
optimization.
Scrum methodology was chosen for effective project management, empha-
sizing collaboration, adaptability, and transparency. The principles of Scrum
will guide our project’s execution.
This chapter sets the stage for the following chapters that will delve into
project implementation details.
16
Chapter 2
Digital Trust and Security

Fundamentals
2.1 Introduction
The purpose of this chapter is to present the basic concepts and principles of
cryptography and public key infrastructure (PKI). It lets project personnel
and stakeholders to efficiently follow major occurrences by gathering, com-
piling, analyzing, and distributing theoretical knowledge.
2.2 Cryptography
2.2.1 overview
Cryptography is the art of keeping information secure by transforming it
into form that unintended recipients cannot understand. In cryptography,
an original human readable message, referred to as plaintext, is changed by
means of an algorithm, or series of mathematical operations, into something
that to an uninformed observer would look like gibberish; this gibberish is
called ciphertext [2].
2.2.2 Area of use

The cryptography domain got a large area of user in the IT ecosystem as
listed below :
a) Encryption and Keys
b) Digital Signatures and Message Authentication
17
CHAPTER 2. DIGITAL TRUST AND SECURITY FUNDAMENTALS
c) Cryptographic Hashes and Password Hashing

A cryptographic hash function is a function, H , that when applied on
a message, M , can be used to generate a fixed-length “fingerprint”
of the message. As such, any change to the message, no matter how
small, will change many of the bits of the hash value with there being
no detectable patterns as to how the output changes based on specific
input changes. In other words, any changes to the message, M , will
change the resulting hash-value in some seemingly random way. [3]
2.2.3 Security qualities

The main goal of cryptography is ti ensure some important features to guar-
antee a secure and high-quality IT environment.
• Confidentiality: information must only be available to authorized par-
ties.
• Integrity: information must remain consistent, trustworthy, and accu-
rate.
• Availability: information must remain accessible to authorized parties,
even during failures (with minimal or no disruption). [4]
2.3 Public key infrastructure(PKI)

2.3.1 Overview
Data security and privacy protection are at the core of most internet users’
concerns. Encryption is a fundamental security measure designed to pro-
tect data from unauthorized access. And public key infrastructure (PKI)
is perhaps the most common cryptography method. PKI involves a set of
physical components (computers and software or hardware cryptographic
equipment such as Hardware Security Module “HSM” or smart cards), hu-
man procedures (checks, validation), and software (system and application),
all of which issue and manage the life cycle of digital certificates or electronic
certificates.[5]
2.3.2 Components of the public key infrastructure

The PKI is generally composed of a certification authority, a registration
authority, and a central directory. Collectively, these components distribute
and validate certificates.
18
• Certification authority (CA): Issues certificates to users, computers,

and services and manages certificates. A certification authority signs
each certificate it issues with its own digital certificate.
• Registration authority (RA): The interface between the user and the
certification authority. It is responsible for identifying applicants or
certificate holders and ensuring that the certificate usage constraints
are met.
• Central Directory (CD): Responsible for storing digital certificates. It

centralizes and organizes the archiving of certificates. It also manages
the list of expired or revoked certificates (CRL) and makes public-key
certificates issued by the certification authority available to all users.[6]
2.3.3 Asymetric Key Ciphers

a) Overview
Asymmetric key cryptosystems / public-key cryptosystems use a pair
of mathematically linked keys: public key (encryption key) and pri-
vate key (decryption key). The asymmetric key cryptosystems pro-
vide key-pair generation (private + public key), encryption algorithms
(asymmetric key ciphers and encryption schemes , digital signature al-
gorithmsand key exchange algorithms.
• Key-pair generation: generate random pairs of private key + cor-

responding public key.
• Encryption / decryption: encrypt date by public key and decrypt
data by private key (often using a hybrid encryption scheme).
• igital signatures (message authentication): sign messages by pri-
vate key and verify signatures by public key
• Key-exchange algorithms: securely exchange cryptographic key
between two parties over insecure channel.[7]
source: https://www.techtarget.com/searchsecurity/definition/asymmetric-
cryptography
b) Public key cryptosystems

A public-key cryptosystem is a cryptographic system in which messages
encrypted with one key can only be decrypted with a second key, and
vice versa.2 RSA (Rivest–Shamir–Adleman) is the most widely used
public-key cryptosystem due to its difficulty of finding the prime factors
19
Figure 2.1: Asymetric encryption
of a composite number.0 Libsodium and Botan both use cryptographic

systems that require two different keys, linked together by some one-
way mathematical relationship.
• RSA cryptosystem: The idea of RSA is based on the fact that it is diffi-
cult to factorize a large integer. The public key consists of two numbers
where one number is a multiplication of two large prime numbers. And
private key is also derived from the same two prime numbers. So if
somebody can factorize the large number, the private key is compro-
mised. Therefore encryption strength totally lies on the key size and
if we double or triple the key size, the strength of encryption increases
exponentially. RSA keys can be typically 1024 or 2048 bits long, but
experts believe that 1024-bit keys could be broken in the near future.
But till now it seems to be an infeasible task.
source: https://www.geeksforgeeks.org/rsa-algorithm-cryptography/
• DSA cryptosystem: The Digital Signature Algorithm (DSA) is a public-
key cryptosystem and Federal Information Processing Standard for dig-
ital signatures, based on the mathematical concept of modular expo-
nentiation and the discrete logarithm problem. DSA is a variant of the
Schnorr and ElGamal signature schemes.
The National Institute of Standards and Technology (NIST) proposed
DSA for use in their Digital Signature Standard (DSS) in 1991, and
20
adopted it as FIPS 186 in 1994.[2] Four revisions to the initial spec-

ification have been released. The newest specification is: FIPS 186-4
from July 2013.[3] DSA is patented but NIST has made this patent
available worldwide royalty-free. A draft version of the specification
FIPS 186-5 indicates DSA will no longer be approved for digital signa-
ture generation, but may be used to verify signatures generated prior
to the implementation date of that standard.
• Elliptic Curve Cryptography (ECC): The Elliptic Curve Cryptography

(ECC) is modern family of public-key cryptosystems, which is based on
the algebraic structures of the elliptic curves over finite fields and on the
difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP).
ECC implements all major capabilities of the asymmetric cryptosys-
tems: encryption, signatures and key exchange. The ECC cryptogra-
phy is considered a natural modern successor of the RSA cryptosystem,
because ECC uses smaller keys and signatures than RSA for the same
level of security and provides very fast key generation, fast key agree-
ment and fast signatures.
source: https://cryptobook.nakov.com/asymmetric-key-ciphers/elliptic-
curve-cryptography-ecc
2.4 X509 certificate

2.4.1 overview
An X.509 certificate is a digital certificate based on the widely accepted In-
ternational Telecommunications Union (ITU) X.509 standard, which defines
the format of public key infrastructure (PKI) certificates. They are used to
manage identity and security in internet communications and computer net-
working. They are unobtrusive and ubiquitous, and we encounter them every
day when using websites, mobile apps, online documents, and connected de-
vices.
source: https://sectigo.com/resource-library/what-is-x509-certificate
2.4.2 Structure of a certificate

The X.509 standard is based on an interface description language known as
Abstract Syntax Notation One (ASN.1), which defines data structures that
can be serialized and deserialized in a cross-platform way. Leveraging ASN,
the X.509 certificate format uses a related public and private key pair to
21
encrypt and decrypt a message. It requires two parts: a data section and a
signature section as listed below:
source: https://sectigo.com/resource-library/what-is-x509-certificate
a) Data section
• Version Number: the version number of the X509 specification

supported by the certificate
• Serial number: it is a unique positive number assigned by the
authority certification.
• Issuer: it identifies the certification authority that signed and is-
sued the certificate.
• Validity period: contains the start and end period of validity of a
certificate
• Subject: This field contains information about the owner of the
certificate. You can find the distinguished name of the public
key holder, the name of the organization, the state in which the
certificate was issued.
• Public key: this field contains information on the algorithm used
and a representation of the certificate owner’s public
b) Signature section
• The signature of the certification authority: This field contains

the algorithm used by the certification authority to create the
certificate as well the signature itself.
2.5 Certificate Signing Request

2.5.1 Overview
A certificate signing request (CSR) is an encoded file containing information
about your website, service, organization, and domain name. This informa-
tion is used by a Certificate Authority (CA) to create an SSL/TLS certificate
for your website to encrypt traffic to your site. A certificate CSR also con-
tains your public key and signature, which helps to verify your identity and
secure communications to your site.
source: https://www.keyfactor.com/blog/what-is-a-certificate-signing-request-
csr/
22
2.5.2 Structure of a CSR

A certificate signing request contains information that will be included in the
certificate:
• Common Name: The fully qualified domain name.
• Organization: The legal name of your organization. This should not

be abbreviated and should include suffixes such as Inc, Corp or LLC.
• City/Locality: The city where your organization is located.
• State/Country/Region: The state/region where your organization is

located, this should not be abbreviated.
• Country: The two-factor letter ISO code for the country where your
organization is located.
• Email address: An email address used to contact your organization.
• Public key: The public key that will go into the certificate.
2.6 Digital Signature

2.6.1 overview
Digital signatures are like electronic “fingerprints.” They are a specific type
of electronic signature (e-signature).
In the form of a coded message, the digital signature securely associates
a signer with a document in a recorded transaction. Digital signatures use a
standard, accepted format, called Public Key Infrastructure (PKI), to pro-
vide the highest levels of security and universal acceptance. PKI involves
using a digital certificate for identity verification.
source: https://origin.docusign.com/how-it-works/electronic-signature/digital-
signature/digital-signature-faq
2.6.2 Production steps

Consider a scenario where Alice has to digitally sign a file or an email and
send it to Bob:
a) Alice selects the file to be digitally signed or clicks on ’sign’ in her email
application
23
b) The hash value of the file content or the message is calculated by Alice’s
computer
c) This hash value is encrypted with Alice’s Signing Key (which is a Pri-
vate Key) to create the Digital Signature.
d) Now, the original file or email message along with its Digital Signature
are sent to Bob.
e) After Bob receives the signed message, the associated application (such
as email application) identifies that the message has been signed. Bob’s
computer then proceeds to:
• Decrypt the Digital Signature using Alice’s Public Key

• Calculate the hash of the original message
• Compare the (a) hash it has computed from the received message
with the (b) decrypted hash received with Alice’s message.
f) Any difference in the hash values would reveal tampering of the mes-
sage.
Figure 2.2: Digital signature process
source: https://easy-software.com/en/newsroom/the-digital-signature-your-
electronic-signature/
24
2.7 Conclusion
In this chapter, I did a thorough theoretical examination of the project’s
digital trust domain. The purpose of this paper is to provide a clear and full
overview of the work that will be done.
25
Chapter 3
Sprint 0 : Planning and

architecture
3.1 Introduction
On the technological features of our project, this chapter will concentrate.
Its major goal is to direct us in comprehending the project’s architecture,
functional and non-functional needs, and identifying primary and secondary
actors. We will have developed a product backlog that will assist us in
breaking the project down into sprints at the end of this chapter.
3.2 Gaps and Opportunities: An In-Depth

Needs Analysis
To identify the precise criteria for pleasing the client, we will undertake a
needs analysis in this part. We will investigate the features and capabilities
that will be built into our platform to successfully meet these needs.
3.2.1
3.3 Meeting User Requirements: A Compre-

hensive Analysis of Functional and Non-
Functional Needs
A thorough study of both functional and non-functional needs will be done
in this section, along with the identification of the major parties engaged in
26
CHAPTER 3. SPRINT 0 : PLANNING AND ARCHITECTURE
our application.
3.3.1 major parties identification
Main actor
User: Users can submit requests for document signatures through our
platform, and such requests are subsequently routed to an administrator for
approval. Users can keep track of the status of their requests, including doc-
uments that have been accepted, denied, or signed. The website also allows
users to interact with administrators and receive notifications of any updates
or modifications to their requests.
Admin: Requests can be managed by administrators by approving or

rejecting document signatures. With the site, they may also interact with
users and view logs of all previous activities.
3.3.2 Identifying and Addressing Functional Needs

Now that we have identified the key stakeholders, we can move on to the
next step of the process and explore the functional needs of the platform.
Admin functionalities:
Manage CSR
• Admin can examinate, accept, reject, certificate signing requests
• Admin can create an X509 certificate for a document
Notifications
• Admin can be notified when a document signature request is created.
Manage Documents
• Admin can examinate certified document requests
27
• Admin can approve or reject certified document signature requests
User functionalities:
Send certification signing requests
• User can send document certification request.
• User can examinate the status of its document CSR requests
Send document signature request
• User can send document signature requests.
• User can examine the status of its requested document
• User can view its signed document and download it
Notifications
• User can receive notifications either its request is approved or declined
3.3.3 Identifying and Addressing Non-Functional Needs

What were once viewed as optional requirements have recently been become
necessary in order to win over clients. While some may still see these re-
quirements as optional, more and more people are beginning to understand
how important it is to address them. In order to build trust and uphold a
good reputation in today’s cutthroat business environment, companies must
put their consumers’ needs first. So, not meeting these needs could have
detrimental effects on a company’s success.
Performance
28
It is crucial to guarantee apps load quickly and steadily. In today’s fast-

paced digital environment, consumers have learned to expect nothing less
than quick and dependable performance, which can have a big impact on
the user experience. Thus, it is essential for developers to give loading time
optimization and crash risk reduction top priority. They can offer users a
seamless and gratifying experience in this way, which will ultimately enhance
engagement and client loyatlty.
Security
For our platform, the security and privacy of user data are of the highest
significance. It is our duty as developers to make sure that user data is stored
securely. We will put encryption techniques in place for user data kept in the
database to do this. By doing this, we hope to preserve our users’ confidence
in our services while also offering a safe and secure environment for them to
connect with our platform.
Availability
The application is only available with an internet connection.
Compatibility
The application is native, it’s compatible with any browser at any OS.
Ergonomy
To ensure conformity to human-computer interaction standards, a UI/UX

design that is suited to the user’s wants and preferences is required.[8]
3.4 Product backlog

the Product Backlog is an emergent, ordered list of what is needed to im-
prove the product. It is the single source of work undertaken by the Scrum
Team.
29
Figure 3.1: Ui-UX design
Product Backlog items that can be Done by the Scrum Team within one
Sprint are deemed ready for selection in a Sprint Planning event. They usu-
ally acquire this degree of transparency after refining activities. Product
Backlog refinement is the act of breaking down and further defining Product
Backlog items into smaller more precise items. This is an ongoing activity
to add details, such as a description, order, and size. Attributes often vary
with the domain of work.
The Developers who will be doing the work are responsible for the sizing.
The Product Owner may influence the Developers by helping them under-
stand and select trade-offs. Multiple Scrum Teams often work together on
the same product. One Product Backlog is used to describe the upcoming
work on the product.[9]
ID specifies the user story with a unique identifier.
User-Story specifies the user’s desired functionality.
Priority specifies the functionality importance
30
Use case ID User story Priority

Authentication 1.1 As a user I would like to be authenticated 0
As a user I would like to send a certificate
signing request
Manage Re- 2.1 As a user I would like to check the status of
quests (user) my requests
As a user I would like to send document sig- 0
nature requests
As a user I would like to check my certificate
As a user I would like to be notified when my
request is accepted, declined, or approved
Manage 3.1 As an admin I would like to make a request
Requests decision
(admin)
As an admin I would like to reject a request 0
As an admin I would like to check all the
requests
Notifications 4.1 As an admin I would like to be notified when
a new request is submitted
As a user I would like to be notified when a 0
request is approved
As a user I would like to be notified when a
request is declined
3.5 Dividing the project into Sprints

At a project management meeting, we agreed to divide our work into four
sprints in collaboration with the Scrum Master.
3.6 Global use case diagram

The planning phase analysis enabled us to construct a complete use case
diagram for our application. Figure 2.3 depicts our system’s behavior and
offers an overview of its components.
3.7 Application Architecture

In this section, we will discuss the architecture of our application, which
has been carefully designed to meet the functional requirements, backlog,
31
Figure 3.2: Use case
diagrams, and sprint divisions that we have established.
3.7.1 Microservice architecture

In our application, we have adopted a microservice architecture, which is an
architectural and organizational approach to software development. This ar-
chitecture decomposes the application into small, independent services that
communicate over well-defined APIs. Each microservice is owned and man-
aged by a self-contained team.
32
Figure 3.3: Microservice architecture
Microservices architectures offer several benefits, including scalability,

faster development, and the ability to enable innovation and accelerate time-
to-market for new features [10]. Each microservice can be developed, de-
ployed,
3.7.2 Three-tier architecture

For each microservice, we have chosen to implement the three-tier architec-
ture. This well-established software application architecture organizes appli-
cations into three logical and physical computing tiers: the presentation tier,
the application tier, and the data tier [11].
Figure 3.4: Three-tier architecture
Presentation layer: The presentation tier, located at the top level of

the application, is responsible for delivering content to the user interface,
33
such as CSS, HTML, or JavaScript. It provides a graphical user interface

(GUI) through which users can directly interact with the application. The
presentation layer communicates with other tiers by sending the results to
the browser and making API calls to interact with other layers.
Application tier: The application tier, also known as the business logic
or middle tier, processes the business logic of the application. It acts as a
bridge between the presentation layer and the data layer, facilitating faster
communication between the two. The application tier is typically imple-
mented using languages such as C sharp, Java, C, Python, or Ruby.
Data tier: The data tier consists of the persistent storage mechanism
and the data access layer. It handles the connection with the database and
performs operations such as insertions, updates, deletions, and data retrieval
based on input data [12].
3.7.3 Django MTV pattern

Our application’s architecture is built using Django, which follows the popu-
lar Model-View-Template (MTV) pattern. This pattern separates the appli-
cation logic into three distinct components: models, views, and templates.
Figure 3.5: Django MTV architecture
The models component represents the data and business logic of the
application. It defines the structure and behavior of the data, allowing for
easy manipulation and storage.
The views component handles user interactions and requests. It pro-
cesses the incoming requests, interacts with the models to retrieve or manip-
ulate data, and renders the appropriate response.
The templates component defines the presentation layer of the applica-
tion. It determines how the data is displayed to the user and provides the
necessary structure and formatting.
34
The MTV pattern within the context of Django ensures a clear separation
of concerns and promotes code reusability, making the development process
more organized and efficient.
3.8 Working Environment

This section will focus on presenting and familiarizing with the working en-
vironment.
3.8.1 Hardware Environment

For our project, we utilized two computers with the following specifications:
Computer:
• Brand: Lenovo
• Processor: Intel(R) Core(TM) i5-10300H CPU @ 2.20GHz
• RAM: 12.00 GB
• Storage: 1TB HDD 512 GB SSD
• Graphics Card: NVIDIA GeForce GTX 1650Ti 4GB
• Operating System: Ubuntu 22.04 LTS X64
3.8.2 Software Environment

Below is the list of software used to develop our application:
• Git: Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with
speed and efficiency. [15].
• Rabbitmq: RabbitMQ is one of the most popular open source message

brokers. From T-Mobile to Runtastic, RabbitMQ is used worldwide at
small startups and large enterprises. [16].
• Jira: Jira is a software application developed by the Australian soft-

ware company Atlassian that allows teams to track issues, manage
projects, and automate workflows. [17].
• Draw.io: draw.io is free online diagram software for making flowcharts,

process diagrams, org charts, UML, ER and network diagrams [18].
35
• Angular: Angular is a development platform that aims to make web

development feel effortless, focused on developer productivity, speed
and testability. Applications built with Angular can be deployed to
mobile devices and desktops as websites and native applications. [14].
• PyCharm Professional Edition: IDE designed for professional Python,

Web, and Scientific development [19].
• Webstorm: integrated development environment for JavaScript and

related technologies. Like other JetBrains IDEs, it makes your develop-
ment experience more enjoyable, automating routine work and helping
you handle complex tasks with ease. [20].
• Django Rest Framework: Django is a high-level Python web frame-

work that encourages rapid development and clean, pragmatic design.
Built by experienced developers, it takes care of much of the hassle
of web development, so you can focus on writing your app without
needing to reinvent the wheel. It’s free and open source. [21].
• Pip: pip is the package installer for Python. You can use it to install
packages from the Python Package Index and other indexes. [22].
• NPM: npm is the world’s largest software registry. Open source devel-
opers from every continent use npm to share and borrow packages, and
many organizations use npm to manage private development as well.
[23].
• Postgres: PostgreSQL is a powerful, open source object-relational

database system that uses and extends the SQL language combined
with many features that safely store and scale the most complicated
data workloads. The origins of PostgreSQL date back to 1986 as part
of the POSTGRES project at the University of California at Berkeley
and has more than 35 years of active development on the core platform.
[24].
• Adminer: dminer (formerly phpMinAdmin) is a full-featured database

management tool written in PHP. Conversely to phpMyAdmin, it con-
sist of a single file ready to deploy to the target server. Adminer is
available for MySQL, MariaDB, PostgreSQL, SQLite, MS SQL, Ora-
cle, Elasticsearch, MongoDB and others via plugin. [25].
• Swagger-UI: Swagger UI allows anyone — be it your development

team or your end consumers — to visualize and interact with the API’s
36
resources without having any of the implementation logic in place. It’s

automatically generated from your OpenAPI (formerly known as Swag-
ger) Specification, with the visual documentation making it easy for
back end implementation and client side consumption. [26].
• Overleaf: Overleaf is a collaborative cloud-based LaTeX editor used

for writing, editing and publishing scientific documents. [28].
• Docker: Docker takes away repetitive, mundane configuration tasks

and is used throughout the development lifecycle for fast, easy and
portable application development – desktop and cloud. Docker’s com-
prehensive end to end platform includes UIs, CLIs, APIs and security
that are engineered to work together across the entire application de-
livery lifecycle. [27].
3.9 Conclusion
This chapter has given us a comprehensive overview of our project. We were
able to identify the essential actors, evaluate the system’s functional and non-
functional needs, improve our product backlog, generate global diagrams, and
eventually choose the best architecture for the project.
37
Chapter 4
Sprint 1 : Authentication and

Registration
4.1 Introduction
In this chapter, we’ll look at our project’s first sprint. Our primary focus
will be on evaluating the use case and creating a detailed class diagram that
is specific to our authentication needs. We will present a final view of the
sprint release before the conclusion of this chapter, highlighting our efforts
and successes throughout this period of development. Therefore, be ready
for an amazing travel as we delve into the details of our first sprint!
4.2 Sprint backlog

This section describes all of the functions that will be addressed during this
sprint. These functionalities are given as user stories, which provide a full ex-
planation of the functionality to be developed. Tasks will also be allocated to
the development team to guarantee that each user story is completed swiftly
and successfully. Now, let’s go into the specifics of this part and make sure
we have a clear plan for the success of this sprint!
38
CHAPTER 4. SPRINT 1 : AUTHENTICATION AND REGISTRATION
ID Use case User story Task

1 As a user i would 1.1 0
like to be create an
account
like to login
like to change my
password
4.3 Analysing Sprint 1

During this part we will prepare our diagrams
4.3.1 Global use case diagram for sprint 1

The Figure 4.1 shows the use case diagram for Sprint 1.
Figure 4.1: Authentication use case
4.3.2 Description of the ”authenticate” use case

The following table is going to make a textual description for the authenti-
cation
39
Use case name Authenticate

Main actors Admin
User
Objective The user or the admin to access the applica-
tion
Pre-condition The user or the admin have to create an ac-
count and vertify it
The user or the admin needs an internet con-
nection
Post-condition Authenticated user
1- The user types its email and password
He clicks on the ”Login” button
Typical scenario 2 - The system verifies if all the fields are
clear and if the format is correct
3 - The system sends the params to the views
to verify them.
4 - The system displays the appropriate home
page for the user.
1- The user click on ”forgot password”
Alternative scenario 2 - The system asks the user to type his email
3 - The user types its email address then he
clicks on confirm
Exception scenario The system displays an error message to in-
form the user to reintroduce his data.
Figure 4.2: Textual description of the authenticate use case
4.3.3 Authentication sequence diagram

After presenting the refined use case and its textual description, we proceed
to showcase the corresponding sequence diagram.
40
Authentication
User JWT Service
Views Database
dispatch Authentication Request /auth

{"email": "email", "password": "password"
2 Authenticate user
3 User information
4 Token creation request
5 JWT Tokens for user
6 Authentication Response
{"access": "token1", "refresh": "token2"}
7 Request: [Authorization: JWT token1]

8 Validate the JWT
9 User authentication
12 Request: [Authorization: JWT token1] 8 Validate the JWT
14 Token expired
15 HTTP 401 {"error.jwt.expired"}
16 Refresh token:
{"refresh": "token2"}
17 Validate the Refresh Token
18 Retrieve user information
19 User information
20: Validate Refresh

Token with user secret
21 new Token
22 New Token
{"token": "token1"}
Figure 4.3: Authentication Sequence diagram
4.4 Implementation
In this section we are going to discuss the implementation of the Authenti-
cation with all its interfaces
4.4.1 Login and register interfaces

The figure 4.4 and 4.5 shows the login and register interfaces
41
Figure 4.4: Login page
Figure 4.5: Register page
42
4.5 Conclusion
In this chapter, we focused on the first sprint of our project, implementing au-
thentication and registration functionalities. We created diagrams, analyzed
the sprint, and discussed the implementation of authentication.
Overall, this chapter provided an overview of the sprint’s goals and ac-
complishments, setting the stage for further development.
43
Chapter 5
Sprint : Communication
between microservices
5.1 Introduction
In today’s interconnected world, web applications often rely on a microser-
vices architecture to enable scalability, flexibility, and efficient development.
Communication between microservices is a crucial aspect of such architec-
tures, and RabbitMQ, a popular message broker, plays a significant role in
facilitating this communication. This chapter explores the implementation
of RabbitMQ for inter-service communication during a Scrum sprint in a web
application.
5.2 RabbitMQ: Overview and Benefits

RabbitMQ is an open-source message broker that provides a reliable and flex-
ible messaging framework for distributed systems. It utilizes message queues
and exchanges to enable asynchronous communication between components
or services. RabbitMQ offers benefits such as fault tolerance, scalability,
and support for various communication patterns like publish/subscribe and
request/reply.
5.2.1 RabbitMQ mechanism

It is a lightweight messaging system that can be deployed on-premises or
in the cloud. Multiple messaging protocols are supported. To meet high-
scale, high-availability requirements, It can be deployed in distributed and
federated configurations.
44
CHAPTER 5. SPRINT : COMMUNICATION BETWEEN
MICROSERVICES
Producer, Exchange, Queue, and Consumer are the four main components
of RabbitMQ.
• Producer: Messages are pushed to exchanges by a producer. Messages
should not be sent at a rate that exceeds the Consumers’ ability to
process them. It’s also in charge of generating routing keys.
• Exchange: It is essentially a message routing rule. Binding is now
required for a message to travel to a queue or a different exchange from
the producers.
• Queue: It’s a storage buffer for messages. Queues are given names to
make it easier for applications to find them. Applications can choose
their queue names or ask the broker to do so. Because such names are
reserved by the broker for internal use, queue names can be up to 255
bytes of UTF-8 characters and cannot begin with ‘amq.’
• Consumer: It takes messages from the queues and reads them. A
pre-fetch limit is something that each customer can set (Otherwise
known as QoS limit). This value represents the maximum number
of unacknowledged messages the Consumer can handle at any given
time.[13]
Figure 5.1: Rabbitmq Queuing system
5.3 Sprint Planning and Goals

During the sprint planning phase, the team identified the need to improve
communication between microservices within the web application. The spe-
cific goals were defined, focusing on enhancing reliability, decoupling services,
45
MICROSERVICES
and ensuring efficient message delivery. User stories related to RabbitMQ in-
tegration were prioritized and selected for the sprint.
5.4 Digitalberry Approach

5.5 Company Approach: Internal Requests
and RabbitMQ
The company currently employs the internal requests approach using Python’s
import requests for inter-service communication in their projects. However,
after extensive research and efforts, it was proposed to introduce RabbitMQ
as a message broker to enhance communication between microservices. This
section presents a comparison between the two approaches to highlight the
benefits of incorporating RabbitMQ in the project.
Table 5.1: Comparison of Internal Requests and RabbitMQ for Inter-Service

Communication
Aspect Internal Requests with Im- RabbitMQ Message Broker
port Requests
Communication Style Synchronous and direct commu- Asynchronous and decoupled
nication between microservices communication through message
using RESTful APIs queues
Reliability Depends on availability of target Reliable message delivery, ac-
service, potential for temporary knowledgments, and fault toler-
unavailability ance
Scalability May struggle with increasing Efficient handling of high message
loads and high-frequency commu- volumes, scalability, and load bal-
nication ancing
Complexity Simple and easy to implement Additional setup and configura-
with familiarity in Python tion for RabbitMQ
5.5.1 Advocating for RabbitMQ Integration

After conducting thorough research and putting in significant effort, the team
successfully advocated for the adoption of RabbitMQ as the preferred mes-
sage broker for inter-service communication. The benefits offered by Rab-
bitMQ, including its asynchronous communication, reliability, scalability,
46
MICROSERVICES
and fault tolerance, convinced the team to embrace this change. The sub-
sequent sections will delve into the implementation details and the positive
impact it had on the project.
5.6 RabbitMQ Implementation

To implement RabbitMQ for inter-service communication, the team followed
a series of steps. First, they configured RabbitMQ by defining exchanges
and queues for message routing. Next, they integrated RabbitMQ libraries
into each microservice, allowing them to publish and consume messages. The
team established bindings between exchanges and queues to establish the de-
sired communication flow. Finally, they implemented error handling mecha-
nisms and ensured message reliability.
5.7 Sprint Execution and Challenges

During the sprint, the team worked collaboratively to implement RabbitMQ
for communication between microservices. They faced some challenges along
the way, such as handling message serialization/deserialization, ensuring mes-
sage ordering, and handling high message volumes. However, through regular
communication and agile adaptation, the team successfully overcame these
challenges and made progress towards their communication goals.
5.8 Conclusion
In conclusion, the successful implementation of RabbitMQ for communica-
tion between microservices during the Scrum sprint greatly enhanced the
web application’s performance and reliability. By leveraging RabbitMQ’s ro-
bust messaging capabilities, the team achieved their communication goals,
enabling efficient and decoupled interaction between services. The experi-
ence gained from this sprint will serve as a foundation for future iterations,
ensuring continuous improvement and seamless communication within the
web application.
47
Chapter 6
Sprint 2: Requests and

Signature
6.1 Introduction
In this chapter, we’ll look at our project’s second sprint. Our primary focus
will be on evaluating the use case and creating a detailed class diagram that
is specific to our authentication needs. We will present a final view of the
sprint release before the conclusion of this chapter, highlighting our efforts
and successes throughout this period of development. Therefore, be ready
for an amazing travel as we delve into the details of our second sprint!
6.2 Sprint backlog

This section describes all of the functions that will be addressed during this
sprint. These functionalities are given as user stories, which provide a full
explanation of the functionality to be developed. Tasks will also be allocated
to the development team to guarantee that each user story is completed
swiftly and successfully. Now, let’s go into the specifics of this part and
make sure we have a clear plan for the success of this sprint!
48
CHAPTER 6. SPRINT 2: REQUESTS AND SIGNATURE

like to be send
a certificate signing
request
like to send a doc-
ument signature re-
quest
like examine my re-
quest status
like to examine my
signed document
4 As an admin i 1.5 0
would like to either
accept or reject a
CSR
would like to either
accept or reject a
document signa-
ture request
would like to check
all certificate re-
quests
would like to check
all document sig-
nature requests
Figure 6.1: Signature microservice backlog
49
6.3 Analysing Sprint 2

6.3.1 Gloabal user case diagram for Sprint 2
Figure 6.2: Requests and signature use case
50
6.3.2 Description of the ”requests and signature” use

case
The following table is going to make a textual description for the authenti-
cation
Use case name Signature

Main actors Admin, User
Objective - User sends a document signature request.
- Admin accepts the request and signs the
document.
Pre-condition - User sends a request with the document to
be signed. - Admin creates a certificate for
the document.
Post-condition Document signed
Typical scenario 1. User enters title, description, common
name, and uploads the document. User clicks
”Send Request” button. 2. System verifies
the fields and format. 3. System sends the
parameters to the views for verification. 4.
System displays a toast confirming success-
ful request submission. 5. Admin clicks ”Ac-
cept” button for a specific CSR to create a
certificate. 6. Admin clicks ”Approve” but-
ton for a specific document request to sign it.
7. System verifies if a valid certificate exists
for the document. 8. System displays a toast
confirming successful document signing.
Alternative scenario - Admin clicks ”Reject” button for a specific
CSR or document request.
Exception scenario System displays an error message to inform
the user to re-enter their data.
Table 6.1: Textual description of the authenticate use case
51
6.3.3 Request and signature class Diagram

The upcoming figure will illustrate the sequence diagram for request signa-
ture.
Figure 6.3: Request and signature class diagram
6.3.4 Sequence diagram for requests and signature mi-

croservice
6.4 Implementation
6.4.1 Request and signature interfaces
Before we delve into the implementation details, let’s take a look at the inter-
faces involved in the request and signature processes. Figure 1 illustrates the
Requests interface, which facilitates the submission and management of vari-
ous requests. Figure 2 presents the Certificate requests interface, where users
can make specific requests for certificates. Finally, Figure 3 showcases the
Certifying document interface, which allows users to verify and certify docu-
ments. These interfaces play crucial roles in the overall system functionality
and workflow.
52
Figure 6.4: Requests Sequence Diagram
Figure 6.5: Signature sequence diagram
53
Figure 6.7: Certificate requests in-

Figure 6.6: Requests interface terface
54
6.5 Conclusion
This chapter focused on the second sprint of our project, which involved
implementing the functionality for requests and signatures. We presented the
sprint backlog, analyzed the use case, and provided a textual description of
the ”requests and signature” functionality. We also included a class diagram
to visualize the system’s structure and sequence diagrams to illustrate the
flow of actions during the implementation. Additionally, we discussed the
interfaces associated with the request and signature processes. Overall, this
chapter laid the groundwork for successful development and progress in our
project’s second sprint.
55
Chapter 7
Sprint 3:Notification and

dockerizing
7.1 Introduction
In this chapter, we will be discussing the sprint 3 of my project. This sprint
focused on two main tasks: realizing the notification system and dockerizing
the application. Both of these tasks were crucial steps towards improving
the reliability and scalability of my application. Join me as we dive into the
details of how we achieved these goals and the lessons we learned along the
way.
7.2 Sprint backlog

Before we dive into the details of how we realized the notification system, let’s
take a look at the sprint backlog for this task. The table below outlines the
specific tasks that were planned for this sprint, along with their corresponding
status and priority. This backlog served as a guide for our team as we worked
towards completing the notification system.
56
CHAPTER 7. SPRINT 3:NOTIFICATION AND DOCKERIZING

like to receive a
notification when a
decision is made for
my request
would like to re-
ceive a notification
when a new request
is created
like check my noti-
fications
Figure 7.1: Notification system backlog
7.3 Analysing sprint 3

7.3.1 Global user case diagram for Sprint 2
Figure 7.2: Use case diagram for authentication
57
7.3.2 Description of the notification use case

Now that we have seen the sprint backlog for the notification system, let’s
explore the use case in more detail. The table below provides a description
of the notification use case, including the actors involved, the main flow of
events, and the different scenarios that may occur.
Use case name notification

Main actors Admin
User
Objective The user receive a notification for a request
decision
The admin receives a notification when a new
request is created
Pre-condition The user have to send a request with the doc-
ument he wants to sign
The admin have own and admin role
Post-condition Notification received
1- The user types The title, description, com-
mon name and uploads the document
He clicks on the ”Send Request” button
Typical scenario 2 - The system verifies if all the fields are
clear and if the format is correct
3 - The system sends the params to the views
to verify them.
4 - The system displays a toast confirming
that the request is sent successfully.
5 - The system sends a notification to the
admin.
1 - The admin clicks on ”accept” or ”decline”
button for a specific request
Alternative scenario 1 - The system sends a notification to the
user to inform him that the decision for his
own request is made
Exception scenario The system displays an error message to in-
form the user to reintroduce his data.
Figure 7.3: Textual description of the authenticate use case
58
7.3.3 Notification class Diagram

In addition to the sprint backlog and use case, we also developed a class
diagram to help us better visualize the structure of the notification system.
The figure below presents the class diagram that we created. This diagram
helped us to identify the necessary classes and their relationships, and served
as a reference as we implemented the notification system.
Figure 7.4: Notification class diagram
59
7.4 Sequence diagram

7.5 Implemention
Figure 7.5: Stats interface
Figure 7.6: Notification interface
60
7.6 Dockerization
In addition to implementing the notification system, dockerization was a
key focus of Sprint 3. Dockerizing the application provided several benefits,
including improved portability, scalability, and consistency across different
environments. This section will outline the plan for dockerizing our applica-
tion.
7.6.1 Assessing Application Components

To begin the dockerization process, we first assessed the components and
dependencies of the application. This involved identifying the key services,
libraries, and configurations necessary for the application to run. As part
of this assessment, we generated a ‘requirements.txt‘ file for each microser-
vice using the ‘pip freeze‘ command. By executing ‘pip freeze ¿ require-
ments.txt‘, we obtained a comprehensive list of the required packages and
their corresponding versions for each microservice. This step ensured that
all the necessary dependencies were properly documented and could be easily
incorporated into the Docker images during the subsequent stages of dock-
erization.
7.6.2 Creating Dockerfile
Figure 7.7: Docker
61
Next, we will create a Dockerfile, which is a text file that contains instruc-
tions for building a Docker image. The Dockerfile will specify the base image,
define necessary dependencies, and set up the environment for running the
application.
7.6.3 Containerizing Services

We will containerize the different services and components of our application.
This may include the backend server, frontend client, and any additional
services or microservices. Each component will have its own Dockerfile and
will be built into a separate Docker image.
7.6.4 Defining Docker Compose Configuration

To simplify the management of multiple containers and their dependencies,
we will define a Docker Compose configuration file. Docker Compose allows
us to define and run multi-container applications using a YAML file. We
will specify the services, their dependencies, and any required environment
variables or network configurations.
Figure 7.8: One of our docker compose files
62
7.6.5 Building and Deploying Docker Images

Using the Dockerfiles and Docker Compose configuration, we will build the
Docker images for our application components. We will then deploy these
images to a container registry or a suitable hosting platform.
7.6.6 Testing and Validating Containers

Once the containers are deployed, we will perform testing and validation to
ensure that the application runs smoothly within the Docker environment.
This may involve running integration tests, checking for any compatibility
issues, and verifying that all services are functioning as expected.
7.6.7 Monitoring and Scaling

As part of the dockerization process, we will set up monitoring and scaling
mechanisms. We will explore tools and techniques for monitoring the con-
tainers’ performance, resource usage, and overall health. Additionally, we
will investigate strategies for scaling the application by adjusting container
instances based on demand.
By following this plan, we will successfully dockerize our application, lead-
ing to improved reliability, scalability, and ease of deployment across various
environments. Dockerization will enable us to package and isolate our appli-
cation’s components, ensuring consistency and simplifying the deployment
process.
7.7 Conclusion
In Sprint 3, we focused on implementing the notification system and docker-
izing the application. These tasks were crucial for improving reliability and
scalability.
We created a sprint backlog outlining specific tasks, analyzed the notifi-
cation use case, and developed a class diagram. During implementation, we
used sequence diagrams and provided screenshots of user interfaces.
In conclusion, Sprint 3 significantly enhanced our project’s reliability and
scalability through the implementation of the notification system and dock-
erization
63
Bibliography
[1] https://www.uagc.edu/blog/what-is-scrum.
[2] https://www.csoonline.com/article/3583976/what-is-cryptography-how-
algorithms-keep-information-secret-and-safe.html.
[3] https://textbook.cs161.org/crypto/hashes.html
[4] https://www.exabeam.com/explainers/information-
security/information-security-goals-types-and-applications/
[5] https://freemanlaw.com/pki-cryptography
[6] https://freemanlaw.com/pki-cryptography/
[7] https://cryptobook.nakov.com/asymmetric-key-ciphers
[8] https://www.mindinventory.com/blog/mobile-app-design-fundamentals-
ui-vs-ux/
[9] https://www.scrum.org/resources/what-is-a-product-backlog
[10] https://aws.amazon.com/microservices/
[11] https://www.finereport.com/en/product-functions/3-tier-
architecture.html
[12] https://www.finereport.com/en/product-functions/3-tier-
architecture.html
[13] https://hevodata.com/learn/rabbitmq-durable/
[14] https://opensource.google/projects/angular
[15] https://git-scm.com/
[16] https://www.rabbitmq.com/
64
BIBLIOGRAPHY
[17] https://www.productplan.com/glossary/jira/
[18] https://www.app.diagrams.net/
[19] https://snapcraft.io/pycharm-professional
[20] https://lp.jetbrains.com/webstorm-ide/
[21] https://www.djangoproject.com/
[22] https://pip.pypa.io/en/stable/
[23] https://docs.npmjs.com/about-npm
[24] https://www.postgresql.org/about/
[25] https://www.adminer.org/
[26] https://swagger.io/tools/swagger-ui/
[27] https://www.docker.com/
[28] https://en.wikipedia.org/wiki/Overleaf
65
Appendix A
Appendix
Figure A.1: Jira project workspace
66
APPENDIX A. APPENDIX
Figure A.2: RabbitMQ class
Figure A.3: RabbitMQ settings
Figure A.4: RabbitMQ producer
67
Figure A.5: RabbitMQ consumer

Figure A.6: Docker compose file
Figure A.7: Docker build
68
Abstract
The main objective of this graduation project is to build an electronic

Signature System which consists of a web application taking into
consideration the requirement and the needs of the host enterprise. These
applications allow admins to manage and track the Signature requests and
to keep track of their teams and projects, and users to create requests as
long as managing their documents and profiles in an easy and fast way. The
development of this application was achieved by using two frameworks,
Django for the server-side (Back-end) processing, Angular for the client-side
(Front-end) binding, RabbitMQ as a message broker, in addition to the
PostgreSQL database.
Resumé
L’objectif principal de ce projet de fin d’études est de construire un système

de signature électronique. système de signature électronique qui consiste en
une application web prenant en l’exigence et les besoins de l’entreprise hôte.
Ces applications permettent aux administrateurs de gérer et de suivre les
demandes de Ces applications permettent aux administrateurs de gérer et
de suivre les demandes de signature et de suivre leurs équipes et leurs
projets, et aux utilisateurs de créer des demandes de signature. de suivre
leurs équipes et leurs projets, et aux utilisateurs de créer des demandes
ainsi que de gérer leurs documents et leurs profils dans la base de données.
Les utilisateurs peuvent créer des demandes et gérer leurs documents et
leurs profils de manière simple et rapide. Le développement développement
de cette application a été réalisé en utilisant deux frameworks, Django pour
le traitement côté serveur (Back-end), Angular pour la liaison côté client
(Front-end), Rabbit pour le traitement côté client (Front-end). (Front-end),
RabbitMQ comme courtier de messages, en plus de la base de données
69
PostgreSQL. base de données PostgreSQL. arabic
g
éC
©J¯ñ ZAJK ñë @ Yë h Qj JË@ ¨ðQåÖÏ úæJKQË@
ø
YË@
JË@ ÐA¢ ú
Gð QºË@ PAêk . . .

¬YêË@
ñÖ Ï @ HAg
é . Ê¢JÓ èA«@QÓ PAJ.J«B@ ú¯ Y g AK
I.K
ð J
J.¢ áÓ
. AJ
Jk@ð HAJ JK
àñº
©J¯ñ Ê£ ©JKð èP@XAK á Ëð ñÒÊË
®ÊÓð
HA
JË@ HAJ . . .
®J
J.¢JË@ iÒ ZBñë
HA . é®J
Ö Ï @
àðQK á ÓYj JÖÏ @ð , ÑêªK PAÓð
J Ó
ÑîE@Y
YK
AÖÏ A£ ÕæAK. HAJ . Ê£ ZA B

Ñê¯Q¯ ©J.JË
QK ñ¢ Õç' È@ . éªK
Ð@Yj JAK. J
J.¢JË@ @ Yë
Qåð éÊîD

é®K Q¢ éJ j Ë@

.
ÑîEA ®ÊÓð

ÉJ
ÒªË@ I.KAg . áÓ QÊÆK@ , ( éJ
®Ê m Ì '@ éK
AîDË@)
ÐXAm Ì '@ IKAg
. . ém.Ì 'AªÖÏ ÁKQå , áK
PA£@

K. èY«A¯ úÍ@ é¯A B
KAJ AK. , ÉKAP ¡Jñ» < áJJ« , ¡ QË@ ( éJ ÓAÓ B@
HA
. . .
éêk. @ñË@)

. ýæQÂ
J«
70

Aziz Guebsi February 2023

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

Aziz Guebsi February 2023

Uploaded by

Document Information

Original Title

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

Aziz Guebsi February 2023

Uploaded by

Copyright:

Available Formats

pfe

1 Project background and scope 6

2 Digital Trust and Security Fundamentals 17

2.5 Certificate Signing Request . . . . . . . . . . . . . . . . . . . . 22

3 Sprint 0 : Planning and architecture 26

4 Sprint 1 : Authentication and Registration 38

5 Sprint : Communication between microservices 44

6 Sprint 2: Requests and Signature 48

7 Sprint 3:Notification and dockerizing 56

Furthermore, electronic signature service providers must be educated in

In conclusion, computer science is a critical field that has revolutionized

Project background and scope

1.2 Overview of the host company

1.2.2 Organisational chart of the host company

Figure 1.1: Digitalberry Tunis

1.3 Unveiling our Project: Insights and In-

1.3.2 A look into the existing solutions

1.3.3 Criticizing the existing solution

Figure 1.2: Login NgSign

• The color palette

• Excessive white space

• The signature form

Figure 1.3: NgSign signature form

Figure 1.4: NgSign Dashboard

When it comes to tido.tn, the landing page boasts an impressive UI design.

1.3.4 Our solution

• Design: We adhere to ergonomic principles to ensure an intuitive and

• Performance: Our platform is optimized for exceptional performance,

• Scalability: Recognizing the evolving needs of businesses, our plat-

• Resiliency: We prioritize building a robust and resilient platform that

Figure 1.5: Tido design 1

Figure 1.6: Tido design 2

Figure 1.7: Tido design 3

• Optimizing Business Functionality: Our platform is specifically tai-

1.4 Working methodology

1.4.1 Agile approach

1.4.2 Crystal approach

1.4.3 Dynamic Systems Development Method (DSDM)

1.4.4 Selection of Scrum

Figure 1.8: Scrum

1.4.5 Scrum principle

Digital Trust and Security

2.2.2 Area of use

a) Encryption and Keys

b) Digital Signatures and Message Authentication

c) Cryptographic Hashes and Password Hashing

2.2.3 Security qualities

2.3 Public key infrastructure(PKI)

2.3.2 Components of the public key infrastructure

• Certification authority (CA): Issues certificates to users, computers,

• Central Directory (CD): Responsible for storing digital certificates. It

2.3.3 Asymetric Key Ciphers

• Key-pair generation: generate random pairs of private key + cor-

b) Public key cryptosystems

Figure 2.1: Asymetric encryption

of a composite number.0 Libsodium and Botan both use cryptographic

adopted it as FIPS 186 in 1994.[2] Four revisions to the initial spec-

• Elliptic Curve Cryptography (ECC): The Elliptic Curve Cryptography