MULTI-FACTOR REMOTE AUTHORIZATION

OF BUSINESS TRANSACTION

By

Areeba Nazir

2018-GCUF-05270

Project submitted in partial fulfillment of the

requirements for the degree of

BACHELOR OF SCIENCE
IN
INFORMATION TECHNOLOGY

DEPARTMENT OF INFORMATION TECHNOLOGY GC

UNIVERSITY, FAISALABAD.

August 2022
 DECLARATION

The work reported in this thesis was carried out by me under the supervision of Mr. AFZAAL
HUSSAIN Department of Information Technology GC University, Faisalabad, Pakistan.

I hereby declare that the title of my thesis MULTI-FACTOR REMOTE AUTHORIZATION

OF BUSINESS TRANSACTION and the contents of the thesis are the product of my own
research and no part has been copied from any published source (except the references,
standard mathematical or genetic models /equations /formulas/protocols, etc.). I further
declare that this work has not been submitted for any other degree /diploma award. The
University may take action if the information provided is found inaccurate at any stage.

Signature of the Student

Areeba Nazir

2018-GCUF-05270

ii
 CERTIFICATE BY SUPERVISORY COMMITTEE

We certify that the contents and form of a thesis submitted by Miss. Areeba Nazir Registration
No: 2018-GCUF-05270. Has been Found satisfactory and in accordance with the prescribed
format. We recommend it to the processor the evaluation by the External Examiner for the
award the of Degree.

Signature of Supervisor ………………….

Name.……………………………..………
Designation with stamp………………….

Member of Supervisory Committee

Signature …………….. ………………….

Name.……………………………..………

Designation with stamp………………….

Member of Supervisory Committee

Signature …………….. ………………….

Name.……………………………..………

Designation with stamp………………….

Chairperson

Signature …………….. ………………….

Name.……………………………..………

Designation with stamp………………….

iii
 DEDICATED

TO

My Graceful and Polite PARENTS

&

All Family Members

Who lives in my mind and soul

Whose love is more precious

Then pearls and diamonds

Who are those whom I say my own

Whose love will never change

Whose prayers will never die

iv
 ACKNOWLEDGEMENTS

All praise to ALMIGHTY ALLAH, the most merciful and the most compassionate and
his Holy Prophet ‘MUHAMMAD’(Peace) be upon him) the most perfect and exalted among
and even born on the surface of earth, who is, forever a torch of guidance and knowledge for
the humanity as a whole.

The work presented in this manuscript was accomplished under the inspiring guidance,
gorgeous assistance, constructive criticism, and enlightened supervision of Mr. Afzaal Hussain
Department of Information Technology GC University, Faisalabad for his skillful guidance,
constructive criticism, masterly advice, valuable suggestions, and sympathetic behavior for the
completion of this manuscript.

I feel highly privileged to take this opportunity to express my heartiest gratitude and
deep sense of indebt to my worthy supervisory committee, Dr. Sheraz Malik and Mr.Tahir
Abdullah Department of Information technology GC University, Faisalabad under whose kind
and scholastic guidance, keen interest and constant encouragement.

Words are very important to convey thoughts and thanks, the words are impossible to
find to thank our Father and whole family for their prayers and encouragement for us and for
our work.

Finally, I apologize if I have caused anger of offence to anybody and the errors that
remain in the manuscript are mine alone.

AREEBA NAZIR

v
 TABLE OF CONTENTS

Chapter 1 .................................................................................................................................. 13

SOFTWARE REQUIREMENT SPECIFICATION ............................................................ 13

1.1 Introduction ........................................................................................................... 13

1.2 Multi-Factor Remote Authorization of Business Transaction ............................... 13

1.3 Modern security-based applications ...................................................................... 13

1.4 Problem statement ................................................................................................. 14

1.5 Solution.................................................................................................................. 14

1.6 Tools and technology............................................................................................. 14

1.7 Scope ..................................................................................................................... 15

1.8 Business goals........................................................................................................ 15

1.9 Limitation .............................................................................................................. 16

Chapter 2 .................................................................................................................................. 17

SOFTWARE PROJECT MANAGEMENT PLAN ............................................................. 17

2.1 Scope and reference ............................................................................................... 17

2.2 Software project management plan ....................................................................... 17

2.3 Evolution of SPMP ................................................................................................ 18

2.4 Reference material ................................................................................................. 18

2.5 Project plan ............................................................................................................ 18

2.6 Process model ........................................................................................................ 19

2.7 Managerial process ................................................................................................ 20

2.8 Technical Process .................................................................................................. 21

2.9 Methods, tools, and techniques............................................................................. 22

2.10 Software Documentation .................................................................................. 22

Chapter 3 .................................................................................................................................. 23

SOFTWARE REQUIREMENT SPECIFICATION ............................................................ 23

vi
 3.1 Project overview .................................................................................................... 23

3.2 Project scope .......................................................................................................... 23

3.3 Specification requirements ................................................................................... 23

3.4 Software Product Features ..................................................................................... 24

3.5 System major module ............................................................................................ 25

3.6 System mode.......................................................................................................... 25

3.7 System functions.................................................................................................... 26

3.8 Non - functional requirements ............................................................................... 28

3.9 Functional Requirements ....................................................................................... 30

Chapter 4 .................................................................................................................................. 31

SOFTWARE ANALYSIS AND DESIGN DESCRIPTION ............................................... 31

4.1 Project relevancy, feasibility ................................................................................. 31

4.2 Project activities .................................................................................................... 31

4.3 System specifications ............................................................................................ 33

4.4 System design ........................................................................................................ 33

4.5 System architectural .............................................................................................. 34

4.6 Detailed description of components ...................................................................... 35

4.7 Data flow ............................................................................................................... 38

4.8 Entity relationship diagram .................................................................................. 40

Chapter 5 .................................................................................................................................. 41

SOFTWARE TESTING ...................................................................................................... 41

5.1 Testing ................................................................................................................... 41

5.2 Unit testing ............................................................................................................ 41

5.3 System testing ........................................................................................................ 41

5.4 Acceptance testing ................................................................................................. 41

5.6 Black box testing ................................................................................................... 41

5.7 System overview.................................................................................................... 41

vii
 5.8 Test Approach........................................................................................................ 42

5.9 Test Plan ................................................................................................................ 42

5.10 Test Case ............................................................................................................ 44

5.11 Test Case Results ............................................................................................... 46

