Backend for a Ticketing System

(1)

Backend for a Ticketing

System

Rafael Borges de Almeida

Mestrado Integrado em Engenharia de Redes e

Sistemas Informáticos

Departamento de Ciência de Computadores 2018

Orientador

Rui Pedro de Magalhães Claro Prior, Professor Auxiliar, Faculdade de Ciências da Universidade do Porto

(2)

(3)

Todas as correções determinadas pelo júri, e só essas, foram efetuadas.

O Presidente do Júri,

(4)

(5)

Abstract

With society slowly but steadily walking towards an increasingly digitized world, some services have been lagging behind on their response to this societal transition. Nowadays, there is an observable increase on digital alternatives for multiple facets of daily life, such as transportation, news, and shopping. An area which has been noticeably lacking in digital solutions is the access to event venues, where paper tickets are still the norm. This work focuses on the design and implementation of an e-ticketing system, in an effort to fill in this the gap between the current solutions for box offices and other commercial services. The design will be focused on satisfying the basic requirements and needs of said systems whether they be functionalities from the event organizer point of view or from the end-user. Increasingly, as progress was made, further quality of life functions were explored and, completely or partially, implemented, in an attempt for the prototype created to be as deployment ready as possible. In this note, there was some integration performed with an existing mobile technology, more specifically, the usage of a mobile payment system in order to offer a native money transaction support. Furthermore, the prototype will be developed from the start with security being a concern, from introduction of well known good practices, for example, use of certificates for e-ticket creation and communications to including some more innovate features such as implementing a multi factor authentication for e-ticket validation. At the conclusion, we plan to have a working prototype, that should satisfy the basic needs of any event agency using it, such as events creation, ticket purchase and validation of those tickets.

(6)

(7)

Resumo

Com a sociedade andando lenta mas firmemente em direção a um mundo digitalizado, alguns serviços têm ficado para trás na sua resposta para esta transição social. Hoje em dia, há um aumento observável de alternativas digitais para múltiplas facetas da vida cotidiana, como transporte, notícias e compras. Uma área visivelmente tem sofrido falta de soluções digitais é o acesso a locais de eventos, onde o ingressos a papel ainda são a norma. Este trabalho concentra-se na concepção e implementação de sistema de bilhética eletrônico, em um esforço para preencher esta lacuna entre as soluções atuais para bilheterias e outros serviços comerciais. O design será focado em satisfazer os requisitos básicos e necessidades dos referidos sistemas sejam funcionalidades do ponto de vista do organizador do evento ou do usuário final. Progressivamente, conforme o progresso foi feito, outras funcionlidades opcionais são exploradas e, integralmente ou parcialmente, implmentadas na tentativa de que o protótipo criado esteja o mais proximo de produção que for possivel. Nesta nota, houve alguma integração realizada com uma tecnologia móvel existente, mais especificamente, o uso de um sistema de pagamento móvel, a fim de oferecer uma solução nativa a transações e pagamentos. Além disso, o protótipo será desenvolvido a partir do começo com a segurança sendo uma preocupação, desde a introdução de boas práticas conhecidas, como o uso de certificados para criação dos bilhetes digitais e comunicações, e incluir alguns recursos mais inovadores, como por exemplo a implementação de uma autenticação multi-fator para validação dos bilhetes. Na conclusão, planeamos ter um protótipo funcional que satisfaça as necessidades básicas de qualquer agência de eventos, como criação de eventos, compra de ingressos e validação desses ingressos.

(8)

(9)

Agradecimentos

Gostaria de agradeceder a orientação e a ajuda do Professor Rui Prior ao longo da dissertação. Gostava igualmente de agradecer ao Instituto de Telecomunicações por acolher este trabalho.

Aos meus amigos por toda a ajuda durante a escrita desta dissertação e aos meus pais pelo apoio durante todo o meu percurso académico

À Joana por todo o apoio e ajuda neste ultimo ano.

(10)

(11)

4 Functional and Non-Functional Requirements 13 4.1 User requirements . . . 14 4.2 Organization requirements . . . 15 4.3 Validator requirements . . . 15 4.4 Administrator requirements . . . 16 5 Architecture 17 5.1 User . . . 18 5.1.1 Local authentication . . . 18 5.1.2 Payment system . . . 19 5.1.3 Ticket Usage . . . 20 5.2 Service Provider . . . 20

5.2.1 Authentication and Access Control . . . 20

5.2.2 Events creation and edition . . . 20

5.2.3 Event States . . . 20 5.2.4 Image Upload . . . 21 5.2.5 Ticket Categories . . . 21 5.2.6 Validator Control. . . 21 5.2.7 Ticket Offers . . . 22 viii

(13)

5.3 Validator . . . 22

5.3.1 Login . . . 22

5.3.2 Validation . . . 22

5.4 Administrator . . . 22

5.5 Auxiliaries . . . 23

6 Implementation and Development 25 6.1 Database, Language choices and Environment . . . 25

6.1.1 Docker configuration . . . 26

6.2 Database Design . . . 26

6.3 REST Application Programming Interface (API) . . . 30

6.4 Modules Implementation . . . 31 6.4.1 Logging . . . 31 6.4.2 Database Access . . . 32 6.4.3 HTTPS Server . . . 32 6.4.4 Routing . . . 33 6.4.5 JSON validation . . . 34 6.4.6 Authentication . . . 34

6.4.7 Modules Root Folder Structure and Configurations . . . 34

6.4.8 Ticket Purchase . . . 35

6.4.9 MBWay Interface. . . 35

6.4.10 MBWay Module . . . 37

6.4.11 Administrator Module . . . 38

7 Tests, Results, Problems 39 7.0.1 Results . . . 40

8 Conclusion and Future Work 43 8.0.1 Future Work . . . 43

(14)

A Docker Configuration 45

B REST API 49

Bibliography 79

(15)

List of Tables

7.1 User module test results . . . 40 7.2 Service provider module test results . . . 41 7.3 Validator module test results . . . 42

(16)

(17)

List of Figures

6.1 RM diagram with tables for user account and information . . . 26

6.2 RM diagram with tables for Service providers . . . 27

6.3 RM diagram with tables relative to events . . . 28

6.4 RM diagram with tables required for transactions. . . 28

6.5 RM diagram with tables required for ticket creation and storage . . . 29

6.6 RM diagram with tables used for the MBWay module . . . 29

