based software system using commercial
ERP system
Bram Cooreman
under supervision of: Ari Rantala, TAMK Jari Mikkolainen, TAMK Esa Kujansuu, TAMK Wim Catteeuw, KHBO Joan Peuteman, KHBO Jeroen Boydens, KHBO
Master’s thesis
June 2013 IT engineering
I would like to thank my parents to give me this opportunity to do my thesis and finish my studies here in Tampere, Finland. This was a great experience for me.
I also would like to thank Ari Rantala, for helping me when I changed subject and guiding me to the correct persons. I would like to thank my supervisors Jari Mikkolainen and Esa Kujansu, they gave me the thesis subject and helped me during my project.
I would like to thank Wim Catteeuw and Joan Peuteman from the KHBO (Katholieke Hogeschool Brugge-Oostende). They gave me the opportunity to do my thesis in Tampere, and Mr Catteeuw for guiding and helping me along with my thesis. I also want to thank the KHBO for the education and the possibility to go on Erasmus.
I should not forget to thank Lien Vercruysse and Sina Tee, they helped me with correcting my thesis.
Studying in Tampere, was a great experience and I have met a lot of new people, with different culture and interests. I have learned a lot of new things both personally and professionally.
Bram Cooreman Tampere 2013
Tampereen ammattikorkeakoulu
Tampere University of Applied Sciences Degree Programme in ICT Engineering Bram Cooreman:
Study of the architecture for a new web-based software system using commercial ERP system
Master’s thesis 75 pages
June 2013
The thesis covers the study of an architecture for a new web-based system which uses a commercial ERP system.
There are business students at the university of TAMK that uses the ERP system. The ERP system makes it possible for them to create and maintain their own company. Every company has the possibility to use a couple of services that are offered by the system, like: banking, automatic ordering system, accounting. The current system is getting old and is not able to withstand more companies and users. A study is necessary to make sure that the new system is compatible with the requirements of the users and the system.
The new system needs to support the services of the old system. The university would like to sell or rent the system to other universities of Finland or to different countries as well. When the new system is used in different universities, there will be different types of databases. To make sure that the system will work across the different universities, there needs to be an interface layer between the database and the different services. This interface layer makes it possible to have only one connection to the database.
1 INTRODUCTION ... 9
2 THE CLOUD... 11
2.1 History ... 11
2.2 Types of cloud computing ... 13
2.2.1 The Public Cloud ... 13
2.2.2 The Private Cloud ... 14
2.2.3 The Hybrid Cloud ... 14
2.3 Different services ... 15
2.3.1 Software as a Service (SaaS)... 17
2.3.2 Platform as a Service (PaaS) ... 17
2.3.3 Infrastructure as a Service (IaaS) ... 18
2.4 Conclusion... 18
3 ENTERPRISE RESOURCE PLANNING (ERP) SYSTEM ... 19
4 WEB-BASED ARCHITECTURE... 20
4.1 HyperText Transfer Protocol (HTTP) ... 20
4.1.1 Request methods ... 20
4.2 HyperText Transfer Protocol Secure (HTTPS)... 21
4.2.1 Secure Socket Layer (SSL) ... 22
4.2.2 Handshake ... 22
4.2.3 SSL limitations... 24
4.3 Hypertext Preprocessor (PHP) ... 25
4.4 Representational State Transfer (REST) ... 26
4.4.1 Constraints ... 26
4.5 REST-ful Application Programming Interface (API) ... 31
4.5.1 Resources ... 32
4.5.2 URL format ... 33
4.5.3 HTTP methods ... 34
4.5.4 HTTP response codes... 41
4.5.5 CURL ... 42
4.5.6 OAuth Authentication Framework... 47
5 MATURITY MODEL ... 61
5.1 Richardson Maturity Model ... 61
5.1.1 Level 0... 62
5.1.2 Level 1... 64
5.1.3 Level 2... 66
5.1.4 Level 3... 68
5.2 Other Maturity Model ... 72
5.2.1 Level 0 Not a REST-ful framework... 72
5.2.2 Level 1 Mapping/routing and HTTP/URI encapsulation... 72
5.2.3 Level 2 Media Type Support and Client support ... 72
5.2.4 Level 3 REST elements modelled into language ... 73
5.2.5 Level 4 Hypermedia as State Engine plus Semantic Support ... 73
5.2.6 Level 5 CoD and layering support ... 73
5.3 Conclusions and concerns ... 74
6 General Conclusion... 75
6.1 Future work ... 75
UTF-8 8-bit Unicode Transformation Format
ARPANET Advanced Research Projects Agency Network API application programming interface
COD Code on Demand
ERP Enterprise Resource Planning
XML Extensible Markup Language
HATEOAS Hypermedia as the engine of application state
HTML HyperText Media Language
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure IaaS Infrastructure as a Service
JSON JavaScript Object Notation
PaaS Platform as a Service
PHP Hypertext Preprocessor
REST Representation State Transfer
RMM Richardson Maturity Model
SSL Secure Socket layer
SaaS Software as a Service
TCP/IP Transport Control Protocol/ Internet Protocol
TLS Transport Layer Security
URI uniform recourse identifier
Figure 1 Private, Hybrid and Public clouds (Beaver, 2013) ...13
Figure 2 Overview of the different services (Bikeborg, File: Cloud_computing_layers, 2013) ...15
Figure 3 Influence of the user and the service provider (Sameer Shelke, Microsoft Windows Azure – Secure Development, 2011) ...16
Figure 4 SSL handshake (IBM, An overview of the SSL handshake, 2012) ...23
Figure 5 PHP (Goodrich, 2012) ...25
Figure 6 PHP and HTML code ...25
Figure 7 Client Server constraint (Fielding, 2000) ...26
Figure 8 Client-Stateless-Server (Fielding, 2000) ...27
Figure 9 Client-Cache-Stateless-Server (Fielding, 2000) ...28
Figure 10 REST (Fielding, 2000)...30
Figure 11 Web API (Massé, 2012) ...31
Figure 12 HTML code with relative URL ...34
Figure 13 HTML code with absolute URL ...34
Figure 14 GET request ...35
Figure 15 Response of the GET method ...36
Figure 16 POST request ...37
Figure 17 POST server response...38
Figure 18 GET request of one book ...38
Figure 19 PUT request ...39
Figure 20 DELETE request...40
Figure 21 DELETE responds ...40
Figure 22 Curl GET request...43
Figure 23 Curl POST method ...44
Figure 24 Curl PUT method(Sandoval, 2009) ...45
Figure 25 Curl DELETE method (Sandoval, 2009) ...45
Figure 26 Generate a server.key...46
Figure 27 Certificate Signing Request ...46
Figure 28 Sign the Certificate ...46
Figure 29 OAuth2 authentication flow (IdentityManagement, 2012) ...48
Figure 32 Resource owner password credentials flow (hansamann, OAuth2: The
Resource Owner Password Flow, 2012) ...52
Figure 33 Client Credentials flow (hansamann, OAuth: the Client Credentials Flow, 2012) ...53
Figure 34 XML example (Data, 2013)...54
Figure 35 SimpleXML example...55
Figure 36 JSON example ...56
Figure 37 JSON code example...57
Figure 38 MVC architecture ...59
Figure 39 Steps to RESTful API (Fowler, 2010)...61
Figure 40 Level 0 example (Fowler, 2010)...62
Figure 41 POST Appointment(Fowler, 2010) ...62
Figure 42 Response of Server(Fowler, 2010) ...63
Figure 43 Book an appointment(Fowler, 2010)...63
Figure 44 Level 1 adding resources (Fowler, 2010) ...64
Figure 45 Request to a resource(Fowler, 2010) ...64
Figure 46 Server response with resources (Fowler, 2010)...65
Figure 47 Client books an appointment with resource (Fowler, 2010)...65
Figure 48 Server Reply in level 1 (Fowler, 2010) ...66
Figure 49 Level 2 with HTTP verbs (Fowler, 2010) ...66
Figure 50 GET request (Fowler, 2010) ...67
Figure 51 201 response of the server(Fowler, 2010) ...67
Figure 52 Level 3 with the use of hypermedia controls (Fowler, 2010)...68
Figure 53 GET method in level 3 (Fowler, 2010)...68
Figure 54 HTTP response level 3(Fowler, 2010) ...69
Figure 55 POST method level 3 (Fowler, 2010)...70
INTRODUCTION 1
This thesis was made for the Tampere University of Applied Sciences (see Figure 3). In the first initial meeting with Esa Kujansuu and Jari Mikkolainen, they told me that the business students use a system called Kykylaakso (see Figure 1). Kykylaakso makes use of an ERP (Enterprise Resource Planning) system. This system makes it possible to simulate and run a company. The system let the students do bank transactions and make orders with other companies. But there are some problems with the system; the database
is not properly set up, it doesn’t have any relations. The Finnish character set isn’t
supported, and the system is becoming a bottle neck.
The university wants to change the system, because the idea is that it can be used later on for other universities in Finland and maybe in the future for universities of other countries.
In order to make sure that the new ERP system isn’t going to be a bottle neck, a study of
the architecture needs to be done. The new system is going to be a web-based architecture like Kykylaakso.
In the current system there are some services that are useful for the new system e.g. Ainopankki (see Figure 2). This service makes it possible to make bank transactions
between the different companies. Because the administrators of the new system don’t
want to rewrite the same service, there has to be a way to make sure that they can reuse that service. So Esa and Jari asked me to make an extra layer between the client and the
Figure 1 Kykylaakso (TAMK, 2008)
Figure 2 Ainopankki (TAMK, 2008)
server (in this case the database), so in case the database changes from e.g. MySQL to
Oracle, it doesn’t have much problems.
THE CLOUD 2
The cloud is a very complex concept. Whereas most people think that the cloud equals the web, there is a lot more to it than meets the eye. There are different definitions concerning cloud computing, with each definition describing a part of the cloud. In the
white paper “A break in the clouds: towards a cloud definition” published by ACM
computer communication Reviews, the authors found over 20 different definitions of cloud computing. They assembled some of the main notions into:
“A large pool of easily usable and accessible virtualized resources (such as hardware,
development platforms and/or services). These resources can be dynamically reconfigured to adjust to a variable load (scale), allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLAs.”
(Luis M. Vaquero, 2009)
The following paragraphs explain the history, the different types of cloud computing, the different services and an end conclusion.
2.1 History
In 1969 J.C.R. Licklider was responsible for the development of ARPANET (Advanced Research Projects Agency Network). This was the beginning of the internet. Licklider had a vision, that everyone on the globe was interconnected and could access programs and data at any site, from anywhere. (Weekly, 2009)
Since the early seventies the internet began to grow. Moreover, in the early nineties the offered bandwidth of the internet started to increase significantly.
One of the first important milestones in cloud computing was the arrival of SalesForce.com in 1999. They introduced the concept of delivering enterprise applications via a simple website.
Amazon Web Services came in 2002, which provided a suite of cloud-based services including storage, computation and even human intelligence.
In 2006 Amazon launched the Elastic Compute Cloud (EC2) as a commercial web service that allows small companies and individuals to rent computers to run their own computer applications on.
In 2007 SalesForce.com expanded its efforts with Force.com. This is a developer-based platform (PaaS), which allows companies to build and run all of their business applications and websites through the cloud.
Google and Microsoft began to enter cloud computing in 2008. The Google App Engine brought low-cost computing and storage services, which led to the arrival of Google Apps. This allows people to store documents on the cloud. Microsoft began to follow these developments with Windows Azure.
SalesForce.com began to grow with Database.com, and there was a way for the developers to access the services on the cloud with any device or platform and with any programming language. In 2010 Apple introduced the iCloud, allowing synchronizing of photos, apps, music and documents across a string of devices. ' (Weekly, 2009; Prakash, Did You Know Cloud Computing Has Been Around Since the '50s?, 2012; sourya, 2011)
2.2 Types of cloud computing
There are several types of cloud computing; public cloud, private cloud and hybrid cloud. Each of these clouds has their own advantages and disadvantages. The next paragraphs explain the pros, cons, usage and meaning of each cloud computing types, as seen in Figure 4.
2.2.1 The Public Cloud
The public cloud is a collection of computing resources (applications, storage, services,
…) that are dynamically and scalable provisioned over the internet and hosted by
hosting providers (Vendors). Those resources can be provided via web apps or web services. All recourses are hosted on a shared system, but each resource operates on its own and is securely encrypted. The public cloud can be used by a small start-up company or a big company that uses the cloud every day. A fee is charged by the cloud provider for each user account. This fee depends on either the usage or a certain quota. The main advantage of a public cloud is that the customer cannot see or control the infrastructure of the cloud. Another advantage is that the resource can be accessed from different places. (Reese, 2009; Anthony T. Velte, 2010; Borko Furht, 2010; Rhoton, 2010; Syed A. Ahson, 2010; KUMARI, 2005)
2.2.2 The Private Cloud
The private cloud is mainly hosted by a company itself, and uses the private network configuration of the company. A private cloud uses virtualization techniques to enhance scalability, resource management and hardware utilization. Companies use a private cloud, because they can manage the infrastructure. The most significant down side of a private cloud are the high operating and bandwidth costs, making it an expensive investment for the company. There are two kinds of private clouds; a cloud owned by the company itself or a cloud provided by the services provider’s data centre. A virtual private cloud is a cloud in a cloud, where the company manages the cloud, but the service provider owns the infrastructure. The advantage of a private cloud is that there is no loss of control or security risks with other cloud infrastructure models. (Reese, 2009; Anthony T. Velte, 2010; Borko Furht, 2010; Rhoton, 2010; Syed A. Ahson, 2010; KUMARI, 2005)
2.2.3 The Hybrid Cloud
Hybrid cloud means a combination of private cloud and public cloud. Hybrid clouds are often used in corporations that need to maintain some of their applications in their internal infrastructure. The companies want to ensure that confidential data and other sensitive information are secure. Moreover, they also need the scalability and cost benefits of the public cloud.
Cloud bursting is a common used term in hybrid cloud computing. It describes the process of an organization using their own computer infrastructure for normal use, while the internet applications are deployed on the public cloud to handle the variable loads. Sometimes it is necessary that the cloud can handle a high/peak load request without failing. (Reese, 2009; Anthony T. Velte, 2010; Borko Furht, 2010; Rhoton, 2010; Syed A. Ahson, 2010; KUMARI, 2005; cloudtweaks, 2012)
2.3 Different services
Cloud computing can be seen as a broad range of different services. Over time cloud services have evolved as a layered model. There are three main layers: Software as a Service (SaaS), Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). Each service has its own function and purpose. Figure 5 Figure 5shows an overview of the different services that are available in cloud computing. These differences are discussed in the next chapters.
Figure 5 Overview of the different services (Bikeborg, File: Cloud_computing_layers, 2013)
Figure 6 shows the responsibility of the user and the service provider for each of the different types of services.
In Figure 6 there are two main aspects management and security. With traditional IT the management is done by the customer. This means that the client is responsible for the security of the system. In IaaS the service provider will take care of the virtualization, servers, storage and networking, the client will manage the data, middleware and applications. Because the application is totally managed by the client the security is then realised by the client. In PaaS, the platform is provided by the service provider, this means that the provider is responsible for the security of the system. The client only takes care of the data and the applications that are on the cloud. In SaaS, the service provider owns the entire stack, this means that they are also responsible for the security of the system. The client will be responsible for the security policies like user access roles and role management. (Llc., 2012)
Figure 6 Influence of the user and the service provider (Sameer Shelke, Microsoft Windows Azure – Secure Development, 2011)
2.3.1 Software as a Service (SaaS)
Software as a Service (SaaS) is the service most visible for end-users. The users make a connection to these services through a web browser or other web portals. The service provider provides the necessary services, with less amount of effort for the IT manager. So all deployment, licensing and billing models are invisible for the end-users.
Some characteristics of SaaS services are: centralized management and keeping the services up-to-date. A lot of the services are standardized, but it is possible to change their configuration and scalability, depending on the application. There are a lot of examples and providers that supports SaaS e.g. Salesforce.com, Google, Microsoft, Facebook, etc.
2.3.2 Platform as a Service (PaaS)
Platform as a service (PaaS) is known as an environment for software development, storage and hosting different services over the internet. PaaS makes it possible to make and create a web application without the cost and complexity of buying and managing the underling software/hardware.
Cloud platforms act as run-time environment, which support a set of programming languages. They offer libraries and additional services such as reusable components that are available for the programming language. There are several webhosting services that support a variety of active server-side components like Microsoft ASP.NET, java scripts, PHP, Python or Ruby on Rails.
2.3.3 Infrastructure as a Service (IaaS)
Infrastructure is the backbone of cloud computing. IaaS makes it possible to offer a virtual private server with any physical needs. This can be done without any capital investments on the client’s side. IaaS can offer servers, storage, network and operating systems as an on demand service. The customer pays only what he uses.
Characteristics of IaaS:
Resources are distributed as a service Allows for dynamic scaling
Variable cost, grows with the necessary equipment
Generally includes multiple users on a single piece of hardware (Kepes, Understanding the Cloud Computing Stack, 2011)
2.4 Conclusion
The current system now uses a private cloud, this has the advantage that all the information and all the work is done by the administrators. The downside is that when the system is growing the hardware needs to grow as well. So in order to handle the growth of the system, it is useful that the university use a hybrid cloud. Because then they have their private data in their own cloud, but they can still use the advantages of a public cloud like: expansion of the hardware.
ENTERPRISE RESOURCE PLANNING (ERP) SYSTEM 3
Enterprise Resource Planning (ERP) system is a management software system that allows the organization to manage all the important parts of its business. ERP software integrates all different features of an operation in the company, including development, manufacturing, marketing, financing, accounting, distribution, ….
In TAMK university they use the ERP system called Pupesoft. Pupesoft is a system that is made with PHP. The students at TAMK use this system to simulate and virtually run their own company. They can make bank transactions and place orders with other companies. Each of these companies can be managed by the supervising teacher. The teacher has the responsibility of the bank, the automatic ordering systems etc..
There are several services that are provided by Pupesoft, one of these services is Ainopankki. Ainopankki makes it possible to do bank transactions, with the bank or with other companies. Because Pupesoft is becoming a bottleneck, and the database is harder to maintain, the administrators of TAMK wants to change the ERP system. The
administrators don’t want to rewrite the code for the services that are useful. In order to
make sure that the services also work on the new system, an API needs to be developed. This API will take care of the integration of the old services in the new system.
The following chapters will explain the web-based architectures and the architecture style that is used to make the API.
WEB-BASED ARCHITECTURE 4
The system in this project is a web-based architecture. The next chapters discuss HTTP, HTTP requests, HTTPS, PHP, PHP framework, REST and RESTful API in more detail.
4.1 HyperText Transfer Protocol (HTTP)
HTTP or HyperText Transfer Protocol is an application protocol used for distributed, collaborative, hypermedia information systems. HTTP is used to transfer data across the Internet or World Wide Web. HTTP defines how the messages are formatted, transmitted and what actions the web servers and browsers should take in response to different commands. The HTTP protocol is a stateless protocol, because each command is independent.
The currently latest version is HTTP 1.1, this is the most common deployed version; it is defined in RFC 2616. The protocol is a request-response protocol, and is typically used in a client-server model. The client sends a request to the server and the server responds to it. If a request fails the server will send a code that represents the reason why it failed. These codes are well-defined.
4.1.1 Request methods
Every HTTP request has multiple methods also sometimes called verbs. Each method describes a desired action to be performed on the identified resource. Depending on the server implementation, the resource will represent dynamically generated data or pre-existing data. The URI identifies the resource. (Abeysinghe, RESTful PHP Web services, 2008)
The HTTP verbs are used in the Uniform interface of a REST-ful API, see also section 4.4.1.4 Uniform Interface. Each verb has an associated semantic that helps identifying the action which needs to be performed on the resource.
TABLE 1 HTTP request methods (Abeysinghe, RESTful PHP Web services, 2008)
Verb Description
POST Sends a resource to the server. Updates the resource in the location identified by the URI.
GET Requests a representation of a resource identified by a URI. Only retrieving data nothing else.
PUT Sends a resource to the server, to be stored in the location identified by the URI.
DELETE Deletes a resource identified by a URI
HEAD Retrieves the metadata of a resource, identical to the GET request
but without the response body
TABLE 1 shows a couple of the request methods of HTTP. Each of those methods are used in a REST-ful API. The POST method means Creating a child resource in a parent resource e.g. /items. POST gives the possibility to create a new item. The GET method Reads the information from the server through the URI. The PUT method Updates or inserts an existing item where the URL is known e.g. /items/1234. The last method DELETE is used for Deleting elements from a resource. In a REST-ful API the HTTP methods are referred as CRUD.
4.2 HyperText Transfer Protocol Secure (HTTPS)
HyperText Transfer Protocol Secure (HTTPS) is a communication protocol which enables secure communication on the internet. HTTPS is not a communication protocol in itself; however, it uses HTTP throughout an SSL/TLS connection. This makes it possible to send data from and to a server in a bidirectional encrypted way. HTTPS uses the TCP port 443, while regular HTTP uses the TCP port 80. To make sure that the server can accept HTTPS commands, it should have a public key certificate to ensure that verification is possible. Some organizations use their own certification, as they become more secure this way.
The site is required to have a full HTTPS connection and all pages should be rendered in HTTPS. In the event that the site has any pages in HTTP, this will cause a security
leak. (Wikipedia, HTTP Secure, 2013; K.roshan, What is Https and SSL? and how it works? Explained in Simple English, 2011)
4.2.1 Secure Socket Layer (SSL)
SSL stands for Secure Socket layer and is a protocol used to provide a secure communication over the internet. The protocol makes it sniffing for important information impossible to do. Not only the security of the website is of importance, but also the communication between the webservers needs to be secure. SSL is a protocol developed by Netscape Communications and RSA Data security. When a SSL connection is set up the connection that is created uses a 128 bit or 256 bit key encryption. The SSL protocol consists out of 2 layers, a record protocol and a handshake protocol. These layers are used on top of the transport protocol like TCP/IP. Both of these layers use asymmetric and symmetric cryptographic algorithms. (IBM, Secure sockets layer overview, 2005)
4.2.2 Handshake
It is very important that messages which are send to and from the client to the server are encrypted. This is realized by using two keys, a public key and a private key. In general the public key is used to encrypt the message and the private key is used to decrypt the message. In order to make sure that the client can have an encrypted connection there needs to be a handshake. Figure 7 SSL handshake shows the handshake between the client and the SSL server.
First of all the SSL connection is established by the client that goes to a HTTPS website.
1) The client sends a “client hello” message to the server, which contains a list of cryptographic information of the client. This information can contain the SSL/TLS version, the cipher suites that are supported by the client, and the different client compression methods. The message contains a 28 byte random string.
2) The server receives the “client hello” message and responds with a “server
hello” message. This message contains the cipher suite that is chosen by the
server out of the list that has been send by the client. It also contains the data compression method, session ID and another random number. The server will send his certificate to the client for the authentication of the client. The digital
certificate contains the server’s public key. If the client needs to use a resource
of the server and that step needs client authentication, the server will request for the client certification.
3) The client will check the server’s digital certification to see if it can authenticate the server. If the server authentication fails the user will be informed about the problem.
4) The client will generate a random byte string, which will be used for the computation of a secret key that is used for the encryption of the message data.
The random byte string is encrypted with the server’s public key that has been
send with the digital certificate.
5) If the server has send a “client certificate request” the client will send a random byte string that is encrypted with the client’s private key. The client will send
this data along with the client’s digital certificate, that contains the client’s
private key, and it is encrypted by the random number generated by the client. 6) The server will check the client’s digital certificate to see if it can authenticate
the client. If the client cannot be authenticated then the session will be terminated. If the authentication is successful the server will use its own private key to decrypt the message that has been send.
7) The client will send the server a finished message that is encrypted with the master secret key, to indicate that the client handshake is complete.
8) The server will send the client a finished message that is encrypted with the master secret key, to indicate that the client handshake is complete.
9) The SSL handshake is now complete, during the rest of the SSL conversation the messages will be encrypted with the shared key. (Pierobon, 2011)
4.2.3 SSL limitations
SSL has several main limitations:
When the user wants to use a secure website, he has to take in account that there is a possibility that the website is not legit. To prevent this, the SSL server uses a special certificate to confirm that they are not imposters.
The way that the ciphers are used for encrypting is an important issue. When the website uses an unsafe cipher like RC4, the possibility that the site can be cracked is much higher than using a save cipher like AES.
The SSL connection is strongly dependent of the implementation of the web browser. (Poretsky, 2013)
4.3 Hypertext Preprocessor (PHP)
PHP is an acronym that stands for Hypertext Preprocessor. It defines a general purpose server script language that makes it possible to build dynamic web pages. PHP is widely integrated with HTML code; therefore, it is possible to use some of the HTML code in a PHP file. The use of PHP makes it possible to build an application through the use of a browser.
The following example shows how HTML and PHP code are integrated
PHP will be used for the realization of the REST API. Figure 8 PHP (Goodrich, 2012)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head>
<title>PHP and HTML example</title> </head>
<body> <?php
echo “This is an example on how the integration of PHP code is possible in a HTML page”;
?>
4.4 Representational State Transfer (REST)
REST is an acronym that stands for Representational State Transfer. REST is a software architectural style for distributed hypermedia system as the World Wide Web. REST was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. The next chapters discuss the principles and the interactions of REST. (Fielding R. T., 2000)
4.4.1 Constraints
A constraint is a rule that indicates one or more software architecture properties. A group of constraints is referred to as a style. REST style is a group of six constraints: client-server, stateless, cache, uniform interface, layered, Code-On-Demand. Each of these constrains will be discussed in the upcoming paragraphs.
4.4.1.1 Client-server
A client-server is a model where two programs communicate with each other and exchange data. The client and server software can be located on the same computer or in the same network; however, it is also possible that they run on different computers in a separated network. The client makes a request to the server and the server responds to the client request. The server can contain multiple services or server programs. By using a client-server constraint it is possible to separate the user interface from the data storage. Figure 10 shows the client server communication. (Fielding R. T., 2000)
4.4.1.2 Stateless
A client-server constraint must be stateless when using REST. A stateless communication means that there is no session state allowed on the server side. Each request from client to server must have all the necessary information. When there is a session state, it is kept on the client side.
This constraint increases the visibility, reliability, scalability. Visibility improves as a monitoring system does not need to look further than the current message date. Reliability improves since it becomes easier to find and recover from a particular error. Scalability is improved because, there is no need to store the state between the requests; the server can free component resources easily. Figure 11 shows that every client needs to send all information to the server. (Fielding R. T., 2000)
Yet, there is also the disadvantage of a decrease in performance with an increase in message size. This increases the repetitive data that needs to be send from client to server.
4.4.1.3 Cache
Cache acts as an intermediary between client and server. A cache saves the responses of a request, and can be reused as a response to a later request that is equivalent to the one that has been send to the server. The response needs to be labelled as cacheable or
non-cacheable. As long as the cache hasn’t been expired the response is still up-to-date to
the one on the server. This has the advantage of eliminating some interactions and improving user performance. The downside of cache is that the data within the cache can be outdated, which causes wrong information to be send to the client..(Fielding R. T., 2000)
Figure 12 shows how the client uses the cache to communicate with the server.
4.4.1.4 Uniform Interface
A uniform interface is an interface for a component that needs to be as generic as possible. The use of a uniform interface simplifies the overall system architecture and improves the visibility of interactions. The services provided by the implementations are being decoupled, this encourages independent evolution. Still, a uniform interface has the downside of degrading the application efficiency. This happens, as the transferred information is in a standard format, and not suited for the needs of the application. REST interface is suit up for large-grain hypermedia data transfer, optimized for the common case of the web; however, the interface is not optimal for other forms of architectural interaction.
A uniform interface is realized by using multiple architecture constraints in order to guide the behaviour of the components. There are four interface constraints that define REST: identification of resources, manipulation of resources through representation,
self-descriptive messages and hypermedia as the engine of application state. (Fielding R. T., 2000; Sandoval, 2009)
4.4.1.4.1 Identification of resources
In a web-based system the resources are identified in requests. This may be addressed by a unique identifier, e.g. URI (Uniform Recourse Identifier). The URI is used in REST-ful systems. The resources are conceptually separated from the representations send back to the client. For example XML, JSON or HTML are used to represent data from the database.
4.4.1.4.2 Manipulation of resources through representation
A client manipulates the resources through representations. The client holds a representation of a resource, which includes metadata, and he has thus enough information to modify or delete the resource on the server, without changing the resources directly. The client can only send and receive representations from the server. Moreover, it is possible that the exact same resource is represented to other clients in different ways.
The main idea is that the representation is a way to communicate with the resource, but it is a copy of the resource. This allows the recourse to be represented in different ways and formats without changing the identifier. (Fielding R. T., 2000)
4.4.1.4.3 Self-descriptive messages
Self-descriptive messages require that every message from client to server must contain all the necessary metadata to describe the meaning of the message. Metadata includes: resource state, the representation format, size and the message itself. HTTP messages provide headers to organize the various types of metadata into well-defined fields. This means that the methods used to invoke the messages must be agreed on and standardized between the client and the server, otherwise the transaction will be rejected.
4.4.1.4.4 Hypermedia as the engine of application state
Hypermedia as the engine of application state or HATEOAS, is a constraint where an application process moves to the next step through hypermedia. The main idea is that a client interacts with a network application entirely through hypermedia which is dynamically provided by the application server. The REST client is not required to know how to interact with any application or server beyond the generic idea of hypermedia.
4.4.1.5 Layered system
A layered system is organized hierarchically. Each layer provides a service to the layer above it and uses a service from the layer below it. The layers can then talk with other layers which improves the extensibility by using a mechanism to isolate the complexity. The client server model is an example of layer architecture. The layered system allows architecture to be composed of hierarchical layers by restricting the component behaviour which limits the interaction with the immediate layers.
By using a layered system (see Figure 13) the knowledge of the system is restricted to a single layer. This causes a limitation on the complexity of the system and encourages an independency. The layers encapsulate there information onto the message, this protects the new services from older services. The components are being simplified by moving the infrequently used functionality to a shared intermediary. The use of intermediaries can improve the system scalability and enables the load balancing of the different services available over the network and processes.
One disadvantage of a layered system is that every layer adds overhead to the message and this causes latency. The latency can be solved by using shared caches. (Fielding R. T., 2000)
4.4.1.6 Code-on-Demand
Code-on-Demand is an optional constraint. The client has access to a couple of resources, but the client does not know the internal working on how to process them. That is why the client sends a request to the server for the code that represents the know-how. Once received, the code can be executed locally. This makes it possible to add code or functions to an existing application, through scripts or plug-ins.
Code-on-Demand has the advantage of extensibility and configurability, since the code on client side can be extended after the application has been deployed. The code that has been send to the client can interact with the user locally rather than through remote interactions. Furthermore, the scalability of the server is improved, because the workload is now done by the client. On the other hand, there is a reduced visibility caused by the code itself.
4.5 REST-ful Application Programming Interface (API)
The web is continuously growing, and more and more web services are available via the internet. Because developers do not want to reinvent the wheel, they would like to use some of the available web services. This can be done with a web application programming interface (API). A web API is used as a communication layer between the client and the web service, see Figure 14 Web API. A web API commonly uses a REST architecture style, and is then referred to as REST API. The term REST-ful comes from the web services that are using a REST API. (Allamaraju, 2010; Massé, 2012; Abeysinghe, RESTful PHP Web services, 2008)
A REST API exists out of multiple resources, each of these resources are linked with each other. The client communicates with the API, so in this way the web service is hidden. In case the web service changes, the API can still work with some minor adjustments. This makes an API very powerful, as the client does not have a straight connection to the database. The next paragraphs discuss in more detail the resources, URL format, HTTP methods that are used and the way that the API is communicating with the server through XML/JSON objects.
4.5.1 Resources
The REST API is a way to communicate with the web service and also makes the operations on the information in the web service. The information in the web service is called resource. When considering a REST-ful API the use of resources is a fundamental issue in the design process. The API communicates with the resources through hyperlinks. The hyperlinks show the representation of how the resources are related with each other.
A resource is an object that contains data, type, relationships to other resources and some set of methods that can operate on that object. The only methods that can be used on resources are the CRUD methods, see section 4.1.1. Each resource has its own resource identifier, URI (uniform resource identifier). A resource can also be used to check the last modified time, this can be passed in the metadata. Resource data can be represented in either XML format or JSON format. Each of these representations has their own advantages and disadvantages, which will be discussed in section 4.5.7. A group of resources is called a collection. Each collection can only exist out of one type of resource, which makes the collection is homogenous. (Abeysinghe, RESTful PHP Web services, 2008)
4.5.2 URL format
A REST API communicates with the web service through hyperlinks. The hyperlinks are called URLs, uniform resource locator. URLs are used to communicate between client and API.
The syntax of an URL is:
scheme://domain:port/path?query_string#fragment_id
Scheme: contains the namespace of the URL. For example this can be the HTTP(S) of a web browser.
Domain: this could be the IP address of domain. Commonly this is the name of the domain, e.g. google.com. This translation is caused by the a domain name system (DNS).
Port: a port number is optional; by default it is 80 for HTTP and 443 for HTTPS. Path: defines where the resource is located.
Query string: the data that needs to be send to the server, for example when the user posts something.
Fragment id: this defines the location in the resource or in the document (Wikipedia, Uniform resource locator, 2013)
Each resource and collection is represented by a URL. The URL is unique for every resource and collection.
The following table shows how the URL mapping happens in a REST API.
TABLE 2 URL mapping in REST-ful API (Massé, 2012)
URL Description
http://localhost/bank/API/ API entry point
http://localhost/bank/API/transactions Top level collection, also called directory of the URL
http://localhost/bank/API/transactions/2 ID selected in the collection, or document
There are two ways in the API to represent a URL; relative and absolute. A relative URL does not fully include the file location, as shown in the HTML code in Figure 15.
In an absolute URL the entire path of the file is located. An absolute URL path can be seen in the following HTML code, see Figure 16:
4.5.3 HTTP methods
As discussed in section 4.1.1 several HTTP methods are being used by REST. The main methods are called CRUD; create, read, update and delete. Each of these methods is explained in the following examples.
Table 3 HTTP methods with REST (Abeysinghe, RESTful PHP Web services, 2008)
HTTP Method URI Description
GET /book List all the books
POST /book Create book(s)
GET /book/1 Retrieve book
PUT /book/1 Update book
DELETE /book/1 Remove book
The next sections discuss client requests and server responses of CRUD methods.
<a href=”login.php” name=”login>Login page</a>
Figure 15 HTML code with relative URL
<a href=”http://localhost/bank/API/login.php” name=”login>Login page</a>
4.5.3.1 GET
Figure 17 shows the GET request that has been send to the server.
The client has entered http://localhost:8080/REST/book.php, the server sees how the client asks for that information. The most important things in the header field are:
GET /REST/book.php HTTP/1.1: there is a get request for the file/document located in REST folder. The protocol that has been used is HTTP 1.1.
Host: localhost:8080: the host or domain name is localhost on port 8080. Port 8080 is used, since an application registers the traffic on that port.
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8: the accept header indicates which content types are acceptable for the response of the server. (Fielding, 1999)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36: this is the user-agent string, the browser that is making the request.
Cookie: __tb_geo=FI%3Bnull%3Bnull: an http-cookie that previously has been send.
GET /REST/book.php HTTP/1.1 Host: localhost:8080
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: __tb_geo=FI%3Bnull%3Bnull
The server receives the request and replies with:
Figure 18 shows the response of the server to the GET request.
HTTP/1.1 200 OK: This response indicates that the server can process the request of the client and sends a 200 OK.
Date: Fri, 24 May 2013 12:03:20 GMT: this indicates when the server sent the message to the client.
Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7: this represents the server settings and the software that is installed on the server.
Content-Length: 183: this indicates the length of the message body that the server sends to the client
HTTP/1.1 200 OK
Date: Fri, 24 May 2013 12:03:20 GMT
Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7 X-Powered-By: PHP/5.4.7
Content-Length: 183
Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html <books> <book> <id>1</id> <name>Book1</name> <author>Auth1</author> <isbn>ISBN0001</isbn> </book> <book> <id>2</id> <name>Book2</name> <author>Auth2</author> <isbn>ISBN0002</isbn> </book> </books>
Content-Type: text/html: this specifies the media type of the entire message body that is send to the client.
The actual message
4.5.3.2 POST
Figure 19 shows the POST request of the client. Only the differences with the GET request are discussed.
POST /REST/book.php HTTP/1.1: The client sends a POST request to the server with the HTTP 1.1 protocol.
Content-Type: application/xml: The information that has been send with the POST request is in a XML format
The POST message
POST /REST/book.php HTTP/1.1 Host: localhost:8080
Connection: keep-alive Content-Length: 166 Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Content-Type: application/xml Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: __tb_geo=FI%3Bnull%3Bnull <books> <book><name>Book3</name><author>Auth3</author><isbn>ISBN0003</isbn ></book> <book><name>Book4</name><author>Auth4</author><isbn>ISBN0004</isbn ></book> </books>
The server receives the messages and sends a HTTP 200 OK back. Figure 20 shows the
response of the server. It’s almost the same as the GET response, the only difference is
that the Content-Length : 0.
4.5.3.3 GET one resource
Figure 21 shows the request of one book. This is realized by going to the URL http://localhost/REST/book.php/1, the number is the ID of the book that user is requesting.
The server then responds with the corresponding book. The answer is the same as the first GET response; however, with the message body being just one book not the entire list.
HTTP/1.1 200 OK
Date: Fri, 24 May 2013 13:20:33 GMT
Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7 X-Powered-By: PHP/5.4.7
Content-Length: 0
Keep-Alive: timeout=5, max=100 Connection: Keep-Alive
Content-Type: text/html
Figure 20 POST server response
GET /REST/book.php/1 HTTP/1.1 Host: localhost:8080
Connection: keep-alive Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch
Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: __tb_geo=FI%3Bnull%3Bnull
4.5.3.4 PUT
Figure 22 shows how the client makes a PUT request. The user puts the new values in the message body. The only difference with a POST method is that the method now is PUT instead of POST.
The server responds in the same way as the POST responds. PUT /REST/book.php/1 HTTP/1.1 Host: localhost:8080 Connection: keep-alive Content-Length: 100 Accept: application/xml Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Content-Type: application/xml Accept-Encoding: gzip,deflate,sdch Accept-Language: nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: __tb_geo=FI%3Bnull%3Bnull; <books> <book> <id>1</id> <name>NewBook</name> <author>Auth1</author> <isbn>ISBN0001</isbn> </book> </book>
4.5.3.5 DELETE
Figure 23 shows the DELETE request to the server, the user wants to delete the first record in the list.
The server responds with a HTTP 200 OK as showed in Figure 24.
Each of these methods now has a positive response (200 OK). Yet, there are also other response status codes, which are discusses in the next paragraph.
DELETE /REST/book.php/1 HTTP/1.1 Host: localhost:8080
Connection: keep-alive Accept: application/xml Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36
Content-Type: application/xml Accept-Encoding: gzip,deflate,sdch
Figure 23 DELETE request
HTTP/1.1 200 OK
Date: Sat, 25 May 2013 10:31:28 GMT
Server: Apache/2.4.4 (Win32) OpenSSL/0.9.8y PHP/5.4.7 X-Powered-By: PHP/5.4.7
Content-Length: 0
Keep-Alive: timeout=5, max=100 Connection: Keep-Alive
Content-Type: text/html
4.5.4 HTTP response codes
Every response that comes from the server has a response code included. There are a lot of response codes, so only the ones that are important for curl and the REST API will be discussed.
4.5.4.1 2xx Success
The 2xx class discusses the responses where the client request was successfully received, accepted and understood. (Fielding e. a., 1999)
200 OK: The request is received successfully; the response is depending on the request.
201 Created: The request is completed, and the answer put in a new request. 202 Accepted: The server accepted the request but has not completed it yet. 204 No Content: The server completed the request; the answer does not contain any message body.
4.5.4.2 4xx Client Error
The 4xx class, this class indicates that there has been an error at the client or user side. 400 Bad Request: The request that sent to the server could not be processed because of a syntax error.
401 Unauthorized: The request needs authentication, since the user cannot be authenticated, it will return an unauthorized error.
403 Forbidden: The requested page or document is not available for the user because the user is not authorized to access it.
404 Not Found: The requested page or document is not found on the server.
4.5.4.3 5xx Server Error
The 5xx class appears in case of a server error; the server is aware of an error and sends it back to the client.
500 Internal Server Error: When a fault occurs on the server side, generally the 500 Internal Server Error will be thrown. If this error message appears, the client tries to send the same request again hoping for another response.
4.5.5 CURL
Curl is a software program that provides a library and command-line. The curl program makes it possible to send and receive data from the server. Moreover, the tool can support different protocols. Curl is used in this project is by using the libcurl. The next paragraphs will explain the workings of libcurl. (Stenberg, 2013)
4.5.5.1 Explanation of libcurl
resource curl_init([string URL]): This initializes the curl session, returns a valid session or false in case of a fault. The URL string contains the URL where the curl needs to get its information. The URL can also be set manually.
boolcurl_setopt(intcurlID, int option, mixed value): curlID is the session of the curl; option contains the option value that needs to be set, value is the value of the option. Several options are being used:
o CURLOPT_URL: This contains the resource URL. It will be set and
overridden if it was already set in the curl_init().
o CURLOPT_RETURNTRANSFER: This option acts as a toggle; when the
value is true then the output is fetched by curl_exec() otherwise it is handled by a file handle (default STDOUT).
o CURLOPT_POST: If this value is set to true then the curl will perform a
HTTP POST request.
o CURLOPT_POSTFIELDS: This option contains an array of the values
send with a POST method and is necessary if the CURLOPT_POST is set.
o CURLOPT_PUT: To put a file to the server.
o CURLOPT_INFILE: the file that needs to be read for the upload.
o CURLOPT_INFILESIZE: The expected file size in bytes.
o CURLOPT_CUSTOMREQUEST: a custom request method instead of
GET or HEAD, useful for the DELETE request.
o CURLOPT_SSL_VERIFYPEER: This option acts as a toggle. If the value
is set to false then the SSL certificate will not be verified. If the value is set to true then the SSL certificate will be checked, the certificate will be passed with the option cainfo. Default value is true.
o CURLOPT_SSL_VERIFYHOST: This option can have 3 values: 0 Do not
check the common name (CN) attribute, 1: Check that the common name attribute exists in the SSL certificate, 2: Check that the common name exists and that it matches the host name of the server.
(Chng, 2009)
o CURLOPT_CAINFO: This option contains the path to the server
certification.
(Torben Wilson, 2001)
Mixed curl_exec(resource $ch): This executes the curl resource and responds with the values from the server side.
Void curl_close($ch): closes the curl session and frees all resources. (Group, 2013)
4.5.5.2 Examples
Figure 25 shows an example of the implementation. This example is a GET request to the server side code. The curl_exec($client) returns the output of the code behind, this output is in a JSON format. The JSON format will be discussed in section 4.5.7.2.
<?php
//HTTPS url to the code behind where the data is processed.
$url = 'https://localhost/bank/API/transaction.php/' . $_SESSION['ytunnus'] . '?lang=' . $_SESSION['lang'];
//Initialize curl
$client = curl_init($url);
curl_setopt($client, CURLOPT_RETURNTRANSFER, 1); //SSL verification set to true
curl_setopt($client, CURLOPT_SSL_VERIFYPEER, true);
/* 0: Don’t check the common name (CN) attribute
* 1: Check that the common name attribute at least exists
* 2: Check that the common name exists and that it matches the host name of the server
*/
curl_setopt($client, CURLOPT_SSL_VERIFYHOST, 2);
// Certificate is necessary to communicate with the code behind curl_setopt($client, CURLOPT_CAINFO,
"C:\\xampp\\apache\\conf\\ssl.crt\\server.crt");
$response = json_decode(curl_exec($client), true); curl_close($client);
?>
<?php
//HTTPS url to the code behind where the data is processed.
$url = 'https://localhost/bank/API/transaction.php/' . $_SESSION['ytunnus'];
//Pass the data that the user has entered
$data = json_encode(array("from" => $_POST['startdate'], 'to' => $_POST['enddate']));
//Initialize curl $ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data); //SSL verification set to true
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
/* 0: Don’t check the common name (CN) attribute
* 1: Check that the common name attribute at least exists
* 2: Check that the common name exists and that it matches the host name of the server
*/
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
// Certificate is necessary to communicate with the code behind
curl_setopt($ch, CURLOPT_CAINFO, "C:\\xampp\\apache\\conf\\ssl.crt\\server.crt"); //Parse the values that are received of the API
$response = json_decode(curl_exec($ch), true); curl_close($ch);
?>
Figure 26 shows a POST request. The data send to the server is in JSON format, and the answer is also in a JSON format and processed as an array.
<?php
$url = 'http://localhost/rest/02/put.php'; $ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "DELETE"); curl_exec($ch);
curl_close($ch); ?>
Figure 27 shows how the PUT request is set up. The PUT method isn’t used in this project.
Figure 28 shows how the DELETE method is possible with curl. The DELETE method is not used in this project
<?php
$url = 'http://localhost/rest/02/put.php'; $fh = fopen('data.txt', 'r');
$data = file_get_contents('data.txt'); $ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_PUT, true); curl_setopt($ch, CURLOPT_INFILE, $fh);
curl_setopt($ch, CURLOPT_INFILESIZE, strlen($data)); curl_exec($ch);
curl_close($ch); ?>
Figure 27 Curl PUT method(Sandoval, 2009)
4.5.5.3 OpenSSL
This project makes use of XAMPP 1.8.1, which is a program making it possible to run a
webserver on one’s own local machine. XAMPP uses Apache 2.3, MySQL 5.5.27, PHP
5.4.7, phpMyAdmin 3.5.2.2, and the OpenSSL service 1.0.1. To make use of the HTTPS with SSL, a certificate is necessary. Libcurl needs that certificate to make sure that sent data is encrypted. There is by default no certificate available with the installation. To make sure that the certificate is correct, some commands are necessary.
Figure 29 shows the first command that generates the private server key.
The next code generates the certificate signing request.
Figure 30 shows the code line that asks the user for some configuration parameters. These parameters need to be well chosen, since if these are wrong the libcurl will not work.
The last code line will sign the certificate. See Figure 31.
Afterwards, the certificate is made and the libcurl can use it. Before the libcurl can work the httpd-ssl.conf needs to be changed. In the conf-file the following parameters need to be changed:
SSLCertificateFile "path/to/server.crt" SSLCertificateKeyFile "path/to/server.key" >opensslgenrsa -des3 -out server.key 1024
Figure 29 Generate a server.key
>opensslreq -new -key server.key -out server.csr Figure 30 Certificate Signing Request
>openssl x509 -req -days 365 -in server.csr -signkeyserver.key -out server.crt Figure 31 Sign the Certificate
When the conf-file is changed the server needs to reboot, after which the libcurl will work. (Pavan, 2009; Chng, 2009)
4.5.6 OAuth Authentication Framework
In a client-server model, authentication of the client to the server is an important issue. There are several ways to accomplish authentication, one of which is regular authentication by username and password. This is basic authentication good for basic website protection. When security is more important basic authentication is not enough; therefore, IETF (Internet Engineering Task Force) made an authentication framework called OAuth. The next paragraphs elaborate on different authentication methods and how OAuth works.
4.5.6.1 Principle concept
Within a classic client-server authentication, the client wants to use access protected resources on the server, which is done by authentication with the server. The authentication happens with the credentials of the resource owner. As the resource owner shares its own credentials with the third party application, some problems and limitations arise:
The resource credentials are stored in the third party applications for future use, often in clear-text.
The servers have to support password authentication, even if this causes security weakness because of the passwords.
The third-party application can have broad access to protected resources, without the resource being able to limit access to and duration of the resource. Resource owners cannot limit access of one third party without limiting access of all third parties, which can then only be done by changing the third-party’s password.
Changing any third party application will result in a change of the end-user’s password and all the data that is protected by that password.
(Hardt, 2012)
OAuthwill deals with these issues by introducing an authentication layer, and making a separation between the client role and the resource. The client requests access to the resources through a resource server that is controlled by the resource owner.
The previous attempt to access resources used the resource owner’s credentials, now the
client gets an access token, containing the scope, lifetime and other access attributes. The access tokens are gained from an authentication server.
In OAuth there are four important roles:
Resource owner: The entity that is able to give access to the protected resources. Resource server: The server that owns the protected resources and is capable of accepting and responding to the requests for accessing the protected resources through access tokens.
Client: The application that makes requests for accessing the protected resources, and this with authorization of the resource owner.
Authorization server: The server that gives the access tokens to the client after a successful authentication of the resource owner and obtaining authorization. (Hardt, 2012)
4.5.6.2 Handshake
Figure 32 shows how the authentication works for OAuth2 between the four roles. a) The client requests authentication from the resource owner. The client can get its
authorization request directly from the resource owner or preferably indirectly via the authorization server.
b) The client receives an authorization grant. This is a credential that stands for the
resource owner’s authorization, and represents one of the four grant types or an
existing grant type. The type of grant type is depending on the method used by the client.
c) The client asks for an access token by presenting the authorization grant and shows this to the authorization server.
d) The authorization server checks if the client is authorized to access recourses and validates the authorization grant; if valid the access token is given.
e) The client presents the access token to the resource server and asks for access to the protected resources.
f) The resource server checks the validation of the access token and if its valid the server gives the client access to the resources.
(Hardt, 2012)
4.5.6.3 Authorization Grant
There are several authorization grant methods. The different methods all have the same purpose: the client needs to have authorization to access the resources and this is done by obtaining an access token.
4.5.6.3.1 Authorization Code
The authorization code is received from the authorization server that acts as an intermediate layer between client and resource owner. This means, that the authorization is not requested directly from the resource owner, instead the client is redirected to an authorization server that returns the authorization code to the client.
The client never gets the resource owner’s credentials, since this information is never
shared. Instead the resource owner is authenticated with the authorization server and the authorization code is send through the authorization server to the client. (Hardt, 2012)
The authorization code grant type is used to access and refresh the tokens. The client
must be able to communicate with the resource owner’s user-agent, because this grant is
redirection-based flow. Moreover, the client must be able to receive incoming request that are redirected from the authorization server. (Gazit, Authorization Code Grant, 2012)
Figure 33 shows the flow of the authorization code grant type. These are the following steps:
a) The flow is initialized by the client through the user-agent of the resource owner to the authorization endpoint. The client request includes the client identifier, requested scope, local state and redirection URI that is needed for the authorization server to send if the access is granted or denied.
b) The resource owner is authenticated by the authorization server via the user-agent. The authorization server establishes the connection if the resource owner
grants or denies the client’s access request.
c) If the access is granted, the authentication server will redirect the user-agent to the redirection URI that is given by the client. The redirection URI contains the authorization code and previous state of the client.
d) The client requests for an access token from the authorization server, this is done by including the authorization code that has been send in the previous step. The redirection URI that is used for getting the authorization code is verified by the client.
e) In the last step the authorization server authenticates the client by checking the authorization code. If this is all valid the authorization server will respond with an access token and optional a request token.
(Gazit, 2012)