Chapter 6 .................................................................................................................................. 47

TOOLS AND TECHNOLOGES ......................................................................................... 47

6.1 Testing and technologies ....................................................................................... 47

6.2 Angular .................................................................................................................. 47

6.3 Angular material .................................................................................................... 48

6.4 MySQL .................................................................................................................. 48

6.5 SpringBoot Java ..................................................................................................... 49

6.6 Spring Security ...................................................................................................... 50

6.7 JSON Web Token .................................................................................................. 50

6.8 Rest Client Api (Application programming interface) .......................................... 53

6.9 OAuth 2 ................................................................................................................. 54

6.10 Android .................................................................................................................. 55

6.11 Biometric ............................................................................................................... 55

Chapter 7 .................................................................................................................................. 56

MANUAL ............................................................................................................................ 56

7.1 Index ...................................................................................................................... 56

7.2 Registration ............................................................................................................ 56

7.3 Registered User...................................................................................................... 57

7.4 Login ...................................................................................................................... 57

7.5 Dashboard .............................................................................................................. 58

7.6 Profile .................................................................................................................... 58

7.7 Business transaction .............................................................................................. 59

7.8 Page Not Found ..................................................................................................... 59

viii
7.9 Biometric authentication........................................................................................ 60

7.10 Application login ............................................................................................... 61

7.11 App Dashboard .................................................................................................. 62

7.12 Business transaction ........................................................................................... 63

7.13 Final business transaction .................................................................................. 64

ix
 LIST OF TABLE

Table 2.1: Phase plan ............................................................................................................... 18

Table 2.2: Release .................................................................................................................... 19

Table 2.3: Management Objective and priorities ..................................................................... 21

Table 5.1: Feature to be Tested with Description .................................................................... 42

Table 5.2: Login ....................................................................................................................... 43

Table 5.3: Test Case 1 .............................................................................................................. 43

Table 5.4: Test Case 2 .............................................................................................................. 44

Table 5.5: Test Case for Login................................................................................................. 44

Table 5.6: Final Test Case........................................................................................................ 46

x
 LIST OF FIGURE

Figure 2.1: Scrum Lifecycle..................................................................................................... 20

Figure 4.1 System Architecture ............................................................................................... 34

Figure 4.2: System Interface Description ................................................................................ 35

Figure 4.3: Use Case Model for User Login ............................................................................ 35

Figure 4.4: Flow of Spring Security JWT ................................................................................ 36

Figure 4.5: Data Flow ............................................................................................................. 39

Figure 4.6 Entity Relationship Diagram .................................................................................. 40

Figure 6.1: JSON Web Token .................................................................................................. 53

Figure 7.1: Index page ............................................................................................................. 56

Figure 7.2: Registration page ................................................................................................... 56

Figure 7.3: Registered User ..................................................................................................... 57

Figure 7.4: Login page ............................................................................................................. 57

Figure 7.5: Dashboard page ..................................................................................................... 58

Figure 7.6: Profile page ............................................................................................................ 58

Figure 7.7: Business transaction page ...................................................................................... 59

Figure 7.8: Page Not Found ..................................................................................................... 59

Figure 7.9: Biometric Authentication ...................................................................................... 60

Figure 7.10: App login page .................................................................................................... 61

Figure 7.11: App Dashboard page ........................................................................................... 62

Figure 7.12: Business Transaction ........................................................................................... 63

Figure 7.13: Final Business Transaction .................................................................................. 64

xi
 ABSTRACT

We ought to provide a remote authorization solution by supporting remote

authorization of business transactions through mobile devices that support biometric
functionality. This will not only reduce cost for the MFA solution available in market
now a day but will also make ease for the end-user to allow transactions remotely from
his mobile. Our solution encounters two aspects of modern security based applications.

1- Multi Factor Authentication of business applications.

Conventionally multifactor authentication involves authenticating the user by
his username/password as One Factor and Email/SMS OTPs as Second Factor. Both
when combined are taken as Multifactor or 2Factor authentication. This conventional
multifactor authentication has drawbacks like it requires user to have access to Email
and SMS at all times in order to gain access to the system or perform any secure activity
that is sensitive operation consider by the system itself.
2 – Remote biometric authorization of users on the go without requiring them
to provide any kind of OTPs. Which will result in streaming of business transaction on
your behalf.

xii
 Chapter 1
SOFTWARE REQUIREMENT SPECIFICATION
1.1 Introduction
Basically multi-factor remote authorization is a multi-module solution base project which
means it has huge work on the backend side. We use Adobe standard for remote authorization.

Here we demonstrate of Multi-Factor Remote Authorization as the name is MFRA. It

consists of the following modules:

1 – Web Application (Java Spring Boot)

2 – Mobile Application (Android)

1.2 Multi-Factor Remote Authorization of Business Transaction

Business transactions in any solution are defined by business applications themselves. A
business application is any application that integrates with our solution. These can be Banking
Applications, Notary Applications etc. and business transaction is any transaction that this
business thinks is radical for their process. e.g. In a Banking application, sending some amount
from one person’s account to another person’s account is considered one transaction. Likewise,
in the notary application, signing a document is considered a business transaction.

1.3 Modern security-based applications

Our solution encounters two aspects of modern security-based applications.

Multi-Factor authentication of business applications. Conventionally multifactor

authentication involves authenticating the user by his username/password as One Factor and
Email/SMS OTPs as Second Factor. Both when combined are taken as

Multifactor or 2Factor authentication. This conventional multifactor authentication has

drawbacks like it requires users to have access to Email and SMS at all times in order to gain
access to the system or perform any secure activity that is sensitive operation considered by the
system itself.

13
 Remote biometric authorization of users on the go without requiring them to provide
any kind of OTPs. Which will result in the streaming of business transactions on your behalf.

1.4 Problem statement

Most of the business transactions performed on websites are secured by verification of

end-user Email/SMS/Biometric as multi-factor authentication commonly known as MFA in
which the user’s biometrics is verified through biometric tokens attached to the desktop or laptop.

This requires biometric devices to be physically available with the User all the time
attached to the computer or laptop on which the transaction is performed. Not to mention that it
requires biometric device maintenance, care and cost as well.

1.5 Solution

We ought to provide a remote authorization solution to this problem by supporting remote

authorization of business transactions through mobile devices that support biometric
functionality. This will not only reduce the cost of the MFA solution available in the market
nowadays but will also make it easy for the end-user to allow transactions remotely from his
mobile.

