Name service for accessing personal services from Web servers

(1)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2015

Rafael

Figueiredo

Name service for accessing personal services from

Web servers

Servi¸

co de nomes para acesso de servidores Web a

(2)

(3)

Universidade de Aveiro Departamento deElectrónica, Telecomunica¸cões e Informática, 2015

Rafael

Figueiredo

Name service for accessing personal services from

Web servers

Servi¸

co de nomes para acesso de servidores Web a

servi¸

cos pessoais

Disserta¸cão apresentada à Universidade de Aveiro para cumprimento dos re-quesitos necessários à obten¸cão do grau de Mestre em Engenharia dos Com-putadores e Telemática, realizada sob a orienta¸cão cient´ıfica de André Ven-tura da Cruz Marnoto Zúquete, Professor do Departamento de Eletrónica, Telecomunica¸cões e Informática da Universidade de Aveiro, e de Fábio José Reis Luis Marques, Professor Adjunto da Escola Superior de Tecnologia e Gestão de Águeda da Universidade de Aveiro.

(4)

(5)

o j´uri / the jury

presidente / president Tom´as Ant´onio Mendes Oliveira e Silva

Professor Associado da Universidade de Aveiro (por delega¸c˜ao do Diretor de Curso)

vogais / examiners committee Andr´e Ventura da Cruz Marnoto Z´uquete

Professor Auxiliar da Universidade de Aveiro (orientador)

Jo˜ao Coelho Garcia

(6)

(7)

agradecimentos / acknowledgements

Quero agradecer aos meus pais, à minha irmã e a todos os meus colegas e amigos que me acompanharam nestes últimos meses,. Queria também agradecer ao Professor Doutor André Zúquete e ao Professor Doutor Fábio Marques por me guiarem e orientarem neste percurso sempre que precisei. Não teria conseguido sem todos vocês. Obrigado.

(8)

(9)

Keywords HTTP, Web service, personal service, Broker, browser, HTTP redirection, name server

Abstract The purpose of this thesis was to devise a mechanism to allow Web servers (or services) to find out and use other Web services running locally to Web clients (personal services). To do so, we had to create a solution for having a local name server to find out personal services (i.e., resolve names to service handles) and a solution for allowing Web servers to invoke personal services given those handles. The communication between the Web servers and the local name server or the personal services is mediated by the Web client (a browser) using a new HTTP redirection mechanism.

(10)

(11)

Palavras-chave HTTP, servi¸co Web, servi¸co pessoal, Broker, navegador, redire¸c˜ao HTTP, servidor de nomes

Resumo O propósito desta tese teve como base o desenvolvimento de um mecan-ismo que permitisse que servidores Web (ou servi¸cos) descobrissem e us-assem servi¸cos Web que executam localmente em rela¸cão aos clientes Web (servi¸cos pessoais). Para conseguir isto, desenvolvemos uma solu¸cão que permita a um servidor de nomes local a descoberta de servi¸cos pessoais (i.e., resolver nomes para referências para servi¸cos) e uma solu¸cão que permita aos servidores Web a possibilidade de invocar esses servi¸cos pessoas usando as referências obtidas. A comunica¸cão entre os servidores Web e o servidor de nomes local ou os servi¸cos pessoais é mediada pelo cliente Web local (um navegador) usando um novo mecanismo de redire¸cão HTTP.

(12)

(13)

List of Figures

2.1 Taxonomy of issues in name systems design and implementation [36] . . . 10

2.2 Domain Name Space vs Unix File System . . . 12

2.3 HTTP redirection. . . 16

2.4 Network Address Translation . . . 19

2.5 Gnome application technology stack . . . 20

2.6 Plugin Architecture . . . 21

3.1 UDDI Architecture . . . 29

3.2 Simple, Open, Broad Industry Support . . . 30

3.3 Third entity and a personal service communicate through a proxy plugin P 33 3.4 Third entity can redirect the brower to a personal service. . . 33

4.1 Broker exploitation architecture. . . 38

4.2 Browser redirection . . . 39

4.3 Redirection mechanism maintains the HTTP header logic but exchanges different metadata . . . 40

4.4 First access made to the broker will trigger its instantiation . . . 41

4.5 An Object in an Directory System . . . 42

4.6 Personal services may have configuration or descriptive attributes. . . 43

4.7 Name resolution . . . 43

4.8 Service listing . . . 44

4.9 General interaction architecture. . . 45

4.10 A single HTTP server can provide multiple services. . . 47

4.11 Addressing a resource in a typical Web service versus addressing a resource in a personal service. . . 47

4.12 Storing attributes for a personal service that support multiple services. . . 49

4.13 Our architecture supports different use cases. . . 51

5.1 Attribute matching . . . 58

6.1 WebKitGTK supports callbacks through a signalling mechanism. . . 64

6.2 Callback mechanism to reach the Broker. . . 65

6.3 Callback mechanism when instantiating a new personal service. . . 66

6.4 Name resolution capture . . . 72

6.5 Handle plain-text capture . . . 72

6.6 Handle encrypted capture . . . 73

6.7 Web server invokes a service giving a previously stored handle. . . 73

6.8 Personal service invocation capture. . . 74

6.9 Client address pool is separated in different access lists. . . 75

(18)

6.11 User interaction employs local communication . . . 76 6.12 Manage the services using a simple interface . . . 77 7.1 Stream or download multimedia files. . . 80 7.2 Media player instantiated in a independent window playing an 1080p video. 81 7.3 Portable Document Format (PDF) signer exploring the Cart˜ao de Cidad˜ao

Electronic IDentity card (eID) . . . 82 7.4 Web server page for the PDF signature . . . 83 7.5 Local user interaction regarding access control to the PDF signining

per-sonal service. . . 83 7.6 File dialog presented by the PDF signing personal service . . . 84 7.7 Menu to enter the Cart˜ao de Cidad˜ao signature Personal Identification

Number (PIN). . . 84 7.8 Final redirection from the personal service to the browser back to the Web

server . . . 85 B.1 Manage the logging options using the user interface. . . 94 B.2 Add new services using the user interface, edit the information and then

persist it. . . 95 B.3 Media player personal service interface. . . 95 B.4 Personal service invocation capture. . . 96

(19)

List of Tables

2.1 HTTP redirection class. . . 16

3.1 An example of a X.500 directory entry using X.500 naming conventions. . 25

5.1 Protocol main structures. . . 53

5.2 Protocol fields for the exchanged messages. . . 54

5.3 Broker configuration fields. . . 55

5.4 Service configuration attributes. . . 56

5.5 Operations Supported by the Interpreter. . . 57

5.6 Classes of characters used in regular expressions . . . 59