6.7 Diagram with representation of user resources . . . 30

6.8 Diagram with representation of service provider resources . . . 30

(18)

(19)

Listings

6.1 Logging Interface . . . 31 6.2 Database configuration . . . 32 6.3 Database interface . . . 32 6.4 Middleware initialization . . . 33 6.5 HTTPS initialization . . . 33

6.6 Router interface examples . . . 33

6.7 Routing with authentication example. . . 35

6.8 MBWay interface configuration example . . . 36

6.9 MBWay interface . . . 37

A.1 Docker configuration file . . . 45

(20)

(21)

Acronyms

API Application Programming Interface

CSR Certificate Signing Request

HMAC Hash-based Message Authentication

Code

HTTP HyperText Transfer Protocol

HTTPS Hyper Text Transfer Protocol Secure ID Identification

IPC Inter-Process Communication

JSON JavaScript Object Notation

NFC Near-Field Communication

POS Point of Sale

QR Quick Response

REST Representational State Transfer SOAP Simple Object Access Protocol SQL Structured Query Language

SSL Secure Sockets Layer

TOTP Time-based One-Time Password

(22)

(23)

Chapter 1 Introduction

We, as consumers, tend to choose options that seem simpler and safer, that offer a higher level of security and privacy [23], with a tendency to prefer solutions that can be achieved ”on the go”, without the use of a considerable amount of time to complete. E-commerce has explored this by offering its consumers a wide variety of choices directly to their homes, and offering convenience for several services. One of the most common services is the purchase of airline tickets[15]. Following E-commerce and due to the widespread availability of increasingly powerful mobile devices, M-commerce offers users the capability of buying and requesting services while on the move[9]. Many of these services can be translated into an e-ticket system, independently of the context of this service. Several e-ticket systems are already in use, such as the current use of Near-Field Communication (NFC) cards on public transportation[16]. However, the development of these systems is usually restricted to the context of the services implementing the e-tickets. Thus, if a e-ticket system that is completely independent of context could be created, it would present service providers with an easy access point for the association of their services to a ticket. Such a system would need to meet the reliability, security and privacy features that consumers want. It would also open a market to those service providers to which said market has been out of reach.

1.1 Context

1.1.1 e-ticket

An e-ticket, or electronic ticket, represents a contract between the owner of the ticket and the service provider. The user with ownership of the ticket, by presenting it to the respective validation system and subsequent corroboration from this system, is entitled to the service that is represented by said ticket. That service would not only vary depending on the context, but also the ticket itself which can have single use or multiple uses depending upon the validation conditions. Security is crucial as it is needed to establish ownership and to prevent forgery.

(24)

2 Chapter 1. Introduction

1.1.2 e-ticket System

According to Payeras-Capellà[22], there is a general consensus about the main actors of such systems:

• User: The owner of the e-ticket issued by the system. When necessary, he is capable of sending the ticket for validation in order to gain access to the respective service.

• Issuer: Usually the issuer would be an intermediary or the service provider itself, but in this work, the issuer is the system being developed and acts as a trusted intermediary between the user and service provider. It should be capable of issuing any ticket categories as registered by the service provider and requested by the user.

• Service Provider: Should be capable of registering the services with the system and also able to validate any ticket the user presents.

On the other hand, the phases which make up an e-ticket system are not well defined. The most common definition is a 3 phase system: e-ticket payment, issue and validation. However, also according to Payeras-Capellà[22], some authors group the payment and issue phases into a single one while others propose the existence of a registration phase in order to identify and authenticate the users. This disagreement is mostly due to the different services that are implementing the e-ticket system.

1.2 Motivation

Security and privacy are two of the main concerns on any M-commerce application[14]. If we give service providers a choice of a system that would work out-of-the-box while satisfying the security and privacy needs, it would provide them a reliable alternative to current traditional paper based systems. Maintaining a bridge from new systems to old ones is also a concern, though, in order to promote an easier transition. Usually, these systems are already an alternative provided by bigger ticketing organizations. However in order to be able to use them, service providers are charged significant fees which are a hard option for smaller providers. Fortunately, the evolution of computational power, small but powerful computing devices, like the emergence of single-board computers and strong mobile devices, allow for the development of a system capable of performing the needs of an e-ticketing system without the need for a heavy investment as well as minimal involvement of third-parties. This would facilitate the access of e-ticket systems to smaller providers.

As a consequence to this facilitated access, users would have an increased contact with newer technologies being used by a wider range of services. This should increase their confidence and openness to these technologies. This could, in turn, further help the transition from traditional ticketing systems to the new system.

(25)

1.3. Objectives 3

1.3 Objectives

In order to steer this work, we propose a few general goals, on top of later defined system requirements. The two main goals to be achieved by the end of this work are: first, that the system should be a deployment ready prototype which means that, aside from possible configurations, its deployment should be done without any need of further modifications and the second goal, involves keeping the system hardware requirements in consideration so that, at deployment, only minimal hardware requirements have to be met.

Other goals are to satisfy the notion of an e-ticket system as described above. For this purpose, again as described, three actors to the system will be considered: the user, the issuer and the service provider as well as small core functionality goals associated with each actor.

• User

– Access to tickets descriptions; – Ability to acquire tickets; – Access to bought tickets.

• Issuer

– Issue tickets to the user; – Perform payment requests.

• Service Provider

– Registration of ticket categories; – Validation of tickets.

More functionality will be added in order to satisfy system requirements, but those should not be required for the core functionally.

1.4 Summary

In chapter 2 we will look at a few published articles on the subject and similar practical applications. Following onto chapter 3 in which we will analyze all possible ways that such system can be used, independently of any implemented infrastructure. Chapter4will describe all functional and non-functional requirements on the system, which are used to satisfy some of the cases described on chapter 3. These requirements are used to determine the system architecture as described on chapter 5, in which we will start making decisions based on how the different components will work and communicate. Chapter 6 describes the different implementation choices, including database designs, development environments and system configurations. In

(26)

4 Chapter 1. Introduction

the last two chapters,7 and8, the results of any tests performed on the system will be shown, followed by, a comparison between the developed prototype and the planned objectives, as well as, an inspection of any problems that were encountered during the tests or development of this work.

(27)

Chapter 2 State of the Art

2.1 Background