1.6 Tools and technology

The following tools and technologies are used in the project.

1.6.1 Tools

 Web Editor (Visual Code)

 Web Browser (Chrome, Firefox and etc.)
 Server (SpringBoot)
 Mobile Editor (Android Studio)

1.6.2 Technologies

 Angular
 Material Angular

14
  MySQL (Database)
 SpringBoot Java
 Spring Security
 DOM (Document Object Model)
 JSON web token
 Rest Client Api (Application programming interface)
 Jwt Oauth2
 Android
 Biometric

1.7 Scope

The scope of this project is very broad in terms of multi-factor remote authorization of the
business transaction. There are two major scopes are following:

1.7.1 Development scope

 User authentication on web and mobile applications

 Initiation of business transactions

 Sending push notifications to android device

 Authorization of business transaction upon biometric authorization

1.7.2 Testing scope

 Test cases of web and mobile applications

1.8 Business goals

1.8.1 Target market

 Banking Applications

 Notary Applications

15
1.8.2 First year goals

 Integration with at least two banks.

1.9 Limitation
The limitation of MFRA is the Internet, which is a necessary condition for testing.

16
 Chapter 2
SOFTWARE PROJECT MANAGEMENT PLAN
2.1 Scope and reference
This project aims to design a system that manages the user security and authenticates the
user then secures the business transaction. The objectives of the study are as follows:

i. Register the user

ii. Authenticate the user on web that generates JSON web token then login
iii. User able to do a transaction which status is pending
iv. Authenticate the user on android that generate JSON web token then login
v. Push notification of transaction
vi. User able to accept or decline the transaction
vii. Status of transaction is change with android application
viii. If the user accepted, then user able to download or proceed to the other user

2.2 Software project management plan

Following are the software management plans

2.2.1 Project overview

We define Multi-Factor Remote Authorization (MFRA) of business transaction is
basically an authenticated the user and allow the user to do transaction.

 User can authenticate ourselves

 User can do transaction
 User use biometric authentication for android application then proceed the transaction

2.2.2 Project deliverable

 SRS (Software Requirement Specification)
 SPMP (Software Project Management Plan)
 SDD (Software Design Document)
 SQAP (Software Quality Assurance Plan)
 STD (Software Testing Documentation)
 SOW (Statement of Work)

17
  PCP (Project Communication Plan)

2.3 Evolution of SPMP

The plan is a dynamic document and will be updated on regular basis according to the
project by default and on an unscheduled basis as needed. All project teams will be notified of the
updates to the plan via e-mail according to the Reporting Plan. Once the initial plan is finalized,
a baseline of the plan will be created. Changes to the plan will take place against this baseline.
The plan will only receive further baselines if a meaningful change in scope occurs.

2.4 Reference material

 MS Project files
 WBS (Work Breakdown Structure)
 MS Visio
 Postman

2.5 Project plan

Following is the detail about the planning phase of this project:

2.5.1 Phase plan

Project Phase Time Allocated Achievement Criteria

Requirement

Requirement 4 Weeks 28 Days

Design 4 Weeks 25 Days

Code 5 Weeks 32 Days

Testing 2 Weeks 10 Days

Implementation 2 Weeks 10 Days

Table 2.1: Phase plan

18
2.5.2 Releases

SPMP To document the agreed deliverables and dates

SQAP To document the quality activities

SRS To document the agreed requirements with the project

supervisor to provide the basis for design and system test.

SDD To document the design and design decisions to provide the

basis for implementation and unit test

STD To document how the software will be tested and record the
results.

WORKING Working software fulfilling all functional and quality

requirements

SOFTWARE USER To document the description of Instructions for hands-on

MANUAL users of the software

POSTMORTEM REPORT To describe the Individual Reflections on Degree Project

Table 2.2: Release

2.5.3 Budget
No Budget because no external hardware and software were purchased.

2.6 Process model

The methodology chosen to develop this system is the scrum model approach. I opted for
this method because I found that it is the best for my project where the stages involved can assist
my level of progress. Many developers prefer the scrum and widely use it as a development
strategy. The scrum model approach is chosen because the approach allows the development of
the system to be revised after the stages are finished. Once the stages are not satisfied, then going
back to the previous stages can be considered necessary to add or modify any features.

19
 Figure 2.1: Scrum Lifecycle
Scrum lifecycle is a number of consecutive steps and iterative stages that should be
performed during the realization of any Scrum project. The iterative approach is the main
principle of the m lifecycle. The work on a Scrum project is subdivided into segments called
Sprints. The project develops from one sprint to another until the final product is ready. Each
sprint cycle is subdivided into several consecutive stages that it must pass from the
beginning till the end. Scrum methodology also includes more specialized lifecycles like the
testing life cycle and the defect life cycle.

2.7 Managerial process

Management objectives and priorities

A flexibility model helps communicate what dimensions of the project are fixed,
constrained, and flexible

20
 Project Dimensions Fixed Constrained Flexible

Cost X

Schedule X

Scope X

Table 2.3: Management Objective and priorities

2.7.1 Assumptions, dependencies, and constraints
 Given that the project is part of a course requirement, it is assumed that adequate
funding is provided
 There exists sufficient time to complete the project.
 Since there is no involvement of trade secrets or other proprietary information no non
- disclosure agreements must be signed.
 The project must be completed by September 2022. must include an operational
system, appropriate documentation, and a final presentation. Due to this time
constraint, it may not be possible to complete the extra desired functionality.
 Team members need to train in the programming languages and environments chosen.
 Scheduling conflicts between the clients and team members may lead to difficulties.

2.7.2 Risk management

The risks in the project that we may have to face in the future will be identified and
managed to remove or mitigate risks.

2.7.3 Risk identification

 Scheduling conflicts between the team members
 Team members may not be experienced

2.8 Technical process

This section specifies the technical methods, tools, and techniques to be used on the project
It also includes identification of the work products and reviews to be held and the plans for the

21
support group activities in user documentation, training, software quality assurance, and
configuration management.

2.9 Methods, tools, and techniques

The following tools, techniques, and standards are used for developing the project:

2.9.1 Development environment

The Whole Project is developed using angular spring boot and android.

2.9.2 Target environment

It is a Module -Based Project so it can only be run when there is an internet connection on
Personal Computers.

2.9.3 Programming language

Using SpringBoot built-in functions and SpringBoot built-in libraries.

2.9.4 Development standards