5.7 List of relevant characters that can be used in regular expression used to express personal service names . . . 60

5.8 Formal syntax. . . 61

5.9 Error situations and respective result code . . . 62

6.1 Midori main additions and changes. . . 63

6.2 Broker package definition. . . 68

6.3 Logging features. . . 74

6.4 Available syntax for access control lists . . . 75

6.5 Resources supported by the Web server. . . 78

A.1 Service listing message fields. . . 91

A.2 Name resolution message fields. . . 92

A.3 Message from the browser to instantiate a service. . . 92

A.4 Service invocation request. . . 92

(20)

(21)

Glossary

API Application Programming Interface. 6, 20, 22, 29, 37, 47, 82 BSON Binary JSON. 69

CC Cart˜ao de Cidad˜ao. 34

DHCP Dynamic Host Configuration Protocol. 31, 32 DIB Directory Information Base. 24

DNS Domain Name System. 5, 12, 13, 23, 24, 28, 30–32, 35 eID Electronic IDentity card. vi, 34, 79, 82

FLAC Free Lossless Audio Codec. 88

GNOME GNU Network Object Model Environment. 20 GUI Graphical User Interface. 20, 37, 50, 75, 77, 80 HD High Definition. 88

HTML HyperText Markup Language. 3, 6, 16–19, 21, 78

HTTP Hypertext Transfer Protocol. iii, v, 3–6, 9, 15–21, 29, 32–36, 38–40, 46–48, 63–65, 67–69, 71, 78, 82, 88, 91, 100

HTTPS Hyper Text Transfer Protocol Secure. 19, 38 ID Identification Data. 76

IdP Identity Provider. 33, 34

IIS Internet Information Services. 88

IP Internet Protocol. 6, 15, 23, 24, 33, 34, 44, 54, 56, 75, 87, 93 IPC Inter-process communication. 46, 50

JSON JavaScript Object Notation. 63, 67, 69, 76, 78, 100 KDE K Desktop Environment. 59

(22)

LDAP Lightweight Directory Access Protocol. 37

MIME Multi-Purpose Internet Mail Extensions. 5, 16, 21, 29 NAT Network Adress Translation. 9, 18, 19, 31, 32, 36 NMAP Network Mapper. 59

NPAPI Netscape Plugin Application Programming Interface. 4, 5, 9, 22, 34, 88 NSS Name Service Switch. 11

PCP Port Control Protocol. 31

PCRE Pearl compatible regular expressions. 59 PDF Portable Document Format. vi, 21, 77, 79, 82–84 PIdP Personal Identity Provider. 5

PIN Personal Identification Number. vi, 82, 84 PPAPI Pepper Plugin API. 4

PSM Personal Service Manager. 14, 15, 26, 42, 43, 59 QoS Quality of Service. 29

SAML Security Assertion Markup Language. 34 SOAP Simple Object Access Protocol. 29, 30 SSDP Simple Service Discovery Protocol. 31, 32 SSL Secure Socket Layer. 34

SSO Single Sign-On. 34

TCP Transmission Control Protocol. 5, 6, 34, 36, 40, 44, 55, 56, 87, 88 UDDI Universal Description, Discovery and Integration. 28–30, 37 UI User Interface. 4, 37, 50, 52, 63, 76

UNP Universal naming protocol. 27 UPnP Universal Plug and Play. 31, 32

URI Uniform resource identifier. 5, 15, 17, 18, 36, 39, 47, 92 URL Uniform Resource Locator. 7, 9, 15, 17, 46, 47

URN Uniform Resource Name. 6, 47, 79

WSDL Web Service Definition Language. 29, 30 WWW World Wide Web. 3, 15, 19, 38

(23)

Chapter 1

Introduction

Over the past two decades the World Wide Web (WWW) has had an exponential growth. What was once an exchange of simple text-based HTTP [8, 11] messages to display static HyperText Markup Language (HTML) pages has grown into something much more complex. We have seen developers push a lot of complexity into the server-side and also seen how the client-server-side is dependant on that complexity. Nowadays, HTML pages are only a skeleton for technologies like Javascript (or other scripting languages). Those technologies contain all the actual interaction logic, controlling the browser, for instance, changing the content that is displayed to the user. An increasing complexity in the Web also resulted in an increasing diversity of services available. Services may take many forms and be provided in many ways. A service that is invoked over the Web is commonly referred to as a Web service.

This thesis proposes a new mechanism for allowing Web services/servers to invoke personal Web services. Personal services are Web services that are provided by a user to provide some service that is useful both for himself and a Web service he is using. To allow Web services to find out which personal services are available to them, given a particular request from the user’s Web client, we need to have a local name server, which we call the Broker. Its job is to offer personal service discovery and provisioning to Web services. The Web services communicate with the Broker and the personal services, which are Web services, through the Web client. In this sense, the Web client mediates all the communication between the server-side (Web services) and the user-side (Broker and personal services).

Our name server, the Broker, supports an attribute-based naming paradigm, in which the personal services will be identified by a set of attributes describing them. These attributes will be based on the functional and operational properties of the services that they intend to describe. When performing service discovery, the Web services purpose should be to match a set of attributes (or properties) against the ones of the personal services being used by the Web client (either totally or partially).

After finding a suitable personal service, the Web service should have the means to invoke it. This is possible by resolving names into service handles, which allow the Web service to later invoke the intended local services using them. To be able to access the local entities (both the Broker and the personal services), the Web Service will use a new HTTP redirection mechanism implemented by browsers.

(24)

1.1 Motivation

Web technologies are evolving at an extremely fast pace. Users are becoming increas-ingly demanding and they fail to understand that maintaining software is often hard and sometimes impossible. One methodology that allows the addition of features to Web ap-plications is the usage of the trendy extensions and/or plugins within browsers. Although they cannot be viewed as a Web service, one must admit that the usage of extensions in browsers has greatly improved the overall user experience.

Nowadays, browser’s plugins and extensions are able to provide all kinds of services, ranging from adding toolbars to the browser to the addition of support for particular technologies (i.e. Flash plugin from Adobe) or add new features (i.e. blocking ads, block Javascript, force HTTPS communication). Extensions are extremely popular because they enable particular developers or companies to add additional features to already existent Web applications by enlarging the browsers’ core functionality. For the development of browsers this is extremely critical, because there are few existing browsers that are popular (Chrome, Firefox, Safari, Opera) and therefore it is much easier to add features to those existent browsers than it is to make a new one, which would probably not be used unless it was supported by a major company. Extensions and plugins are, thus, extremely versatile and allow users to enjoy additional features without much effort to the developers.