There are some proposed, and a few already implemented, solutions to e-ticketing systems. One of them, which is proposed by Anita Chaudhari[11], implements a simple system for train transportation where the users register an account to which they can add credit to, for the purpose of buying tickets for the destination using the application which in turn uses the Near-Field Communication (NFC) communication point to determine the source of the communication. The user can then preview the ticket and save an image with the Quick Response (QR) code for later validation. This simple implementation incurs the inconvenience of requiring the user to already be at the point of origin in order to buy the ticket. Also, being able to save an image of the QR code for later use, allows for the possibility that the ticket be handed to a third party without the service provider’s knowledge, creating multiple security problems.

Another proposal is made by Cosmina Ivan[17], also in the context of public transportation, which presents a system in a later stage of development and with some usability testing. The proposal is focused on increasing the mobility of the user by allowing said user to buy tickets exclusively through the mobile application, unlike in the aforementioned work, and the use of NFC tags to validate the tickets. During the validation process, the user taps a NFC-enabled device with the ticketing application on it against the NFC tag. This tag transfers to the device information relative to the transportation and in turn, the device communicates this information to the application server. This validation process does not prevent any foul play on the user side, for example, the use of a stub application that reads the information from theNFC tag but does not communicate with the application server.

A further paper describes an e-ticket system with small events in mind[12]. It focuses on a mobile application where the user can search for and buy tickets for events, and on utilizing an offline validation system. To validate, the user prior to the event, downloads the ticket information signed with a event specific private key. At the venue, the user uses NFC communication to transfer that ticket to a validator which checks the integrity of the ticket using the public key

(28)

6 Chapter 2. State of the Art

and resorting to a tracking system in order to avoid the reuse of tickets. This system has the advantage that the validator can be any NFC capable device, allowing for the use of mobile phones and reducing the costs of operation.

2.2 Related Work

Similar systems to the one being studied are already being deployed in several services. For instance, a recent release at the time of writing, is the application Anda[1] developed by Faculdade

de Engenharia da Universidade do Porto and Transportes Intermodais do Porto. This application

allows the user to choose which type of single use ticket to buy, pay using direct debit or credit card with later validation of the ticket usingNFC, using the already existing framework. The main limitation of the application, is the fact that it requires the cellphone to haveNFChardware, which limits the amount of users.

Other services using similar approaches, are the airline companies. Taking as an example the Ryanair application[3] which is capable of listing available flights, allows the user to purchase tickets, and also display them to be verified during check-in using a QR. The Portuguese airline

Transportes Aéreos Portugueses[4], also has an application for this purpose, although searching for a flight using said application, opens the smartphone’s browser taking the user to a website instead of performing the operation in application, which suggests that there is no means to use the ticket through the application.

Another recent example is the placard betting platform solution[8]. It is a mobile application which allows users to electronically create betting tickets that are translated into a QRcode. This code is then used by an authorized mediator to register the bet into the system. However, this application does not keep any history of bets, and does not allow direct payment or perform payouts.

A system that should be more contextually similar to this work is the application used by the company Bilheteira Online[2] which is an application for a ticket office. This application would have very similar if not the same requirements that will be presented later on. However, this application usage seems to be limited to only inform authorized agents with an access token, information about an event such as entries and exits of the event enclosure. Instead, the current digital solution is a online website, where we can search for events and acquire tickets, which are then emailed to the user. The ticket should then be printed and shown at the entrance, where the validators read a barcode.

Most of these implementations consist on very similar processes which can be, in a general way, translated into converting ticket information into a message, which is then, normally, transported by use of NFC,QR or a printed ticket. In case of theQRcode, the code itself can be used when printed out, shown from an received email or simply stored in an image for later use. This indicates that the code only retains information to identify the ticket. There is no attempt automatically performed by the underlying systems, to determine if the ticket itself

(29)

2.2. Related Work 7 is a copy or, in case shown using a smartphone, the legitimacy of the user claiming to be the owner. These verifications, are performed on the side by the use of an identification card and checking if the ticket in question was already used, which would leave open the question of which ticket was forged. The use of printed ticket also supports this notion, since it is not using any digital device, any attempt automatic multi layer validation is not possible, without further input. Unfortunately, due to these implementations not being open-sourced, we cannot draw any more conclusions of how these systems work in the background or further analyze theNFC communications.

Contrasting to company specific solutions, there is an open-source protocol[5] which studies the existing problem of ticket resellers buying tickets from primary locations and reselling them at a very high markup over market price. It then proposes a protocol based on Ethereum’s smart contracts in order to establish a chain of ownership, allowing end-users to verify the tickets’ legitimacy and allowing service providers, which can be considered the primary ticket sellers, to control ticket resale prices and even charging fees. The main contrasting point between this alternative and this document’s proposition, is that the protocol only covers an alternative to ticket signing, leaving open a third-party layer in which developers create the actual e-ticket application.

(30)

(31)

Chapter 3 Use Cases

Context, usage requirements and functionalities are needed in order for the planning of any software development while maintaining it updatable for future demands. Therefore, before exploring any further, we should describe, and analyze all possible uses within the context, even if at first not relevant or not within the short-term scope of development.

These limitations will directly affect in what ways we can perform the vending, storage and validation of our e-tickets and in this chapter, we will describe and analyze our options, while also looking at end-to-end usage.

3.1 Ticket storage

Storing the ticket directly impacts upon the kind of security we can offer to the user’s side of the system. Quick example of this limitation is the existence or lack thereof of computing power which would allow for more complex and possibly safer alternatives, more precisely if the storage is based on cellphone versus a piece of paper.

The storage environments that will be analyzed are:

• paper • smart card • smartphone

And the pros and cons will be based on these capabilities:

• computability • reusability • security

(32)

10 Chapter 3. Use Cases

• user comfort • points of failure

3.1.1 Paper

Although seemingly counter-productive and against the idea of e-tickets, paper tickets sold at physical box offices or printed at home (via some website), can be connected to our back-end and work natively with all other functionalities, by simply having a printed out Quick Response (QR) code which is associated with a key that would give access and reference to any other required information. This method is appropriate for static, single use tickets despite the zero computation capabilities on the client side. It severely limits security, allowing failures such as the theft and copy of the ticket. It would also be a limiting factor for validators as it would require that they have a camera or some other means to visually read the information printed on the paper. In spite of these issues, it can arguably be considered the most comfortable method to use due to its similarity with traditional tickets and the fact it does not need any extra hardware.

3.1.2 Smart Cards