We are using IDE which is Integrated Development Environment.

2.9.5 Documentation standards

We are using adobe standard for remote authorization (Cloud Signature Consortium) for
Software project management plans.

2.10 Software documentation

 Software documentation provides the work products to be built for this project and
the types of pee reviews to be held for those products.
 To ensure that the implementation of the software satisfies the requirements, the
following documentation is required as a minimum:
o Software Requirement Specification (SRS)
o Software Design Description (SDD)
o Software Test Plan

22
 Chapter 3
SOFTWARE REQUIREMENT SPECIFICATION
3.1 Project overview
This project aims to design a security system that will replace the present manual system.
The objectives of the study are as follows:

3.1.1 Signing application

A business application implemented in Java and Angular initiates the user's business
transaction. It implements Adobe standard for remote authorization (Cloud Signature
Consortium) and communicate with mobile application.
3.1.2 Mobile application
Authorization Application contains an authorization encryption asymmetric key pair for
the user to authorize any business transaction initiated by the above signing application.
3.2 Project scope
The scope of this project is very broad in terms of other manually security application

 User authentication on web and mobile applications

 Initiation of business transactions
 Sending push notifications to android device
 Authorization of business transaction upon biometric authorization
3.3 Specification requirements
This section will give the requirements that are used to guide the project's software design,
implementation, and testing.

3.3.1 Hardware interfaces

 Processor– i7
 Memory – 16 GB RAM
 512 KB Cache Memory
 Hard disk 16 GB