However, there are still some drawbacks. Browsers’ extensions can only interact with either the User Interface (UI) or the HTTP engine at certain well-defined points. Browser extensions are allowed to take advantage of the browser interface (i.e. add toolbars, icons, colours, open windows) but they still lack the benefits that come with an application that runs on its own (i.e. specific UI requirements).

Deploying a service in different browsers (through an extension or a plugin) forces the developers to produce multiple software implementations to different browsers. Netscape Plugin Application Programming Interface (NPAPI) and Pepper Plugin API (PPAPI) are cross-platform plugin architectures that both aim to bring extension compatibility across different browsers (assuming they support the standard). NPAPI in particular is very successful and is used by major companies: Oracle Java1, Microsoft Silverlight2, Google Earth3, Facebook video chat, etc.

In April 2015, the Google Chrome browser changed its default settings and removed support for NPAPI, forcing their users to manually re-enable its support. It also an-nounced that as of September 2015 they will cease all NPAPI support, leaving two choices for all NPAPI compliant extensions developers: either migrate to another standard or be branded as a legacy system. Google Chrome PPAPI tried to solve NPAPI issues by of-fering yet another standard for cross-platform plugins, but Mozzila announced that they were not interested in working with it. Even if they did want to work with it, there would be no assurance that they would always support the standard. This example clearly shows that companies struggling for standard supremacy can have a major impact on the future exploitation of plugins.

Users are often the reason that leads to software malfunction. The fact that plugins add functionality to the browser may also lead to some collision of interests. A good example of that are the famous Javascript blocking plugins (NoScript4for Firefox, Chrome

1 https://www.oracle.com/java/index.html 2 https://www.microsoft.com/silverlight/ 3_{https://earth.google.com/} 4 https://noscript.net/

(25)

ScriptSafe5 and Safari JS Blocker6). The user often sees these plugins as the magical tool that will enable unprecedented protection to their personal browsers but they seldom realize that these plugins are often hard to use and will eventually lead to unwanted results. We are motivated to decouple our architecture from such problems and maintain the communication using low-level HTTP.

These were just two examples of the limitations that plugins suffer from. There is one immediate conclusion. Due to browser updates (or other software), plugins may no longer work or have unexpected behaviour. There is no guarantee that the browser plugins will always work since it is always possible that the browser gets updated and lose support for a technology that they depend on. All in all, while browser plugins allow for additional features they are still just an extension and they are always dependant on the browser.

Exploring the usage of personal services would allow the user to isolate plugins from the browser and as a result also allow it to be completely self-reliant. Isolating a plugin from the browser will also protect it because it is no longer restricted by the impositions that the browser may place (i.e. blocking Java applets, imposes security constraints, blocking Javascript).

This topic was explored in previous work [37]. In that solution, a personal service was used to authenticate users using a Personal Identity Provider (PIdP). That service ob-tained the user credentials by exploring the Portuguese citizen card (Cart˜ao de Cidad˜ao) and, this way, shifting the exploration of smart cards from the browser to a personal service, which acted as a personal identity provider. We are motivated to create a so-lution that would allow any type of personal service to seamlessly (from the local user perspective) be invoked by Web services.

1.2 Problem

Using personal services allows the user to isolate plugins from the browser. However, while public Web services or plugins could be explored by a remote Web service, by using either an HTTP redirection or by triggering plugins using specific content (i.e. trigger-ing NPAPI compliant plugins by ustrigger-ing specific Multi-Purpose Internet Mail Extensions (MIME) content types on the HTTP response), HTTP does not support a redirection mechanism towards personal services bound to a particular name, for example, by map-ping names into local Transmission Control Protocol (TCP) ports. The common HTTP redirection uses a HTTP location header containing the Uniform resource identifier (URI) where the resource is located, and no name resolution exists other than a Domain Name System (DNS) name in the URI.

Web services could still use an URI to redirect their calls to personal services, but that would imply two things [37]: (i) the Web services would need to know the service location (IP address and TCP port); (ii) the personal services would most likely be obliged to use static, well-known ports (removing flexibility and exposing the personal services location). The usage of personal services implies local management of the services in question, which would most likely result in different configurations across different users. Before the Web service could be able to invoke the personal service by redirecting the Web client to it, it would need to learn the service’s local address (IP address and TCP port), which would require some discovery mechanism or at least the exchange of messages prior to the redirection.