Similar to today bus passes, smart cards can be charged with keys corresponding to tickets, allowing for the re-usability of the same card by later recharges. Being on these cards, also permits the use of some computability should its use be needed on the security protocols while validating the ticket, although it would imply that validators have access to means of reading these cards. Some user comfort is lost if, in the context of use, there would be any reason to select the ticket to be used. Other than that, it can be argued that it is one of the most comfortable methods to use due to the public’s adaptation using similar systems on public transportation.

3.1.3 Smartphone

The on demand online access, high computational power and interactivity of today phones makes them the perfect storage for e-tickets. Online access allows tickets purchase and any possibly required management, along with other security options that would require bi-directional communication with the server. This might be the least comfortable option for users since it requires the use and familiarity with more recent technology and this method being the most contrasting one from a typical ticket but might also be the safest since a cellphone is less likely to be lost or stolen than a piece of paper or a card. Furthermore, if the internet is used, it adds a whole new security concern during communication with the server.

(33)

3.2. Buying 11

3.2 Buying

Tickets transactions can be summarized onto two possibilities, via a physical or digital box office. Usually, we associate digital box offices with e-tickets, however both methods share some common ground and are not necessarily limiting on the choice of the ticket’s storage. A physical box office, can sell an e-ticket simply by receiving the customer’s information (e-mail for example) and associating this with the ticket key. And the reverse can also apply where the customer buys a ticket through a website and prints the ticket at home into a QRcode. The main limitation affecting storage, would be the use of smart cards, since if the ticket is bought at home and the customer wishes to charge a smart card, it would require an Near-Field Communication (NFC) capable device.

Furthermore, the means of selling the ticket should not introduce compromises to any security features. The security protocols applied to the selling of the ticket at a website or through an app, would need to be similarly applied to physical box offices.

3.3 Validation

Reliability and speed are crucial during ticket validation. Ideally there would be a permanent internet connection with the infrastructure, turning the validator into a instrument that would only read the ticket (paper, card or cellphone) and transmit to the operator the result of the read. In a real world situation, internet connection may fail or suffer disruptions, therefore some form of offline validation is required so that, even if it wouldn’t be as secure, there would be no immediate disruption to the service.

Validation, in general, should be able to ensure two things: ticket legitimacy and ownership. Legitimacy can be ensured by verifying if the ticket provided to the validator results from a legitimate transaction from a ticket box and that it isn’t a unauthorized copy, forgery, already used or simply the wrong ticket. Valid ownership implies that there is some connection between the client and the ticket itself, meaning it shouldn’t be usable by a third party.

Although some of these requirements are always true, context of use can be limiting as to the underlying security of the tickets. In paper storage, the most limiting, only a static key can be printed to it and any ownership validation would need to be done by hand. Smart cards are somewhat safer but anyone can use a card that does not belong to the legitimate user, therefore being a source of issues to the ownership check. Meanwhile on smartphone, assuming the phone data is protected, it would make it significantly harder to be used by a third-party. Also due to the smartphone’s capabilities, it is possible to use dynamic keys for the tickets, further increasing security.

Another limit created by context comes from organizations themselves that might want tickets to be reused or to be transferable between users.

(34)

(35)

Chapter 4 Functional and Non-Functional

Require-ments

With the use cases defined, we can proceed to analyze them and determine the system requirements while also focusing on the planning as to the scope of this work. We can first state that we will define requirements for each of the actors of the e-ticket system: User, Service provider, and Validator. Doing this would allow us to, later on, define points of entry for the functionalities required for the satisfaction of the requirements. Since it is possible that some functionalities will not fall under the requirements of any of the aforementioned actors, these will be defined as under the purview of an Administrator to the system, in spite of such an actor not being considered in the system. Each of these points have their own requirements, however there are some important requirements that are shared amongst all actors. These would be mainly security related and it would involve the following:

• Secure end-to-end communication - Dealing with payments and providing a service, implies the use of proper security methods and maintaining a secure communication channel between the users and the server. Encrypting the messages is therefore essential along with secure information storage.

• Scalability - Although initially designed for small systems, proper scaling capabilities are required as to not to inhibit the growth of any user. Also, accepting the existence of multiple organizations to be registered under a single deployment, affects the scaling of the service, allowing the usage of the system by multiple simultaneous groups without disruption of service.

• Stability - Similar to other online services, disruptions to the service could imply a security or payment failure, which could in turn would make the system unusable. This requires the creation of fall-backs in case of any disruption occurs on any of the critical communications. • Connectivity - Since development of the system’s back-end is the scope of this work, a proper

Application Programming Interface (API) implementation with the required documentation 13

(36)

14 Chapter 4. Functional and Non-Functional Requirements

is a must for any future work on a front-end interface that uses the API. Also, additional attention is required on the protocols or added third-parties as to avoid adding further software or hardware requirements to the front-end.

• Modular - Separation of services facilitates the systems stability and scalability, it also allows for easier maintenance and future improvement.

• Upgradability - Heavily affected by the modularity of how the system’s architecture is designed and implemented, changes to protocols or additional service requirements are likely to happen. Maintaining the architecture adaptable to these changes allows for the utilization of less third-party software to handle the new requirements.

4.1 User requirements

These will affect functionality from the public’s, or user’s, side when using this system directly. Anything that involves the user planning to search, buying a ticket for and accessing an event has to be considered here.

• Login - A way to perform registration and login into the service, either by using a standard account or external registration (Social Media).

• Event search and display - Searching and listings of past, ongoing and future events and methods to filter the display. Afterwards it should give access to any relevant information about the event.

• Organization search and display - Similar to the above event search, but applied to organizations.

• Ticket acquisition - Methods to acquire the corresponding pretended ticket and display them for validation

• Ticket aggregation - Similar to acquisition of new tickets, however some cases require for the creating of a single verifiable package which includes multiple tickets.

• Secure payment - Some sort of payment system is required for any usage. In order to fulfill this requirement a communication module will be developed using the servers of MBWay mobile payment systems.

• Profile settings - Some functionality require a way to add and edit personal information, therefore a simple editable personal profile is needed.

(37)

4.2. Organization requirements 15

4.2 Organization requirements

Some sort of back-office is needed so that organizations are able to edit their information, manage events, ticket categories, offers and their validators.

• Login - Secure log in using only local account information.

• Events information access - Access to any created event belonging to this organization. • Event status - Some control over the state of the event, allowing the creation of new events