3.3.2 Software interface

 `Operating System Windows

23
  Front- End Angular
 Back-End Spring Boot
 Web Server Tomcat
 Application Android Studio

3.3.3 Communication interface

As it is mentioned that the solution, we are providing is a module-based solution,
therefore, a business application implemented in Java and Angular that initiates the business
transaction for the user. It implements Adobe standard for remote authorization (Cloud Signature
Consortium) and communicate with mobile application.

3.3.4 Memory constraints

The memory constraint applies in this project are as following

3.3.4.1 Primary memory

RAM must be 4GB or greater

3.3.4.2 Secondary memory

Secondary memory must be 40GB or greater and an external 120GB hard drive for
backups on daily basis.

3.3.5 Operation
Operations are categorized into two types:

 Multi Factor Authentication of business applications.

 Remote biometric authorization of users on the go without requiring them to provide
any kind of OTPs.
3.4 Software Product Features
A feature is a prominent characteristic or something added as a special attraction. The
functionality of a product usually means the extent of its overall ability. However, it can
sometimes mean the same thing as function, i.e., Feature is a useful function within a computer
application or program.

Features or functional requirements for this system are given below:

24
3.4.1 Website panel
 Register: This requirement enables a user to register a new user on the website.
 Login: The user should have a username and password to login into the website.
 Profile: This enables users to view their personal information.
 Transaction: This enables the user to do a transaction on a document, download it if
the admin accepts it, transaction if the admin declines the transaction, and delete it.

3.4.2 Application panel

 Login: The user should need a biometric to login into the application.
 Dashboard: This enables the notification of transaction here the user accepts or
declines the transaction

3.5 System major module

Following is the list of Major modules of this project and their functionalities:

3.5.1 Module 1 (Signing Module)

A business application implemented in Java and Angular initiates the user's business
transaction. It implements Adobe standards for remote authorization (Cloud Signature
Consortium) and communicates with a mobile application.
3.5.2 Module 2 (Mobile Module)
Authorization Application contains authorization encryption asymmetric key pair for the
user to authorize any business transaction initiated by the above signing application.
3.6 System mode
The system has the following modes:
3.6.1 Normal mode
In normal mode, the System will allow access for the usage of all the proposed functions.
3.6.2 Intermediate
 Register User.
 Login User
 Manage Business Transaction
 Login the User on the Android app then proceed with the business transaction

25
3.6.3 Objects:
Users and administrators that manage the security
3.7 System functions
Following are the system functionalities of this project
3.7.1 Validity checks on the inputs
Validity checks are the following
3.7.1.1 Login:
The system shall allow the user to log in only when the user provides a valid username
and password.

3.7.1.2 Create profile

The system shall create a user profile before allowing the user to update the details.

3.7.1.3 Delete event

The system shall allow the user to delete a transaction if it the declined.

3.7.1.4 View transaction

The system shall allow the user to download and view the document if the transaction is
accepted on the mobile application.

3.7.2 Exact sequence of operations

This project has multiple functions, all of which have their importance but the core
functionality of this project is the ability that it provides its user to do a secure business transaction
and manage the security.

3.7.3 Responses to abnormal situations, including

3.7.3.1 Overflow
The system shall not allow login if the active number of users is more than the server's
active user limit

3.7.3.2 Communication facilities

If a registered user cannot log in or forgets their password, he /she can contact the
administration via email/phone call.

26
3.7.3.3 Error handling and recovery
Error handling and recovery will be done in the maintenance phase.

3.7.3.4 Effect of parameters

Error parameters will be set by testers

3.7.3.5 Relationship of outputs to inputs, including

 Inputs will be taken through input functions and constraints
 Input formulas will be implemented in the functions

3.7.4 Performance requirements

 Number of terminals to be supported: server limit
 Number of simultaneous users to be supported: 200 users
 Amount and type of information to be handled.

3.7.5 Logical database requirements

During the login authentication process at the login page, a username and password are
required. Both are string variables that are defined at the time of registration and stored in a
database where the user username shall be unique, and the password can be later changed by the
user if applicable.

3.7.6 Design constraints

The system will support major browsers such as Firefox Mozilla, Google Chrome, Opera
with Html 5 JavaScript, and jQuery support. The system should have enough space minimum
space of 100 MB at the server machine where the website is hosted.

3.7.7 Standards compliance

W3school is the standard way of web development, its naming convention is followed
throughout the development process.

3.7.8 Software system attributes

System Requirement attributes are given below:

3.7.8.1 Reliability
The System will assure login facility effectively with all working modules regarding the
reservation.
27
3.7.8.2 Availability
The system must be always available.

3.7.8.3 Maintainability
The system should be completely remote administrable. This means that system statistics
(average transaction time, current active sessions, number of sessions processed in last
3ur/day/month) and system functions (start/ stop system, reboot system, restart services, etc.)

3.7.8.4 Portability
 Percentage of components with the host-dependent code: 0 to 5 %
 Percentage of code that is host-dependent: 0 to 5 %
 Use of a particular operating system: Widows

3.7.8.5 Software limitations

At this point, it’s not viable for this system to purchase professional web hosting services.
Because of this, the file must be used for the persistence of data to be used by the webserver,
instead of persisting the data to a DBMS. Another limitation is the use of a web server instead of
an application server.

3.7.8.6 Environmental
The client-side will run on any environment which supports a web browser. The server-
side environment will not be a concern to the clients and can be upgraded/changed as necessary,
without affecting the clients.

3.7.8.7 Transferability / conversion

There are no transferability concerns for the client - side. The server side should be
designed in such a manner so that the system can be transferred to a different web hosting service
without affecting day-to-day operations.

3.7.8.8 Scalability
The system shall be designed so that it can easily be scaled to increase performance
(response time). This means that the various tiers can be running on different processors.

3.8 Non - functional requirements

The non - functional requirement of the project is as: -

28
3.8.1 User interface
Our Desktop Application has a formal and decent look, does not have any shocking colors
each written thing is prominent and well-managed. The instructions given are easy and have a
clear meaning. Form instruction is all about to related form and only performs only that form.

3.8.2 Fast response time

Using this Website in case of entering data, the system shall respond fast and relative to
the content.

3.8.3 Ease of use

It is easily understandable and easy to use ADMIN PANEL and USER PANEL.

3.8.4 Ease of learning

We provide the complete documentation of this project that is helpful for the users of this
project that how to use this product.

3.8.5 Understandability
We should use understandable icons and buttons that will be self-explanatory, and the
interface of the App is not complex.

3.8.6 Speed and latency

 The system is reliable
 It will be available for 24 hours for the user
 It will be accurate
 It will be reusable
 It will be understandable
 It will be flexible
 It will be testable

3.8.7 Longevity
We are using a spring environment along with an MYSQL Database that is easily
understandable, and has flexible tools so our system will perform its working to the maximum of
its capacity.

29
3.9 Functional Requirements
List of Functional Requirement

 Registration
 Login
 Profile
 Transaction
 Transaction record

30
 Chapter 4
SOFTWARE ANALYSIS AND DESIGN DESCRIPTION
4.1 Project relevancy, feasibility
The feasibility study for the project is:

4.1.1 Technical feasibility

Building this system is technically feasible. The hardware and software needed are all
available, it not difficult to get them. The brief I can say the necessary resources needed for the
development and maintenance of the system are available. I am going to use java programming
languages and databases.

4.1.2 Operationally feasibility

The project I am developing is operationally feasible as there is no need for users to have
good knowledge of computers before using them. The user can learn and use the system with
easiness he just needs to read the manual or tutorial from the developers.

4.1.3 Economic feasibility

Besides being technically feasible, developing this system is economically feasible as
well. The development of the system does not require the developers to spend a lot of money.
The tools I will be using to develop the system are not expensive and the software's open source.
All I need is time. Even the maintenance of the system will not be expensive. The system is
indeed economically feasible.

4.2 Project activities

To give solutions to problems in the industry, a software developer or a team of developers
must incorporate a development strategy that encompasses the process, methods, and tools
layers, and generic phases. This strategy is often referred to as a process model or a software
developing paradigm. A process model for software development is chosen based on the nature
of the project and application, the methods, and tools to be used , and the controls and
deliverables that are required. All software development can be characterized as a problem-
solving loop in which distinct stages are encountered. Regardless of the process model that is
chosen for a software project, all the stages coexist simultaneously at some level of detail.

31
4.2.1 Planning
The purpose of this phase is to determine the best solution and steps taken to develop the
system. Planning involves detailed planning for the timing of the working progress and the types
of techniques that will be taken next. Planning also involves the methodology that will be going
to use for this project.

4.2.2 Requirement analysis

The purpose of this phase is to build a logical model of this system. In addition, this phase
is also needed to understand the applications, fact-finding techniques like document reviews,
surveys, observations, and sampling must be made to identify application requirements, software
requirements, and hardware requirements. In this phase, what kind of data requirement and the
functional requirement will be decided.

4.2.3 Design
This phase will produce a draft of the system architecture and the prototype of the
application that will satisfy all requirement analyses. At this phase, the user interface and all
necessary input and processes will be identified. This phase also determines the application
architecture, which is going to show how to transform the logical design into basic system coding
to generate the prototype of the system. The result of this phase is the application interface and
system design specification. For this project, the design will be created using Java Net beans.

4.2.4 Implementation
During this implementation phase, the system will be constructed. All codes are generated
inside this phase. At the end of this phase, the system should run and most of the functions of the
system should be able to use. Based on the previous phase, from the prototype, the system will
become the first version inside this phase.

4.2.5 Testing
This phase will evaluate or verify the system that was developed. This phase will have
simulation data that will simulate the true database for the system. This is to test the functionality
of the system in comparing captured data with a database. Besides, all the functionality that may
cause errors or problems to the system must be specified inside this phase because the result of

32
the system is a very high priority and importance. However, the testing phase will only cover
overcoming the problem statement and the system objectives.

4.3 System specifications

The major requirement of this project is:

Hardware requirements:

 Processor i7
 Memory 8 GB RAM
 512 KB Cache Memory
 Hard disk 16 GB

Software requirements:

 Operating System: Windows

 Web - Technology: Angular
 Front-End: Angular material, Bootstrap
 Back-End: MySQL
 Web Server: Tomcat.

4.4 System design

This document is adopted from the Adobe standard for remote authorization.

4.4.1 Design overview

To fully document all the aspects of the architecture, the Software Design Document
contains the following subsections.

 System Architectural Design

o Chosen System Architecture
o Detailed Description
o System Interface Description
 Detailed Description of Components
o Use Case Diagram
o Flow of Spring Security JWT

33
4.5 System architectural
Design System architectural design describes as:

4.5.1 System architecture

A three - tier architecture was chosen to allow the interface to be changed independent of
application/business/business logic and to allow the data storage technology to be changed
without impacting the application / business logic layer.

Figure 4.1 System Architecture

4.5.2 Detailed description
A detailed description of Architectural design is:

Presentation tier

The presentation layer is directly concerned with the end - user. End-user performs his
actions using this layer. It contains the components dealing with user interface and user
interactions.

Logic tier

Also called the middle tier, logic tier, business logic, or logic tier, this tier is pulled from
the presentation tier. It controls application functionality by performing detailed processing.

Data tier

The data layer contains the data access components and database. Database access
components are objects providing access to underlying database tables, reading values from tables
into objects, storing values, etc.

34
4.5.3 System interface description

Figure 4.2: System Interface Description

4.6 Detailed description of components
A detail description of the diagram is:

4.6.1 Use case model for user login

A use case diagram is a graphic depiction of the interactions among the elements of a
system. A use case is a methodology used in system analysis to identify, clarify, and organize
system requirements.

Figure 4.3: Use Case Model for User Login

35
4.6.2 Flow of Spring Security JWT
You can have an overview of our Spring Boot Security JWT example with the diagram
below:

Figure 4.4: Flow of Spring Security JWT

Now I will explain it briefly.
4.6.2.1 Spring Security
WebSecurityConfigurerAdapter is the crux of our security implementation. It
provides HttpSecurity configurations to configure cors, csrf, session management, rules for
protected resources. We can also extend and customize the default configuration that contains the
elements below.

UserDetailsService interface has a method to load User by username and returns

a UserDetails object that Spring Security can use for authentication and validation.

UserDetails contains necessary information (such as: username, password, authorities) to

build an Authentication object.

UsernamePasswordAuthenticationToken gets {username, password} from login

Request, AuthenticationManager will use it to authenticate a login account.

AuthenticationManager has a DaoAuthenticateProvider (with help of

UserDetailsService & PasswordEncoder) to validate UsernamePasswordAuthenticationToken

36
object. If s successful, AuthenticationManager returns a fully populated Authentication object
(including granted authorities).

OncePerRequestFilter makes a single execution for each request to our API. It provides
a doFilterInternal() method that we will implement parsing & validating JWT, loading User
details(using UserDetailsService),checking Authorization

(using UsernamePasswordAuthenticationToken).

AuthenticationEntryPoint will catch authentication error.

Repository contains User Repository & RoleRepository to work with Database, will be
imported into Controller.

Controller receives and handles request after it was filtered by OncePerRequestFilter.

AuthController handles signup/login requests

Security: we configure Spring Security & implement Security Objects here.

 WebSecurityConfig extends WebSecurityConfigurerAdapter

 UserDetailsServiceImpl implements UserDetailsService
 UserDetailsImpl implements UserDetails
 AuthEntryPointJwt implements AuthenticationEntryPoint
 AuthTokenFilter extends OncePerRequestFilter
 JwtUtils provides methods for generating, parsing, validating JWT

Controllers handle signup/login requests & authorized requests.

 AuthController: @PostMapping(‘/signup’), @PostMapping(‘/signin’),

@PostMapping(‘/signout’)

Repository has interfaces that extend Spring Data JPA JpaRepository to interact with
Database.

 UserRepository extends JpaRepository<User, Long>

 RoleRepository extends JpaRepository<Role, Long>

37
 Models defines two main models for Authentication (User) & Authorization
(Role). They have many-to-many relationship.

 User: id, username, email, password, roles

 Role: id, name

Payload defines classes for Request and Response objects

We also have application.properties for configuring Spring Datasource, Spring Data JPA
and App properties (such as JWT Secret string or Token expiration time).

4.7 Data flow

Data Flow Diagram is a way of representing a flow of a data of a system or process. It

provides information about the input and output of each entity and the process itself. It has no
control flow, there are no decision and no loops. Data flow diagram is a part of the structured
analysis.

38
Figure 4.5: Data Flow

39
4.8 Entity relationship diagram
An entity relationship diagram (ERD) shows the relationships of entity sets stored in a
database. An entity in this context is an object, a component of data. By defining the entities their
attributes, and showing the relationships between them , an ER diagram illustrates the logical
structure of databases

Figure 4.6 Entity Relationship Diagram

40
 Chapter 5
SOFTWARE TESTING
5.1 Testing
Software testing can be stated as process of verifying and validating that a software or
application is bug free, meets the technical requirements as guided by its design and development
and meets the user requirements effectively and efficiently with handling all the exceptional and
boundary cases . It mainly aims measuring specification, functionality performance of a software
program or application. Software testing is done during the development process. Software testing
involves the execution of software component to evaluate one or more properties, testing stages
of the project can be explained as below, and system was tested for all these stages.

5.2 Unit testing

System was tested individual units or components of a software. The purpose is to validate
that each unit of software code performs as expected.

5.3 System testing

Testing of complete system was done to evaluate system compliance with the specified
requirements.

5.4 Acceptance testing

System is tested for acceptability. The purpose of these test is to evaluate the system
compliance with the business requirements and access whether it is acceptable for delivery.

5.6 Black box testing

In this testing examine the functionality of an application without peering into its internal
structures or workings. The software into which known inputs are fed and where known outputs
are expected is termed a black box testing.

5.7 System overview

System consists of many features and these features are a prominent characteristic or
something added as a special attraction. The functionality of a product usually means the extent
of its overall ability. However, it can sometimes mean the same thing as function, i.e. Feature is

41
a useful function within a computer application or program. Features or functional requirements
for this system are given below:

 Register: This requirement enables user to register on the website.

 Login: User should have id and password to login into Website.
 Logout: When user don't want to use application anymore, he must sign out his account
so that no one else can use it.
 Admin Panel: Admin can manage complete website using its admin panel.

5.8 Test Approach

Test case procedures will be created and followed Procedure will consist of several steps
and all steps will be performed. If the result is a desired output, test will be passed. There will be
a pass / fail test criterion. Many low priority test cases can be executed using a small number of
resources. A lower priority test is a pre- requisite of another higher priority test e.g. an expensive
and high priority usability test might necessitate many of the inexpensive low priority navigational
tests to have passed.

5.9 Test Plan

The following is the list of areas to be focused on during testing of the project. Here the
scenario is that the person should be able to login to the age and emotion recognition system with
the correct password and user #id.

Req # Module Name Roles Description

Req1 Register User A user can register their account for login

Req1 Login and User A user can login and logout from the system using the
logout login page of the system

Table 5.1: Feature to be Tested with Description

We now what condition we have for a login page we said it as technical requirement
document (TRD).

The technical requirement Document (TRD) is as under.

42
LOGIN

T1 Username must not be empty.

T2 User password must not be empty.

T3 If the username and user password are correct , then login

Table 5.2: Login

Step 1: Our Test Case is

“Verify Login, when correct Username and Password are entered, it should log in
successfully "

No# TR Test Case Test Step Test Data Result

1 T3 Verify 1. Open the login Username=areeba Login

Login page Successful
Password=areeba
2. Enter
Username
3. Enter the
password
4. Click to login

Table 5.3: Test Case 1

Step 2: We identify the Technical Requirement that this case is verifying. For our test case, the
technical requirement is T3 is being verified.

T3 is our technical requirement in which we decide that if the username and password is correct
then the user login to the system

Step 3: In this step, we Note this Technical Requirement (T3) in the Test Case

Step 4: Identify the Requirement for which this TR (Technical Requirement - T3) is defined We
noted the as it was the requirement which is checked.

Step 5: In this step, we Note the (Requirement) in Test Case.

43
 No# TR Test Case Test Step Test Data Result

1 T3 Verify 1. Open the login Username=ahmed Login

Login page Successful
Password=ahmed
2. Enter
Username
3. Enter the
password
4. Click to login

Table 5.4: Test Case 2

Step 6: Do all the steps above for all your test cases and extract the result.

Development environment will be used for all testing.

5.10 Test case

Test Case for verifying the requirement:

Test Case: TC-01 Test Case Name Log In

System: Module Based System Sub System:

Designed By: Areeba Design Date :

Executed By Areeba Execution Date:

Brief Description : This case enables the user admin to log in the system .

Table 5.5: Test Case for Login

Operatin Window 10 Environment: Module Based(Web & App)
g System:

Software Angular , Spring Boot , MySQL, Android.

Tools:

44
Steps Strateg Action Inpu Case Actual Expected Status Remar
y(Test t Result ks
Result
to Pass)
/(Test to
fail)

T-T –P /
T-T-
F

1 T-T-P Login User Empt Please Please Pass

the name y Enter a Enter a
Websit Valid Valid
e Userna Usernam
me e

2 T-T-P Login Pass Empt Please Please Pass

to the word y Enter a Enter a
Online Valid Valid
Intelle Passw Password
ctual ord
Materi
al

3 T-T-P Login Pass If Please Please Pass

to the word Wro Enter Enter
Online ng Passw Password
Intelle Pass ord
ctual word
Materi
al

45
 Submi
ssion

4 T-T-P Login Emai If Please Please Pass

to the l incor Enter Enter
Online rect Userna Usernam
Intelle User me e
ctual name
Materi
al
Submi
ssion

Table 5.6: Final Test Case

5.11 Test Case Results
 Sees the requirements that guided its design and development.
 Retorts correctly to all types of inputs.
 Achieves its functions within an acceptable time.
 Is suitably usable.
 Can be installed and run in its planned environments.
 Attains the general result.

46
 Chapter 6
TOOLS AND TECHNOLOGES
6.1 Testing and technologies
In this project we used the following techniques. We will discuss each briefly.

Frontend (Website):

 Angular
 Material Angular
Database:
 MySQL
Server:
 SpringBoot Java
 Spring Security
 DOM (Document Object Model)
 JSON web token
 Rest Client Api (Application programming interface)
 Jwt Oauth2
Application
 Android
 Biometric

6.2 Angular
Angular is a development platform, built on TypeScript. As a platform, Angular
includes:

 A component-based framework for building scalable web applications

47
  A collection of well-integrated libraries that cover a wide variety of features,
including routing, forms management, client-server communication, and more
 A suite of developer tools to help you develop, build, test, and update your code

With Angular, you're taking advantage of a platform that can scale from single-developer
projects to enterprise-level applications. Angular is designed to make updating as straightforward
as possible, so take advantage of the latest developments with a minimum of effort. Best of all,
the Angular ecosystem consists of a diverse group of over 1.7 million developers, library authors,
and content creators.

6.3 Angular material

Angular Material is a User Interface (UI) component library that developers can use in
their Angular projects to speed up the development of elegant and consistent user interfaces.
Angular Material offers you reusable and beautiful UI components like Cards, Inputs, Data
Tables, Date pickers, and much more.

Each component is ready to go with default styling that follows the Material Design
Specification. Nonetheless, you can easily customize the look and feel of Angular Material
components. The list of available Angular Material components continues to grow with each
iteration of the library.

6.4 MySQL
In regard to the general definition, MySQL is an open-source relational database
management system (RDBMS) with a client-server model. RDBMS is a software or service
used to create and manage databases based on a relational model. Now, let’s take a closer
look at each term:

6.4.1 Database
A database is simply a collection of structured data. Think of taking a selfie: you push
a button and capture an image of yourself. Your photo is data, and your phone’s gallery is
the database. A database is a place in which data is stored and organized. The word
“relational” means that the data stored in the dataset is organized as tables. Every table relates
in some way. If the software doesn’t support the relational data model, just call it DBMS.

48
6.4.2 Open source
Open source means that you’re free to use and modify it. Anybody can install the
software. You can also learn and customize the source code to better accommodate your
needs. However, The GPL (GNU Public License) determines what you can do depending on
conditions. The commercially licensed version is available if you need more flexible
ownership and advanced support.

6.4.3 Client-server model

Computers that install and run RDBMS software are called clients. Whenever they
need to access data, they connect to the RDBMS server. That’s the “client-server” part.

MySQL is one of many RDBMS software options. RDBMS and MySQL are often
thought to be the same because of MySQL’s popularity. A few big web applications like
Facebook, Twitter, YouTube, Google, and Yahoo! all use MySQL for data storage purposes.
Even though it was initially created for limited usage, it is now compatible with m any
important computing platforms like Linux, macOS, Microsoft Windows, and Ubuntu.

6.5 SpringBoot Java

Spring Boot provides a good platform for Java developers to develop a stand-alone and
production-grade spring application that you can just run. You can get started with minimum
configurations without the need for an entire Spring configuration setup.

Advantages

 Spring Boot offers the following advantages to its developers −

 Easy to understand and develop spring applications
 Increases productivity
 Reduces the development time

Goals

Spring Boot is designed with the following goals −

 To avoid complex XML configuration in Spring

 To develop a production ready Spring applications in an easier way
 To reduce the development time and run the application independently

49
  Offer an easier way of getting started with the application

6.6 Spring Security

Spring Security is a powerful and highly customizable authentication and access-control
framework. It is the de-facto standard for securing Spring-based applications.

Spring Security is a framework that focuses on providing both authentication and

authorization to Java applications. Like all Spring projects, the real power of Spring Security is
found in how easily it can be extended to meet custom requirements

Features

 Comprehensive and extensible support for both Authentication and Authorization

 Protection against attacks like session fixation, clickjacking, cross site request forgery.
 Servlet API integration
 Optional integration with Spring Web MVC

6.7 JSON Web Token

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and
self-contained way for securely transmitting information between parties as a JSON object. This
information can be verified and trusted because it is digitally signed. JWTs can be signed using a
secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to also provide secrecy between parties, we will focus
on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while
encrypted tokens hide those claims from other parties. When tokens are signed using
public/private key pairs, the signature also certifies that only the party holding the private key is
the one that signed it.

6.7.1 Use:
Here are some scenarios where JSON Web Tokens are useful:

6.7.1.1 Authorization:
This is the most common scenario for using JWT. Once the user is logged in, each
subsequent request will include the JWT, allowing the user to access routes, services, and

50
resources that are permitted with that token. Single Sign On is a feature that widely uses JWT
nowadays, because of its small overhead and its ability to be easily used across different domains.

6.7.1.2 Information Exchange:

JSON Web Tokens are a good way of securely transmitting information between parties.
Because JWTs can be signed—for example, using public/private key pairs—you can be sure the
senders are who they say they are. Additionally, as the signature is calculated using the header
and the payload, you can also verify that the content hasn't been tampered with.

6.7.2 Structure:
In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which
are:
 Header
 Payload
 Signature
Therefore, a JWT typically looks like the following.

xxxxx.yyyyy.zzzzz

Let's break down the different parts.

6.7.2.1 Header
The header typically consists of two parts: the type of the token, which is JWT, and the
signing algorithm being used, such as HMAC SHA256 or RSA.

For example:

{
"alg": "HS256",
"typ": "JWT"
}
Then, this JSON is Base64Url encoded to form the first part of the JWT.

6.7.2.2 Payload
The second part of the token is the payload, which contains the claims. Claims are
statements about an entity (typically, the user) and additional data. There are three types of
claims: registered, public, and private claims.

51
 An example payload could be:

{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
The payload is then Base64Url encoded to form the second part of the JSON Web Token.

Do note that for signed tokens this information, though protected against tampering, is
readable by anyone. Do not put secret information in the payload or header elements of a JWT
unless it is encrypted.

6.7.2.3 Signature
To create the signature part you have to take the encoded header, the encoded payload, a
secret, the algorithm specified in the header, and sign that.

For example if you want to use the HMAC SHA256 algorithm, the signature will be
created in the following way:

HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
The signature is used to verify the message wasn't changed along the way, and, in the case
of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it
is. Putting all together

The output is three Base64-URL strings separated by dots that can be easily passed in
HTML and HTTP environments, while being more compact when compared to XML-based
standards such as SAML.

52
 The following shows a JWT that has the previous header and payload encoded, and it is
signed with a secret.

Figure 6.1: JSON Web Token

6.8 Rest Client Api (Application programming interface)

REST is a set of architectural constraints, not a protocol or a standard. API developers can
implement REST in a variety of ways.

When a client request is made via a RESTful API, it transfers a representation of the state
of the resource to the requester or endpoint. This information, or representation, is delivered in one
of several formats via HTTP: JSON (Javascript Object Notation), HTML, XLT, Python, PHP, or
plain text. JSON is the most generally popular file format to use because, despite its name, it’s
language-agnostic, as well as readable by both humans and machines.

Something else to keep in mind: Headers and parameters are also important in the HTTP
methods of a RESTful API HTTP request, as they contain important identifier information as to
the request's metadata, authorization, uniform resource identifier (URI), caching, cookies, and
more. There are request headers and response headers, each with their own HTTP connection
information and status codes.

In order for an API to be considered RESTful, it has to conform to these criteria:

 A client-server architecture made up of clients, servers, and resources, with requests

managed through HTTP.
 Stateless client-server communication, meaning no client information is stored between
get requests and each request is separate and unconnected.
 Cacheable data that streamlines client-server interactions.

53
  A uniform interface between components so that information is transferred in a
standard form. This requires that:
o resources requested are identifiable and separate from the representations sent to the
client.
o resources can be manipulated by the client via the representation they receive
because the representation contains enough information to do so.
o self-descriptive messages returned to the client have enough information to describe
how the client should process it.
o hypertext/hypermedia is available, meaning that after accessing a resource the client
should be able to use hyperlinks to find all other currently available actions they can
take.
 A layered system that organizes each type of server (those responsible for security, load-
balancing, etc.) involved the retrieval of requested information into hierarchies,
invisible to the client.
 Code-on-demand (optional): the ability to send executable code from the server to the
client when requested, extending client functionality.

Though the REST API has these criteria to conform to, it is still considered easier to use
than a prescribed protocol like SOAP (Simple Object Access Protocol), which has specific
requirements like XML messaging, and built-in security and transaction compliance that make it
slower and heavier.

In contrast, REST is a set of guidelines that can be implemented as needed, making REST
APIs faster and more lightweight, with increased scalability—perfect for Internet of Things
(IoT) and mobile app development.

6.9 OAuth 2
JWTs can be used as OAuth 2.0 Bearer Tokens to encode all relevant parts of an access
token into the access token itself instead of having to store them in a database.

54
6.10 Android
Android provides the fastest tools for building apps on every Android device. With an

intelligent code editor, flexible build system, real-time profilers and emulators. Create connected
apps. Creating the best code. Build rich experiences. Building without limits.

6.11 Biometric
One method of protecting sensitive information or premium content within your app is to
request biometric authentication, such as using face recognition or fingerprint recognition. This
guide explains how to support biometric login flows in your app.

55
 Chapter 7
MANUAL
7.1 Index

Figure 7.1: Index page

7.2 Registration

Figure 7.2: Registration page

56
7.3 Registered User

Figure 7.3: Registered User

7.4 Login

Figure 7.4: Login page

57
7.5 Dashboard

Figure 7.5: Dashboard page

7.6 Profile

Figure 7.6: Profile page

58
7.7 Business transaction

Figure 7.7: Business transaction page

7.8 Page Not Found

Figure 7.8: Page Not Found

59
7.9 Biometric authentication

Figure 7.9: Biometric Authentication

60
7.10 Application login

Figure 7.10: App login page

61
7.11 App Dashboard

Figure 7.11: App Dashboard page

62
7.12 Business transaction

Figure 7.12: Business Transaction

63
7.13 Final business transaction

Figure 7.13: Final Business Transaction

64