5_{https://code.google.com/p/scriptno/}

6

(26)

Given the lack of flexibility that the HTTP redirection shows to allow Web services to invoke personal services, there are two mechanisms that are essential for a scalable, personal service architecture:

1. A local name server that allows service discovery and provisioning (by resolving names into service handles).

2. A new HTTP redirection mechanism that allows the Web service to invoke personal services, given those handles.

1.3 Contribution

We allow Web services to discover and invoke personal services by using a name server (Broker) that is local to the Web client. With this, the user running the Web client (browser) is able to isolate his personal services from the browser, avoiding all the drawbacks mentioned in section 1.1. To contact either the Broker or the personal services, the Web service expresses that intent by using a new HTTP redirection mechanism. The redirection allows the Web services to access both entities without having knowledge of their location (Internet Protocol (IP) address and TCP port). Note that although we are using a new HTTP redirection, it still uses the fundamental HTTP paradigms in the structure of such HTTP messages.

We deliberately decoupled our communication paradigm from higher-level technolo-gies, such as Javascript. This way, it is the browser that manages the redirection mecha-nism, instead of the Web services through downloaded Javascript programs. By using core HTML mechanisms, and assuming that our new redirection mechanism would be part of them, we also allow the implementation to be independent of the Web client (all browser should implement it) or the page content. This might seem like a high cost but browsers commonly launch daily updates, so, it is not unprecedented to add new functionality to them. The actual browser that we updated for testing our proposal was Midori7.

To provide personal service discovery and provisioning we developed an attribute-based name server, the Broker, which is also local to the user. The Broker allows rich service descriptions, based on an multi-attribute schema. Services are described using a set of attributes that are based on their operational and functional properties. To perform service discovery, the Web services and the Broker should both share a formal query language, which we also propose.

After a successful name resolution, a Web service obtains an opaque handle for a personal service. Being opaque means that the handle will only make any sense to the browser providing it (should be encrypted and the browser should be the only one em-powered to decrypt it). In this sense, the location information about a particular personal service is never leaked to a Web service within a personal service handle. The only way the Web service has to contact the personal service is by using that handle on a invocation request returned to the browser that provided the handle.

Local services are in fact Web services. They expose an Application Programming Interface (API) through the different Uniform Resource Name (URN) that are defined in their interfaces. This allows a personal service to expose different resources, or different functionality, through the usual HTTP means to do so. Several services were developed and integrated in this architecture for a proof of concept. The aim of those services was to demonstrate relevant situations for the use of personal services. That includes:

7

(27)

1. Explore personal services that can behave as an autonomous application. For this, we developed a personal service that can display media content (this would possibly replace media plugins).

2. Explore personal services that require user interaction but take advantage of the browser to do so. We developed a service to demonstrate that this is possible. 3. Explore personal services that can discriminate the client intent by having knowledge

of the description the client used when searched for it, and, in this way, be able to provide different services depending on that description.

1.4 Organization

This thesis is divided in 8 chapters. This was the first one and its purpose was to give the reader an introduction to the work that was done and why it was done. The next chapter, Chapter 2, will offer the reader some background about concepts that are relevant to the work. Readers that are knowledgeable in the taxonomy of issues in name systems design or in Uniform Resource Locator (URL) redirection mechanisms can skip this chapter.

Chapter 3 presents the related work. In this chapter we will give a particular emphasis to existing name systems and discuss some of their design choices.

Chapter 4 begins by enumerating our major design goals and giving some insight into what is expected from each. Then, it describes our system’s architecture, explains the messages exchanged and identify the responsibilities that each entity has.

Chapter 5 explains in detail the communication and the name service access protocol, namely, the structure of the exchanged metadata, how to register services and the name service query language.

Chapter 6 describes our implementation of the proposed system, addressing the tech-nologies used and why they were chosen.

Chapter 7 describes our use cases and the personal services that we developed for a proof of concept of our proposal. In this chapter we also show how the architecture can be explored by giving a step-by-step on how to invoke the developed personal services using Web services.

Finally, in Chapter 8 we conclude this thesis by providing a critical overview of the benefits and limitations of the solution proposed and putting forward future work possi-bilities.

(28)

(29)

Chapter 2

Context

This chapter aims to provide the reader with some background on the related topics for this thesis.

Section 2.1 discusses some issues regarding the design and implementation of naming systems. We also occasionally compare the discussed designs with the approach we took in our proposed solution.

Section 2.2 presents a brief explanation of the HTTP standard, discusses some of the most popular URL redirection approaches and gives some insight to which we chose and why.

Section 2.3 discusses the problems that domestic firewalls and Network Adress Trans-lation (NAT) boxes create, in our scenario, and presents a solution.

Section 2.4 describes the technologies behind the browser we opted to adapt (Midori), compares plugins and extensions and finally describes NPAPI.

2.1 Name Server designs

A name system is a service that resolves names into objects. To perform a name resolution, entities should communicate with the name service using some pre-established standard. A name service may support three major operations: (i) the resolution of names into objects; (ii) binding and unbinding of objects; (iii) the ability to list names or provide general object description.

Figure 2.1 shows the different name system designs, as described in [36]. The design of a name system ranges from a single server providing simple name resolution (e.g. map names into physical addresses) to distributed solutions composed of complex query mechanisms and with elaborate requirements (e.g. fault tolerance, access control, data replication, load balancing). Every name system has its own requirements and, therefore, also has its own internal mechanisms. This section will give some context into the issues that may affect the design and implementation of name systems. This section will also be useful to later on identify why existent name systems do not comply with our requirements. A name system may provide white-page services, yellow-page services or both. The terms white-pages and yellow-pages were originally used to refer to the telephone book. The latter refers to businesses, while the former lists individuals. A white-page service purpose is to return information about an object when queried with the object’s name (e.g. return a individual telephone number from a given name). More advanced white-page services may allow the user to identify objects using identifiers other than its name. These kinds of services are commonly called descriptive (or attribute-based) white-page services. While white-page services aim to identify objects, a yellow-pages query aims to

(30)

(31)

target a specific class of objects by giving a generic description. These systems typically employ a flexible attribute-based query mechanism and allow the users to perform different query operations. White-page services and yellow-page services are often seen as the same thing (or at least their differences are arguable) since a white-page service that enables descriptive naming is fundamentally the same thing as a yellow-page service [25, 36].

2.1.1 Semantic and syntactic matching

According to F. Giunchiglia and P. Shvaiko [27], semantic matching is a technique that verifies if two graph-like structures semantically correspond to one another. It can be any kind of classification, taxonomy, ontology or eXtensible Markup Language (XML) schema. Semantic matching tries to find semantic correspondences by mapping meanings, contrasting with syntactic matching that tries to map labels (or tags). Semantic matching also takes into account the semantic similarity relation between elements.

In syntactic discovery, given a query with a certain set of filtering requirements, the discovery problem involves finding a specific entity that can fulfill the given input and output criteria solely based on a syntactical equivalence of the input and output names. For instance, in [25] the author defines that one pair of attributes, one being given as an argument and the other being registered in the database, are considered equal if the intersection of their set of strings (syntactic matching) is nonempty. Our naming system ignores the semantics behind the registered attributes and, instead, only perform syn-tactic matching. Unlike [25], we do not only consider the intersection of strings when matching names. Regular expressions have gained considerable popularity over the past years because they allow pattern matching. Using patterns allows the name server clients to match attributes without fully knowing what to look for. In our system regular expres-sions may be particularly relevant because initially the clients are not expected to have any knowledge of the existing registered personal services and their definition (description).

2.1.2 Name assignment

A naming convention greatly influences how the name system manages its objects. A naming convention may be structured or non-structured. A non-structured convention is the most simple and is typically seen running on a single centralized server using a flat name space. A fairly well-known example of this is the Name Service Switch (NSS)1 which manages the Unix registered users and groups by calling several name services (in a specific order),typically the first is the well-known Linux files (/etc/passwd, /etc/group and /etc/hosts). Using a flat name space makes it extremely simple to manage the registered objects or even add new name definitions, but does not allow or makes it practically impossible to use it for distributed solutions.

Flat name spaces do not match distributed solutions because they do not facilitate decentralized naming and/or locating distributed information. This is largely due to the fact that it is extremely hard to locate unique names in a distributed name space. While in a centralized model a single central authority is responsible for assuring uniqueness for each entry, in a distributed model that is not so easy to accomplish. A hierarchical naming convention is suited for a distributed scheme because it allows many authorities to share the registration and administrative process. This process is commonly called incremental name resolution. Flat name space would possibly work in a distributed system but it

1

(32)

would require extensive configuration (to allow the name servers in locating authoritative servers for a given name).

Using structured naming conventions allows the system to break each name in different parts. Separately, they should have no meaning, neither semantic nor syntactic (see Section 2.1.1), but are still relevant enough to be forwarded in the distributed network. A structured naming convention may employ either attributed or non-attributed names. A name system can define if a structured name is composed of a indefinite amount of components or define a boundary limit. They can also define how to separate a name into its separated components (e.g. separate each component using symbols like ”/” and ”.”). A structured name is often correlated by its geographical location, the structure of organizations (e.g. physical addresses of machines in distributed networks) or by the location of an object in a machine (e.g. Unix file system). The most common structure is a hierarchical naming convention with a tree-like name space. There are numerous examples of this pattern: Unix file systems, DNS, X.500, etc. Name spaces structured in a tree-like structure may define limits for the tree depth and, in this sense, limiting the amount of components that a name can have. There are other approaches that use graphs, instead of trees, which allows for more complex mechanisms like the same name having multiple paths across the graph (allowing aliases). This is particularly useful in descriptive systems where the same object may be described using different descriptions, for instance, a full description and a short description.

Figure 2.2: Domain Name Space vs Unix File System ( from http://www.kernel-panic. it/openbsd/dns/dns2.html)

Figure 2.2 shows an example of a DNS name space and compares it to a typical Unix file system. The similarities between both are evident. Both systems have a highly hierarchical structure.

The hierarchical structure of the DNS allows for the decentralization of its administra-tion. In fact, an organization in charge of a domain can delegate, e.g., assign responsibility for a sub-domain to a different organization and only maintain information about the non-delegated part of the domain (called a zone). This kind of conventions are clearly powerful if the names are to be structured by their object geographical location.

As explained, an hierarchical convention is suitable for a distributed system. In our scenario, each user has a centralized name server acting as the sole naming authority for the whole system. There are three things that can already be excluded from our design: (i) using a distributed model (ii) using an hierarchical structured naming convention (iii) using semantic matching. Thus, we will define our name architecture here.

(33)

We allow the user to register an arbitrary amount of attributes (or properties) to describe the service and a fixed amount of attributes that provide configuration properties. The latter are only read by the name server and its name (configuration) is pretty self-explanatory. The name size (amount of attributes) is not limited by the name server, thus, a user may register a service with any amount of attributes (excluding duplicates). In terms of name rules or syntax we expect numbers and letters (numbers and strings) but any character supported by UTF-82 is accepted. Finally, the name architecture itself is, as expected for a centralized naming system, a flat name space. Our name server is responsible for assuring the uniqueness of each registered object and also to provide authoritative decisions for our entire name space (which is conditioned by the user configuration).

2.1.3 Name Distribution

This brings us to another discussion. The difference between centralized models (e.g. ours) and distributed models (e.g. DNS). In a centralized model, a single name server is responsible for providing authoritative decisions for the whole name space. A centralized model is typically used when there is a need to focus the administration of the whole system in a single place (or entity).

The distributed model is motivated by considerations of consistency, reliability and extensibility. According to [5], there are some approaches that can be considered hybrid. For instance, a logical centralized name server may have an implementation that consists of several physical name servers.

Our local name server is responsible for only managing the user personal services. As such, it follows the centralized model.

2.1.4 Name resolution

Name resolution is the process of determining the naming authority of an object given its name [32] followed by the binding of that given name. A name resolution procedure involves searching for a valid name server (for that name) and determining the correct function to execute in the interpreter. The interpreter should be able to process the given names and retrieve the necessary information from a database.

There are two different name resolution methods: absolute and incremental. If an authoritative name server has the means to execute a name resolution, resolving a given name by itself, then the process may be called an absolute name resolution. In an in-cremental name resolution, the name server only resolves part of the name, if able, and forwards the request (on behalf of the client) to another name server. This process is repeated until the name is completely resolved. For instance, given the DNS name space of the Figure 2.2, to resolve the name mail.kernel-panic.it, each name server will resolve a part of the name. The name is divided by the separator ”.” and is forwarded through the tree in a top to bottom approach. The network host is typically configured with the root name servers. These are responsible for finding the authoritative name server for the top-level domain. In this case it is it. The top-level domain will find the authoritative name server for kernel-panic and so on.

Name resolutions in our system are fairly simple (aside from the formal language itself). The name server receives a name. That name is basically a set of attributes that should uniquely describe a personal service. Aside from the name, the requester should

2_{UTF-8 is a variable length character encoding that uses 8-bit code units. It is possible of encoding}

(34)

also identify that the interpreter method to be executed is indeed a name resolution. Since the name server is the sole authority for the entire name space he can always provide an authoritative answer to the requester.

2.1.5 Database

A name server database may exist in two forms. It can be persisted in the machine or be loaded into the machine’s main memory. Having the database in the main memory re-moves the need to access the disk each time the name server has to read from the database, allowing the interpreter methods to directly access the database, adding efficiency to the whole process. Nevertheless, this can only happen if the whole database has a fairly small size and the version persisted in the disk is not changed often. For instance, imagine that the database is stored in a text based form. Using text-based storage solutions allows the users to manually edit, remove or add objects to the database. If any user effectively changes the database content, the name server’s version is no longer valid.

To solve this problem, solutions like periodically reloading the whole database may be employed (again, this would only be possible if the database has a fairly small size, like in local name servers).

In our scenario, we have a database supplying the local name server with the de-scription for our personal services. Since, in our case, we are expecting users to have particularly small databases (e.g. a database with 10 registered services and the name server configuration uses approximately 3KB) we use a text-based format to allow users to manually configure their services without recurring to graphical user interfaces (al-though we provide one). This database is loaded into memory when the name server starts. In our case, we are expecting the database to be read more times than written but, nevertheless, to avoid having outdated versions of the database loaded into memory, we periodically reload it.

2.1.6 Security concerns

Authentication and Authorization

One of the main aspects of a service discovery architecture is the establishment of a communication between a client, a name server and a third entity, a target server/service, that is previously unknown to the client (or, at least, the client does not know how to reach it).

In our architecture we do not authenticate the name server or the personal services (third entity). If the personal services and its clients require authentication they should define their own (after the client obtained the means to access the service). We are, however, adding a mechanism that associates a handle to the requester. This assures that after the requester obtained the handle he is the only legitimate entity for that handle. This way, even if the handle is shared or stolen, it will be to no avail. This also assures the personal services that the entities reaching them are authorized (by the Web client). Access Control

We perform two different types of access control. One is based on the configuration attributes of each service and is controlled by the Personal Service Manager (PSM) and the other are actions in real-time, performed by the Web client user. Those types work cooperatively but independently.

(35)

Firstly, we employ fine-grained access control. This means that the PSM is able to dictate, for each service, which entities (using either IP addresses, networks or domain names) are authorized and which are not. These rules follow one of two access control approaches: whitelisting or blacklisting. The PSM is responsible for deciding which ap-proach better suits each service (although it is able to use both at the same time, with the risk that one might shadow the other).

The first method is based on a configuration for each service. Once the database is loaded into memory those rules are immutable. The second method of access control is dynamic: this allows new rules to be added during a session. Basically, we take advantage of the browser capability to provide user interaction to allow real-time access control decisions. Much like when the browser asks the user if he wants to allow a certain action (i.e. typically through a pop-up window), when a Web server/service performs a name resolution for a service ,but, has no permission to do so, the local name server may ask the user, through the browser interface, for a temporary decision (session scoped). The user should be presented with several choices: (i) allow that Web server/service for the rest of the session; (ii) deny it for the rest of session; (iii) add a new permanent rule.

2.2 HTTP Protocol

The HTTP is an application layer protocol used to exchange/transfer hypertext. It is the base foundation for data exchange over the Internet and has its roots on the ap-pearance of the WWW. Its functionality is simple, it works as a simple request-response, client-server model. It has originated from the need to distribute hypermedia across the Internet and, in order for this to be possible, a communication standard was necessary. Through simple rules the HTTP protocol describes how transactions across the Internet are to be made.

Whenever a server receives an HTTP request it is expected to return a response. The response has a list of headers and a message body. The status code header is particularly important since it will dictate how the client will deal with the response. The status codes are divided in five different classes: Informative, Successful, Redirect, Error and Others. The redirect class demands additional actions from the client before the request can be completed.

2.2.1 URL Redirection

URL redirection may be used for several reasons. The premise of the whole process is the following: a resource that was found at X may now be found at Y. Practical scenarios include URL shortening, preventing broken links or facilitating user navigation by moving users from one page to another.

HTTP Redirection

There are several different redirection codes defined with different redirection char-acteristics and each should be used in different situations; yet, they all share the same final outcome: the client is redirected to another URI. Table 2.1 shows the HTTP 1.1 redirection codes and their meaning. When an user agent (browser) tries to access a resource at one URI but receives a redirection to another URI as a response, there is typically an HTTP header field3 containing the new URI attached. That header field is

3

(36)

Web Client Web Server Third Entity HTTP Request HTTP Redirect HTTP Request HTTP Response Figure 2.3: HTTP redirection.

called Location and is part of the HTTP standard.

Table 2.1: HTTP redirection class.

Code Name Meaning

3xx Redirection If a code belongs to the redirection class the user agent is expected to perform further actions.

300 Multiple Choices Indicates several options that the user agent may use to obtain access to the wanted resource.

301 Moved permanently Request resource has moved to a new permanent URI. 302 Found Requested resource was found under a different URI. 303 See other Request resource was found under a different URI.

The user agent must retrieve the resource using a GET method. 304 Not Modified The resource was not modified since the last access.

305 Use a proxy To access the resource, use the proxy given by the Location header.

307 Temporary Redirect The resource is temporarily found in another URI. Further resource accesses must use the original URI.

Script-based Redirection

Nowadays the declarative heart of the Web, HTML, seems more irrelevant every day. An HTML page is just a skeleton that carries all the complexity in the form of scripts.

As such, it is not uncommon to see Web servers redirecting the clients using scripting programming languages. Using the HTML tag <script> servers can include scripts that will be executed in the client side. The HTML <script> tag has a type which identifies the language of the script or format of the data and can be any MIME type. The most used language is Javascript and is typically identified by the type text/javascript. Its usage was actually made obsolete in RFC 43294 and, instead, application/javascript

4

(37)

should be used. Nevertheless, text/javascript still has better cross-browser support. Javascript suffers from the following problems:

• The browser may either block it or suspend it until further action (e.g. user inter-action);

• A scripted redirection will prompt the browser to move to another page. Unfortu-nately, it does not support different types of redirection. Unlike scripted redirection, HTTP redirection can use well documented redirection types (see 2.1) which the browser understands.

Although some browsers may not execute Javascript for security reasons, or be effec-tively enhanced to disable them (e.g. through extensions), it is still one of the most used ways for URL redirection.

1 <!D O C T Y P E H T M L> 2 < h t m l l a n g=" e n - U S "> 3 < h e a d > 4 < s c r i p t t y p e=" t e x t/j a v a s c r i p t "> 5 w i n d o w.l o c a t i o n.h r e f = " h t t p :/ /r e d i r e c t e d p a g e . com " 6 < / s c r i p t > 7 < t i t l e >J a v a s c r i p t R e d i r e c t i o n< / t i t l e > 8 < / h e a d > 9 < b o d y >

10 If you are not r e d i r e c t e d a u t o m a t i c a l l y, it m e a n s y o u r b r o w s e r is b l o c k i n g J a v a s c r i p t.

11 < / b o d y > 12 < / h t m l >

Listing 2.1: Redirecting a Web client using a script embedded in the HTML page is possible.

HTML Meta refresh tag and HTTP refresh header

Another methodology for redirecting Web user agents is the usage of the HTML <meta> tag to inject a HTTP refresh header. This technique allows the server side to tell the client which particular URI to load. Using a timeout of zero seconds the refresh effectively works as a redirect.

1 <!D O C T Y P E H T M L> 2 < h t m l l a n g=" e n - U S "> 3 < h e a d > 4 < m e t a c h a r s e t=" U T F - 8 "> 5 < m e t a h t t p - e q u i v=" r e f r e s h " c o n t e n t=" 0; URL = ’ h t t p :/ /r e d i r e c t e d p a g e . com ’ "> 6 < t i t l e >R e d i r e c t i o n u s i n g H T M L m e t a tag and H T T P r e f r e s h h e a d e r< / t i t l e > 7 < / h e a d > 8 < b o d y > 9 < / b o d y > 10 < / h t m l >

Listing 2.2: Injecting a HTTP refresh header (with content 0) in the HTML message allows the server to redirect the client to another page.

(38)

In Listing 2.2, the content attribute represents the seconds that the browser should wait before executing the redirection. The most common practice is to use 0 and to yield an instantaneous redirection.

Using the meta tag together with the HTTP has the following problems:

• In some cases the browser may ignore refresh requests that have a content with value zero. A solution for this would be to use a different content value (e.g. 1 second);

• According to W3C, the usage of the meta refresh tag may lead to several problems: – Servers that overuse this mechanism may get blocked5;

– Users might momentarily see page A before being redirected to page B (this typically happens if the content value is higher than 0);

– In some older browsers the back operation might become unusable6.

In conclusion, due to the great options available, using this methodology is not really advised.

2.2.2 Final remarks

We have described several issues that affect the redirection using the HTML meta tag and the script-based redirection. Now we will explain why we used HTTP based redirection and which are its advantages over the other types.

We mentioned that an HTTP redirection requires the browser to perform an additional step. This step is particularly important because it means that it is the browser that will control the redirection. In our redirection we maintain this logic by using the simple HTTP based redirection and allowing the browser to control the whole process. The only difference between our redirection and the existent HTTP redirection is in the metadata. HTTP uses the Location header field to identify the new resource (URI) but we use something entirely different (see Section 4.3).

Maintaining HTTP redirection brings several advantages:

• The Web client (browser) knows exactly what is going on because it is able to control the entire redirection process. This means that the Web client will be responsible for detecting the redirection, reading the attached metadata and process that metadata; • This kind of redirection mechanism does not suffer from previously mentioned lim-itations like being blocked by the Web client (or by its extensions) or resulting in unexpected behaviour (if the meta content value is higher than 0 the user will have to wait before being redirected).

• Every Web client fully supports (in principle) HTTP redirection.

2.3 Domestic firewalls and NAT boxes

The personal service providers (Web client users) are expected to be located in domes-tic networks. Typically, in a domesdomes-tic network, the clients are located behind a NAT [9] box (Figure 2.4).

5_{http://www.w3.org/wiki/HTML/Elements/meta}

6

(39)

NAT, however, prevents servers/services from invoking these personal services di-rectly. This happens because machines located in private networks (behind NAT) are not addressable (reachable) from public networks.

We could manually configure NAT to make the presence of the services visible (static entries) but that would force every service to use fixed ports and each new registered service would also require additional NAT configuration.

NAT

Box Servers

Clients

Private IP:PORT Public IP:PORT Private Network Public Network

Figure 2.4: Network Address Translation

To solve this problem, Web services/servers redirect the Web client to the personal services. This avoids the need to invoke the personal services directly. In sum, redirecting the Web client to personal services can:

• Avoid direct invocation. The Web client will act as a proxy between the personal services and the remote Web servers/services;

• Avoid additional configuration. HTTP and Hyper Text Transfer Protocol Se-cure (HTTPS) is generally not blocked by domestic firewalls. Also, since the traffic will always be initiated by the Web client, NAT should not pose any problem; • Centralized access control. Since the Web servers/services are redirecting the

Web client to the personal services, we can perform centralized access control in the Web client.

2.4 Web browsers

A browser is a software application used to locate, retrieve and display content on the WWW, including Web pages, text, images, videos and other files. The Web browser is the client on a client/server model that includes a Web client and a Web Server. The Web client contacts the Web server requesting information (typically called Web pages) and the Web server sends the information back to the Web client which displays the result on the computer or other Internet-enabled device.

Today’s browsers are extremely complex software suites that can interpret and display HTML Web pages, applications, Javascript or other content hosted on Web servers. Pop-ular browsers include Mozilla Firefox, Internet Explorer, Google Chrome, Apple Safari and Opera.

2.4.1 Event-driven architecture

When using a browser, there are always a lot of events happening. The amount of exchanged messages between the browser and Web servers may reach incredibly high figures. When an HTTP message is sent, there is no way to predict how long the reply

(40)

will take so, it is not realistic to block the execution and wait for a response every time a request is sent.

To solve this, browsers use an event-driven architecture (non-blocking) and because of this much of its functioning is based on the detection of events. An event is based on the occurrence of something that has significance to the software. A browser uses a complex system of signals that are emitted at certain well defined points. An event occurs each time a previously registered signal is emitted. For instance, each time a message is built, sent or received a signal is emitted.

2.4.2 Midori browser

All the previously mentioned browsers are backed up by large companies (Mozilla, Microsoft, Apple, Google, etc) that invest large amounts of money improving the software quality. To be able to prove our concept we had to choose a browser that supported all our requirements but at the same time was simple enough. The Midori browser is a lightweight, fast and open source browser. Midori is written in C and Vala7. It is fairly small for a browser (˜33000 lines of code) and uses WebKitGTK+8 and Libsoup9.

Application

WebKitGTK+ (UI Process)

WebKitGTK+ (Web Process)

WebCore

LibSoup

Figure 2.5: Gnome application technology stack

WebKitGTK+

Midori uses WebKitGTK+ as its Graphical User Interface (GUI) engine. WebKit-GTK+ is a GNU Network Object Model Environment (GNOME) framework that en-ables users to design applications that use a web platform with increased security and responsiveness.

Libsoup

Midori uses Libsoup as its HTTP engine. Libsoup is a HTTP client and server library for GNOME applications. It uses a synchronous and asynchronous(both GMainLoop10 and callback-based) API that integrates well with GNOME applications and is mainly used in threaded applications (like a Web browser).

7 https://wiki.gnome.org/Projects/Vala 8 http://webkitgtk.org/ 9_{https://wiki.gnome.org/action/show/Projects/libsoup?action=show&redirect=Libsoup} 10 https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html

(41)

Callback

A callback is a piece of executable code, typically a method, that is passed as an argu-ment to another piece of code. When a certain event occurs, the second code will invoke the previously registered executable code to deal with that event. Both WebKitGTK+ and Libsoup use a signalling mechanism. The point is to register a signal and pass a callback as an argument to that signal. When that signal is emitted the software will execute the previously registered callback to handle the event. Both WebKitGTK+ and Libsoup have a set of well-defined signals that, if registered, are emitted at certain specific points of the Web engine cycle of life, for the WebKitGTK, and of the HTTP message cycle of life, for the Libsoup.

2.4.3 Plugins and Extensions

For the sake of clarity the difference between a browser extension and a browser plugin will first be explained. A plugin is a third party library that ”plugs in” to the browser and can be, for example, embedded inside a web page using the HTML tag <embed> or <object>. They perform actions that are restrained to what one can do inside a Web page and typically respond to certain MIME types: Adobe Reader to display PDF files, Macromedia Flash for flash files, Apple Quicktime, etc. Extensions can interact with the browser interface and, thus, do much more. An extension can change the browser interface, process pages and, of course, interact with Web pages. Not only that but, while an extension may contain a plugin, the contrary may not occur. Throughout this document we will mainly talk about plugins but all our logic also applies to extensions.

Figure 2.6: Plugin Architecture (from http://www.codeproject.com/Articles/389667/ Simple-Plug-in-Architecture-in-Plain-C)

A plugin is, therefore, a piece of software that adds additional functionality to an existing software application. This is extremely important because when an application enables plugins it also enables user customization. This has gotten extremely popular and trendy because developers are very keen on making their own additions to already

(42)

existing applications. Plugins can be seen on many kinds of software but are particularly popular on browsers. Every well known browser supports plugins: Opera, Google Chrome, Mozilla Firefox, Internet Explorer, Safari, Midori etc. This has enabled users to add huge amounts of additional functionality to browsers and overall improved the user experience. Although plugins are extremely useful they have certain rules that they must abide. The plugin is only allowed to interact with the browser on certain well defined moments and therefore its actions are limited.

2.4.4 Netscape Plugin Application Programming Interface

NPAPI was developed by Netscape11 for their browsers, appearing for the first time in the Netscape Navigator 2.0 in 1995. NPAPI is a cross-platform plugin API and enables the same plugin to be used in different applications as long as the platform supports their standard. Each plugin must state the content types [12, 13, 20] that they are able to handle. Whenever the browser receives a message with that content type, it loads the respective plugin and starts streaming data into it. Any plugin that wants to be NPAPI compliant must implement and expose around 15 functions for initializing, creating and destroying plugin content. NPAPI was supported by every major browser until Google Chrome announced that it would phase out NPAPI support. Mozilla Firefox also reduced support for NPAPI after version 30 and Opera declared NPAPI deprecated from Opera browser 20 onward.

This standard is particularly relevant, when considering our work, because it gives a good example of the hazards that come when using browser plugins. In [1], a personal service was developed to replace their old NPAPI compliant plugin, which will soon stop working on Chrome browsers. Replacing plugins (or extensions) with personal services represents a fairly simple and elegant solution. Using personal services also enables the developers, for example, to merge a Web application with a Desktop application.

11

(43)

Chapter 3

State of the art

This chapter is divided in three sections. Section 3.1 will describe standards that are able to perform general object discovery and give particular focus to well-known directory services and elaborate naming services. These naming services could potentially be used (or adapted) to provide resource or service discovery.

Section 3.2 gives focus on more modern naming systems. These systems enable Web service discovery on the Internet.

Finally, Section 3.3 describes systems that allow the provision of services in local/do-mestic networks, either from entities also local to the network or external to it.

3.1 Object discovery

In this section we will differentiate attributed and non-attributed naming systems while giving focus to the first. These naming systems all perform object discovery. Objects can be users, files, resources, services or physical objects (e.g. printers, servers, etc). 3.1.1 Directory Services

A directory service is a centralized, network-based repository that stores and pro-vides access to information that must either be shared between applications or is highly distributed. The information should always be concise and strictly relevant to an entry. Directory services are similar to databases but contain more descriptive data and typically a directory service database is read more often than it is written.

A directory service look-up is an operation that targets a specific entry and in that entry targets a specific piece of information. One of the oldest directory service example is the telephone directory. The telephone directory service employs a simple data structure. The nodes are names and the entries are telephone numbers. A name translation in such a system is extremely simple. The user provides a name to the service and, if there is an entry node with that name, the respective telephone number will be returned. Other well known directory service standards are the DNS [30] and the X.500 Directory Service [34]. Most electronic directory services are accessed through implementations of the X.500 standard, which defines an open, vendor-neutral, industry standard network protocol and set of access methods to a directory. X.500 has become the standard access method for directory information, much as the DNS is used for IP address look-up on almost any system on an intranet and on the Internet.

DNS is a standard that, in essence, is the telephone directory system of the Internet. Just like any telephone user would register his number in a white-pages service, a IP

(44)

address is registered in a database and users obtain that address by using a name. Just like when one would look-up a white-pages service to translate a name into a telephone number, DNS translate names into IP addresses. To perform a look-up, DNS relies on a distributed system of name servers and a standardized language to query these servers. The overall naming structure of the Internet defines the largest DNS name space.

The Internet DNS name space consists of a tree structure of domain names, with a root domain at the top. The root name server plays a vital role, providing authoritative referrals to name servers for all top-level domains, which recursively determine referrals for all Internet host names, amongst other infrastructure information [4].

On the Internet, major domains are situated immediately below the root node. From these domains it branches into other domains, etc. Each name server is authoritative for a part of the naming tree. The fact that the DNS is structured in a tree means that it has a hierarchy. It is only because of this hierarchy structure that the DNS server could be deployed on a global scale. Although there are millions of DNS servers across the globe there is no need to replicate the world ”telephone list” in every single one of them. When a DNS server receives a name resolution request, if it is not capable of providing with an answer (incremental name resolution), it just needs to forward the request to the appropriate name server in the hierarchy.

According to Section 2.1, DNS would be classified as a white-pages service using a distributed model and a non-attributed structured naming convention (using a tree-like structure). Without giving any more focus to other design features, it is obvious that the DNS is not suited for our implementation. Following a distributed model is not even the deal-breaker because we could define a private name space (private networks are not included in the Internet name space) and use a single naming server as the sole naming authority. The DNS is, unfortunately, non-attributed and therefore it is not appropriate for our solution, which requires a rich description for the services. There is, however, another directory service that uses an attribute-based approach: the X.500 standard.

3.1.2 X.500

The X.500 Directory Service is a global directory service. It can manage information about countries, organizations, people or machines. It works as a white-pages service but also has the capability to look-up information by name and to browse and search for information, much like an yellow-pages service.

In X.500, the information is held in a Directory Information Base (DIB) and is ar-ranged in a tree structure called the directory information tree.

X.500 employs an attribute-based object description (Table 3.1). Each named object has a set of attributes and each attribute has a defined attribute type and one or more values. Much like the DNS, the X.500 name space is hierarchical. To find an object an unambiguously identifier, called distinguished name, is used. The distinguished name is a concatenation of different attributes, called relative distinguished name, found in the tree along the path leading from the root to the named entry.

The X.500 standard uses a tree-based, hierarchical structure, similar to the DNS. But unlike DNS, it uses a descriptive, structured attributed-based naming convention. Both X.500 and DNS provide incremental name resolution. The former is commonly based on the object geographical location and the latter is based on both the object geograph-ical location and its location and function in an organization. To find an object the requester needs to know his distinguished name. For instance, to find the FTP Server location (Table3.1) the user would need to request with the name (C=PT, L=Portugal,

Name service for accessing personal services from Web servers

Rafael

Figueiredo

Name service for accessing personal services from

Web servers

Servi¸

co de nomes para acesso de servidores Web a

Rafael

Figueiredo

Name service for accessing personal services from

Web servers

Servi¸

co de nomes para acesso de servidores Web a

servi¸

cos pessoais

Contents

List of Figures

List of Tables

Glossary

Chapter 1

Introduction

1.1

Motivation

1.2

Problem

1.3

Contribution

1.4

Organization

Chapter 2

Context

2.1

Name Server designs

2.2

HTTP Protocol

2.3

Domestic firewalls and NAT boxes

2.4

Web browsers

Chapter 3

State of the art

3.1

Object discovery