without the need to publicize.

• Ticket categories - Categories to define different kind of tickets, along with a way to manage the price, sale periods and other relevant information

• Ticket offers - Ability and management of ticket offers allows for the system’s native support of promotional actions, that the organization decides to undertake without a need for direct injection of the tickets.

• Create validation agents - Creating new validation agents involves the supply of a key to be used during the validator login.

• Validation agents lock - If for security reasons, it can required to invalidate a validator key, disabling any further logins or validation attempts.

• Payment config - Methods that govern how current payments are processed, therefore configuration is required although as stated above, initially only the MBWay payment system will be considered.

• Profile - Similar to the user, a simple editable profile is required.

• Access control - Although only a quality of life requirement, allowing for multiple accounts to administrate a single organization account adds some further security on the organization side.

4.3 Validator requirements

Validators are responsible for allowing access to events and catch any possible infraction. Therefore, the security and reliability of this component is crucial as any failure could either create a security breach or a considerable disruption of service.

• Login - A key should be given by organizations to their event validators to gain access to the validationAPI. This key should be of single use and locked onto the device on the first use to add control over the validating agents.

(38)

16 Chapter 4. Functional and Non-Functional Requirements

• Online Validation - During normal usage, agents are only a communication intermediary. They should only read the ticket information and transfer onto the server for processing. This processing should check the ticket’s integrity and validity.

• Offline Validation - In case of any communication failure, validation cannot stop. Therefore, a means of offline validation is required even though it has reduced capabilities when compared to its online counterpart. This requirement, although considered as part of the project, should be facilitated and not performed by it.

4.4 Administrator requirements

These requirements are needed to perform more sensitive registrations. Everything that would fall on a direct to database access or in the need for a system administrator would fall under this category.

• Organization registration - Registering organizations should be initialized by service agents as to maintain some initial security. This registration involves the association of an organizational owner to a local account and creating the needed certificates for later on use in communication protocols.

• Ticket Seller certificate - For the same reasons as stated above, creating certificates to be used by third-parties ticket sellers should be done by administrative agents. This requirement only partially affects the current work, meaning the existence of these sources of tickets should already be considered by validators, however in testing phases, no actual third party is used.

(39)

Chapter 5 Architecture

In this chapter, having analyzed the system requirements stated above, we will plan the architecture of our system. First, it is possible to split the system into different services, henceforward called modules. Each module would satisfy the needs of a specific actor to the system and each section in this chapter will cover one of these modules. However an extra section exists, which will describe the auxiliary functionalities that serve more than one module.

This architectural design takes inspiration from modular programming, which allows inde-pendent development of each component of the software, and by running each of these modules as independent services, it maintains a clear separation of each of the actors, creating an obstacle to any unauthorized access to another component.

Common amongst all modules is the communication architecture. Being that the system should function independently of later developed end-user applications, we choose to implement the communication as a resource oriented web service, basing off Representational State Transfer (REST)[13] architecture which, with proper documentation allows for a strong and easy to use Application Programming Interface (API) without limiting any development choices on the application side. As for the communication, there was a choice between using the Simple Object Access Protocol (SOAP)[21] protocol or simple HyperText Transfer Protocol (HTTP) requests with JavaScript Object Notation (JSON)[10]. SOAPoffers a very strict and formal messaging protocol which consequently, adds further security to the system, which is something critical as eventually, we would be processing payments. However, this protocol does not fit very well with REST architectures, since the APIdeveloped with the architecture is very mutable, as resources are added and accessed, while on SOAP, although not mandatory, not having static endpoints is a major obstacle for its implementation. Furthermore, the size of the messages produced by the protocol is substantial and with the added difficulty of parsing them, which would be a negative aspect considering the mobile context in which the system is planned to exist. On the other hand,JSON messages do not impart any added security by themselves, leaving this aspect to each end point so that they validate their own requests. However JSON objects are easily parsable and, unless required, should not contain any further information other than that which is strictly needed. This is a positive aspect for mobile development which, despite having

(40)

18 Chapter 5. Architecture

limited processing power, requires having fast interactivity with the user. Moreover, easier to parse messages facilitate the scalability of the system while maintaining fast responses.

Further similarities between the modules, are the existence of two main components, one of which will implement theREST architecture, validate theJSON requests, authenticate users, directing the body of the request into a second component and, after proper processing, respond to the request. Meanwhile, the second component will process the request and, as needed, communicate with the database to perform the access, creation or modifications on the resources. The last common component is the database. Although each module will be responsible for its own connection, they will all share the same database.

5.1 User

First, we will decide on the authentication methods. Initially, the planned authentication could be done using either of two methods: the user email, which would be verified, and user input password; or using a social network login. We will focus on the first method, since the external login requires only the implementation of the chosen network’s API.

5.1.1 Local authentication

The email and password authentication, henceforward called local authentication, will be similar to most authentication protocols, although in this case, we will be creating an user Identification (ID) for internal processing using a SHA hash which is turn is digested into base 64 for storage. Furthermore, two other tokens are created using the same method. The first one is used later on for a time-based one-time key. The other one is used to identify a ticket storage container which, for the the context of this prototype, it would be the smartphone used during registration, however the definition of these containers is important for later support of paper and/or smart card storage mediums. The password will be handled using the bCrypt algorithm, salted with a random hash for later storage on a database.

After registration and as defined on the requirements, an user application would need endpoints in order to explore possible events or requested information, such as date, duration, ticket prices. Afterwards the main concern would be ticket acquisition, aggregation and payment. Acquiring and aggregating the e-ticket can be abstracted into the same process, simply by dynamically creating packages, which can contain 1 or more tickets, and associating them to the user’s container followed by the payment for that package.

(41)

5.1. User 19

5.1.2 Payment system

With the package formed, we should look at the payment. As proposed, the system should natively support communications with MBWay mobile payment systems, as such an interface is required.

But first, let’s look at how MBWay works and its requirements. Communications to the MBWay servers are performed via a strict SOAPprotocol, in which the webservice endpoints on MBWay’s side determine what operation is performed. These operations can be financial operations, financial inquiries, alias control or TPA control. The first involves a request for payment or a request involving an earlier payment, for example a refund. Financial inquiries are used to retrieve information about payment history. Alias controls can be used to create an alias that refers to end users allowing the use of the returned token instead of any personal information on the end user and finally, the last possible operation is a request for the closure of the TPA. This last operation manually signals the end of the transactions for the current day allowing for the payment system to perform any required internal financial transactions.

TheirAPI also requires the existence of endpoints on our side for asynchronous responses. More specifically, one endpoint is needed for asynchronous financial operation results and another for alias creation. However, we are not required to support all functionalities, therefore not having to satisfy all of MBWay’s requirements. Instead we need only implement the requisites required for an early prototype of our system, more specifically the financial operations endpoints.

Knowing which communications will be required to perform, we can look at the protocol itself. Analyzing the MBWay technical documentation[6], we can assert that we will be playing the role of the integrator in one of two possible protocols. This signifies that, in a practical generic example, the merchant would register himself with us, giving their Point of Sale (POS) identification that they would be receiving from MBWay, which would allow us to perform payment requests on their behalf. Furthermore, we would need to register ourselves on MBWay, therefore acquiring a certificate to use on any requests performed to their endpoints. Additionally, for our asynchronous response endpoints, it is mandatory to use Hyper Text Transfer Protocol Secure (HTTPS) with our own certificates.

Taking in consideration how communications must be performed for the payment system, we know that a separate server listening for requests is needed along with a method to handle the asynchronous responses so that we can act accordingly. As such, a solution resides in the development of an additional independent module with its own database to log every incoming and outgoing request while maintaining the status of any pending requests.

Being that this module, henceforward referred as MBWay module, will be exchanging information with the user module, a means of communication to and from it is required, since we are already usingHTTPfor external requests, we decided to use the inter-process communication protocol, Inter-Process Communication (IPC), based on Unix sockets. Meaning that the MBWay module will be listening for events using an Unix socket to receive any required configurations

(42)

as well as to initiate any payment requests. These requests should already be arriving with all of the needed information and the module only works as a transparent middleman that logs information as needed. Increasingly, it will emit events for the asynchronous responses, to warn the user module of accepted, rejected or failed payments.

5.1.3 Ticket Usage

With the ticket acquired, the user’s next step is accessing the ticket’s token so that it can then be passed to the validator. The ticket is composed of two parts:

T = (K, S(K))

K is the key generated upon payment confirmation, and S(K) is K signed with the seller’s certificate as specified in the section5.4. In this work’s prototype scope only one seller exists that being the system itself however, for future work, it is important to implement this component on the ticket. In section 5.3we will analyze how the ticket works while undergoing validation.

5.2 Service Provider

5.2.1 Authentication and Access Control

To gain access onto this module, it is first required to create a local user account using the user module followed by registering an organization as explained on section 5.4. The initial account will be treated as the organization’s owner and as such, it will have the permission to grant or remove access to other existing user accounts. These accounts should have access to most endpoints, except those that handle the authorized accounts and payment systems. As a security concern, no user account can have access to more than one organization.

5.2.2 Events creation and edition

Creating the event should require the input of core information, namely a name, description, start and end dates. Afterwards, it should be possible to further edit additional information. Out of these, the most noteworthy is the event state, image upload, ticket categories and validator control.

5.2.3 Event States

Some functionalities may depend upon the current situation of the event, for instance, if the event is already underway or yet to be publicized. Therefore it is required to define the current state of an event. As such, at any given time, the event will be in one of the following states:

(43)

5.2. Service Provider 21 • Saved - This will be the first state, which will be attributed right after creation. An event

in this state won’t have any information accessible by the user module.

• Planned - At any given time, the service provider may publicize this event transitioning it to the planned state. At this point, the information is accessible by the public and they should be able to acquire tickets.

• Active - During the time period in which the event is ongoing, it is considered as active. • Finished - After the event conclusion time, it will be classified as finished.

5.2.4 Image Upload

Since the system should natively support any information and, although not critical to the core functionalities, a method to publish images for event publicizing would be a must for any practical implementation of this system. As such, and since our API will be based on JSON structures which is not ideal for file uploads, a point of entry to the upload of image files is required. This point of entry should have an encoding of multipart/form-data which allows files to be uploaded under a form. Afterwards, the request would return an identification for each uploaded file for later use in event edition.

5.2.5 Ticket Categories

Categories allow for a single event to have multiple tickets with different specifications. Each ticket category should have the following characteristics: name, description,price, amount, sale start time, sale end time, tags and secure.

Some of them are self explanatory, except the last two. Tags should work together with the validators adding the non-requirement functionality in which certain ones can only validate certain tickets. The second attribute determines if the ticket, when under online validation, requires the use of the time-based one-time key from the user, otherwise the ticket would be declared as invalid.

5.2.6 Validator Control

Along with the event and ticket management, service providers also need access to the means to manage the validators. This would require a method to create them, accessing their login tokens, attributing tags if using that feature and, for security reasons, be able to deactivate that token disabling any further online functionality.

(44)

5.2.7 Ticket Offers

Another non-requirement functionality that was added expecting to have a need for it later. The service provider may input emails in order to send to those emails an activation token for a given ticket package. Other than how these tickets are handed out, they function just the same as normally bought tickets.

5.3 Validator

5.3.1 Login

The token generated earlier is required to access this module. Furthermore, the system expects an application token, either generated by itself or using some identification from the smartphone, in order to lock the validator token to a device. This way the service provider could single out a device should any issues arise.

5.3.2 Validation

To perform the online validation, the validator should act as a transparent transporter of the ticket information from the user side application to the module. The endpoint should be expecting one of two possible JSONschemas. The first one contains only the ticket information referred on 5.1.3. In this case, we validate the ticket by first validating the signature and then checking the database for the current state of the ticket key. The second possibility, before looking at the ticket and the signature, we use the time-based one-time method.

At account creation, we generated a token and stored the timestamp of creation, which we proceed to share with the user. The time-based one-time algorithm[19] states that we use the HMAC-Based one-time password algorithm[18], however we define as such:

T OP T = HT OP (K, T )

, where K is used as the key and it is the token we shared earlier and T is the number of steps in the pre-set interval that have elapsed. In practice, we calculate T as

T = timestamp − current_time interval

.

5.4 Administrator

Currently, this module will only serve two purposes. The first is to register any new organizations on the system. For this it just requires the input of basic information such name, email, contact,

(45)

5.5. Auxiliaries 23 and description. It would also add the given user email owner status on the organization. The second purpose is to register third party ticket sellers. A certificate signing request[20] is required and from it we extract any needed information about the seller, we test the certificate, using it to test the signature on a message sent with the Certificate Signing Request (CSR) and if it passes we sign it followed by an email to the seller with the signed certificate.

5.5 Auxiliaries

These functionalities will be defined under a library which will be common to all modules. In this library, we will have implemented methods to perform:

• Logging - defines the different logging files and formats.

• Database connection - configurations, common points of entry for logging and interfaces to limit database queries.

• Emailing - Should implement a method to configure an email service and send any required emails

• JSON schema validation - Should contain regex or use a third-party library to validate communications into the server

• File Upload - Library to manage and control files being upload onto the server

• MBWay interface - This library should contain the required methods for communication with the aforementioned MBWay module.

(46)

(47)

Chapter 6 Implementation and Development

In this chapter we will look at how the aforementioned architecture is to be implemented, starting with the development of the Representational State Transfer (REST) Application Programming Interface (API), defining the database structure and then finally characterizing each of the modules and their functionalities. Some of the features that were added during the implementation were not intended to be fully functional by the end of this work. They are however intended to be basic ideas or structures in order to facilitate any future development. None of these features can affect the core functionality that was determined on the system requirements.

6.1 Database, Language choices and Environment

Before looking at the implementation, we should look at which tools are to be used.

Firstly, looking at the database, the first design choice to be made is between using a Structured Query Language (SQL) or a NoSQLdatabase. Without going much deeper into the differences or advantages, it was decided to utilize aSQLdatabase, simply due to the fact that it is the most commonly used on similar web-based services. As such, and due to prior experience with this technology, we have decided to use MySQLwith the InnoDB engine.

The Next design choice to be made is to choose a coding language in which to implement the system. There are several to choose from along with frameworks designed for this purpose. In this case the decision made was to use JavaScript with the NodeJS framework. This decision was due to our familiarity in the use of this framework due to past projects. Furthermore, the existing NodeJS modules will accelerate the development and simplify the addition of features for future work.

Initially, we decided to make our implementation available on a remote server. For this purpose, a RaspberryPI server was used, unfortunately due to hardware failure we were forced to find an alternative. Looking at available alternatives that would allow us to keep developing

(48)

26 Chapter 6. Implementation and Development

remotely we decided that renting a server would be our most viable option. However, due to the cost and performance loss over the RaspberryPI solution, we settled for using local virtual machines with Docker containers.

6.1.1 Docker configuration

We will be using Docker to simulate a network swarm with a single node. This would allow, in theory, for the future scaling of the system as needed to satisfy greater loads. However, in the scope of this work, the scalability was not fully tested. Nevertheless, a proper implementation of Docker would facilitate later work on that area.

As such, we will attribute to each module, as well as the database, their own service. Each service will be run in its own independent container over a lightweight Linux operating system. The configuration of each service will expose the required ports in the container to the host, create volumes that associate paths in the container to physical paths on the hosts, allowing for persistent data and a common point for the Inter-Process Communication (IPC) sockets. We will also introduce the required environment variables for any possible configuration as well as use the Docker secrets functionality, which stores any files containing sensitive data into "/run/secrets/", such as passwords and keys. The appendix A shows the full configuration used for this work.

6.2 Database Design

The design of the database was extended upon as different functionalities were being implemented as to satisfy their needs. We will now look into the structures that support the more critical functionalities.

Firstly, how to identify users. Initially we thought of using a simple user table, however as different log-in methods were considered, the following schema was decided upon, shown in figure 6.1, in which we are already considering the possibility of third party authentication.

accounts userID email localAccountID facebookID active containerGroup containers container containerGroup mobileDevice localAccounts localAccountID password userToken userID token timestamp users userID firstName lastName birthday gender countryID address zipCode city vatNumber phone

Figure 6.1: User RM Diagram

(49)

6.2. Database Design 27 be reconsidered due to the General Data Protection Regulation that went into effect earlier this year. This also applies to some of the data stored in other tables. However, this work being a prototype and such information not being required by any functionality, this remains unaltered. The "accounts" table stores logistic information for authentication, including relations to tables where specific log-in methods’ information is stored. The table "userToken" contains information required for the tickets’ validation during the time-base one-time algorithm for each user. "containers" are, as the name suggests, used to relate possible multiple ticket containers to a single user, however during this prototype, each user will only have the possibility for one container, that will be identified as the mobile device.

For the service providers, as shown in figure6.2, which were named "organizations", we show the relation from "users" to "organizationsAgents" which determines the users affiliated with the organization as well as the organization’s owner. The "organizations" table itself contains mostly basic information. "mbway_organizations" is where we are storing the Point of Sale (POS) required for performing financial requests into the MBWay servers in the organization’s behalf. Lastly, the figure shows one of the possible interactions of the "locations" table, which in addition to relating to any table where a location is required, is where Google Maps locations are stored.

locations locationID name address lat lng type mbway_organizations organizationID posID organizations organizationID name shortName email contact locationID vatNumber thumbnailImage feedImage coverImage rate description organizationsAgents organizationID userID owner users userID firstName lastName birthday gender countryID address zipCode city vatNumber phone

Figure 6.2: Service provider RM Diagram

In the figure 6.3 we show the relations between the event and its different components. Each event will start with an organization which owns the event and upon activation by the service provider, the entry is then added to "activeEvent", locking the event thus disabling its deletion. Furthermore on the service provider’s request, entries can be added to "ticketTypes" or "verifiers". "ticketTypes" stores information as pertaining to the ticket categories, meanwhile, validators’ information is stored in the table "verifiers". The relation between "verifiers" and "ticketTypes" can be used to determine which validators are authorized to validate certain tickets. The "eventRate" and "tagsEvents" were added as the need for rating and searching events by tags, for future work, was predicted.

Figure6.4shows which tables required to process and register a payment using MBWay. As can be seen, the table "mbway_transactions" registers all requested payments while maintaining an updated status. Each transaction should be related to a single ticket, an organization using the "posID" and a user using the "userID". We don’t use the phone number associated with the

(50)

28 Chapter 6. Implementation and Development activeEvent eventID eventRate userID eventID rate events eventID name description transport slogan startDate endDate organizationID locationID thumbnailImage feedImage coverImage locations locationID name address lat lng type organizations organizationID name shortName email contact locationID vatNumber thumbnailImage feedImage coverImage rate description tagsEvents eventID tagID tagsTickets ticketTypeID tagID ticketTags tagID en pt ticketTypes ticketTypeID name eventID description maxAmount price startSaleTime endSaleTime stock secure verifiers verifierID eventID token note androidID locked verifiersTags tagID token

Figure 6.3: Event RM Diagram

MBWay directly since there is a possibility of it changing, furthermore, if required, it is easier to replace the table than to use an MBWay alias.

mbway_transactions posID merchantOprID ticketID status timestamp userID mbway_organizations organizationID posID tickets ticketID container ticketKey packageID seller users userID firstName lastName birthday gender countryID address zipCode city vatNumber phone mbway_payment userID phone new_phone

Figure 6.4: Financial Transactions RM Diagram

Lastly, figure 6.5, shows the "tickets" relation with the aforementioned "containers", the "ticket_package" relation between "ticketTypes" and "tickets" allowing for the creation of the required packages. Furthermore, we store the certificate corresponding to the ticket seller associated to a "boxOffice" and "invalidtickets" stores the Identification (ID)s of any ticket that were validated, refunded, cancelled or subject of payment failures.

Although we will not go into much detail, we also show the tables being used as logs for the MBWay module on figure6.6. As can be observed, we keep a table for each outgoing request, one

(51)

6.2. Database Design 29 boxOffice file commonName countryName localityName organizationName emailAddress hostName containers container containerGroup mobileDevice invalidTickets ticketID verifierID time orderedBy reason mbway_transactions posID merchantOprID ticketID status timestamp userID ticketTypes ticketTypeID name eventID description maxAmount price startSaleTime endSaleTime stock secure ticket_package packageID typeID amount tickets ticketID container ticketKey packageID seller

Figure 6.5: ER diagram with tables required for ticket creation and storage

registration annulment in case of communication errors, as per the MBWay specification; along with tables to store the synchronous and asynchronous responses with their respective status. Moreover, we also have tables for financial inquires, even though we will not be implementing that functionality on the system.

Annulments merchantOprId referencedMerchantOprID timestamp additionalData status Enquiries merchantOprId posID timestamp status Enquiries_Financial_Operations merchantOprId enquiryId Financial_Operations posId merchantOprId aliasName aliasTypeCde amount currencyCode operationTypeCode aditionalData timestamp timeOut Financial_Operations_Result merchantOprID token status amount currencyCode statusCode timestamp

(52)

6.3 REST

API

In order to follow theREST API’s standard, we must define resources that will be created, edited, and deleted, as well as separating the function call entries from said resources, building them into adequate paths, and determining the most appropriate HyperText Transfer Protocol (HTTP) methods.

Looking at the modules and at the database design, we can state that only two modules, service provider and user, have resources whilst all of them will require endpoints that also act as function calls.

Figure 6.7: User resource diagram

Figure 6.8: Service provider resource diagram

The diagrams6.7 and6.8show the resources of each module. For these we will be using the following rules for paths nomenclature and methods:

• Paths - While building the path, we should use the following: /resource/resourceID; • GET - Using this method will get a list of resources or, if provided with anID, information

on a specific one;

• POST - This method should be used to create new resources of the specified type; • PUT - It should update the information of the resource. Unless otherwise noted by theAPI,

(53)

6.4. Modules Implementation 31 • DELETE - As the name suggests, it should delete, if possible and allowed, the resource

along with any child resources;

As for the function calls, they will cover authentication methods across all modules: the upload on the service provider, the ticket purchase on the user, and the ticket validation on the validator module. These calls will require a POST method, and both resources and function calls will use application/json content type except for the upload which, as stated before, will use multipart/form-data.

With this we start writing the documentation, using the OpenAPI 3.0 specification[7], for each of the API’s modules, which are shown on appendix B.

6.4 Modules Implementation

In this section, we will discuss each of the individual modules that have been implemented using the NodeJS framework along with which, why, and how we choose certain third-party modules to tackle certain problems.

6.4.1 Logging

One of the advantages of using NodeJS is its middleware. This allows for the developer to process any request on a certain order depending on the paths. As such, we will use that potential as much as possible, starting with logging.

For the logging we will use a module called Winston, which allows for custom logging formats and outputs furthermore, if using Express-Winston we can intercept HTTPmessages and log them.

To initialize, we will read the configuration used, with all the required information about transports and their formats being used on the module, along with, if required, adding the express application to the middleware to intercept the HTTPmessages. Having initialized the logging, we only need to call it from any of the in-development modules that use either log or logErrors functions. It is of note that the log functions are designed to work asynchronously, while logErrors expects a callback chain that should end with the return of the proper error message to the user.

init: function (config) { ... }

initRoutingMiddleLogging: function (app) { ... } logError: function (err, info, next) { ... } log: function (level, txt) { ... }

(54)

6.4.2 Database Access

We will use a module called MySQL to handle the database connection and queries. The configuration, which you can see in6.2, is hard-coded since all modules should share the same database. db_config.connectionLimit = 10; db_config.dateStrings = true; db_config.host = ’sql’; db_config.port = ’3306’; db_config.user = ’tikt’;

db_config.password = fs.readFileSync(’/run/secrets/db_user_pass’, ’utf8’); db_config.database = ’tikt’;

db_config.multipleStatements = true;

Listing 6.2: Database configuration

The code block 6.3 shows the exposed interface. "ConnectDB" is used to initialize the connection, however it also catches connection errors or lost connections, in which case it will automatically attempt to reconnect after a certain amount of time has elapsed. The remaining functions do as their names suggest, being that "transactionError" also calls rollback on the current transactions and "getDataFromRows" returns extracts from the query response, in this case, an array with an object for each row.

function connectDB() { ... }

function procedure(procedureName, args, next) { ... } function query(sql,values,next) { ... }

function beginTransaction(next) { ... } function rollback(next) { ... }

function commit(next) { ... }

function transactionError(err, next) { ... } function queryError(err, next) { ... } function getDataFromRows(rows, next) { ... } function format(sql, values) { ... }

Listing 6.3: Database interface

6.4.3 HTTPS Server

Each module will have its own Hyper Text Transfer Protocol Secure (HTTPS) server to implement and setup. The server will be using the express module, that natively allows for the use of middleware configurations from other modules. As such, during initialization we will introduce the middleware to be used on each of the modules, which can be seen on code block6.4.

Backend for a Ticketing System