Text size

Spacing

Contrast
Settings

 

Introduction to X-Road (part 3)

Anto Veldre, Analyst (State Information System Authority)

Previous parts

Making use of X-Road

I'm only asking

A consumer (or client) user of the X-Road is limited to making requests via the X-Road. Generally requests will not be initiated manually. Instead, a relevant request-making functionality is programmed into the IS of particular institution/company. The request must adhere to X-Road Messaging Protocol (there are several versions available) and will then be pushed into the security server on the initiator side. After being encrypted and formatted, the message moves on through the magical X-Road pipeline until it lands in the target institution's security server.

The cryptic name “OSI Level 7 Application Gateway” obscures the complexity of the X-Road’s pipelines. The IS of the requesting user will send a POST request against his own Connectivity Server, e.g. http://myconnectivityserver/CatsData.Estonian-Xroad/FindTheCatOwnerByCatsMicroChipNumber?123456. Once the POST request has been sent and answered, the answer to the user’s request appears, as if magically. In the case of the organization seeking to process stray cats, for example, the “request” initiated when the cat’s chip is queried is responded to with the personally identifying information of the pet owner. Accomplishing the same task without the X-Road would require a bunch of usernames and passwords, the relevant servers' IP addresses, and knowledge about how to effectively use SQL (Structured Query Language). As a result of the X-Road, users can initiate requests without needing to know how to reach the registers, or even how to produce valid SQL sentences.

Both the initiator and the target of the request have their own numeric identity. This numeric identity could, in the simplest instances, just be their identity in the Business Register. It is relatively easy to save both parties’ numbers in a request log. This logging makes it possible to prove at a later date who has made what requests of which databases. When operating databases that require high security, data providers can impose extra requirements for access. For example, they can require the personal ID number of the person behind the request, or require eID to finalize a request.

Even if your organization is technologically compatible with the X-Road, if it does not have an agreement with the data owner from whose database you are requesting data, your request’s outcome is very simple: your request will not be honored because you do not have sufficient access rights.

Providing answers to consumers

In contrast to consumers, who make requests via the X-Road, data providers use the X-Road to answer requests and share data. Data providers must meet two extra requirements to use the X-Road.

  • First, data providers must have a Register (database) to grant the access to. This Register must have been registered with RIA. Through the registration process it is possible to limit who has access to the database.
  • Second, data providers must have an Adapter Server, commonly known as “integration components.”

Adapter servers are not standardized. Each set of integration components will solve a given task a little bit differently. The important functions of the adapter server are: parsing the requests that arrive via the X-Road, translating these into a language understood by the local database—the X-Road does not circumscribe organization’s ability to use whatever database platform they please—and directing answers back to X-Road pipeline. Data providers can procure these adapter servers from whatever software company they prefer.

Adapter servers also check arriving requests against the requested WSDL file, so continuing with our stray cats example, the adapter server may check the request against the “FindTheOwnerByChipNumber.wdsl” file. The adapter server will only forward the request to the database if the request is grammatically correct and if the originator the request is on the access control list. Adapter servers also forward the answers back across the X-Road to the request initiators.

A data provider’s adapter server must be registered with the X-Road centre and with RIHA. If the adapter server is not registered then the X-Road centre cannot advertise its services back to potential consumers. RIHA registration also facilitates convenience since it allows all WDSL files to be centrally published, and by extension, public, described and understood.

A short note to hackers:  you cannot use an adapter server to access the X-Road from your home because you have neither data to share nor clients.

MISP

Another feature of the X-Road is MISP (mini-information-service-portal), a standard web portal to enable trivial requests that conform to prescribed parameters. The MISP makes it possible for users to access the X-Road via a normal internet browser. It does this by translating WDSL files directly into webpages.

MISP screenshot

MISP screenshot

MISP is intended for small and low budgeted institutions that are legally required to publish data of some kind. MISP makes X-Road participation more convenient for these organizations, which might otherwise be thwarted by the complexity of X-Road participation.

Even organizations using MISP must have a security server. Several private companies provide joint MISP  + Security Server solutions to smaller municipalities. A tiny municipality will save a lot of money by not building its own server room.

MISP is only accessible to those who have logged in using two-factor eID. Further, for security reasons, MISP cannot be used to execute complex requests or access especially confidential information.

Ancillary Information about the X-Road

It is impossible to counterfeit requests and data on the X-Road

As noted above, every interaction that occurs via the X-Road is logged. Requests are always logged. This constant logging facilitates one of the X-Road’s most important design goals: data integrity. Only authorized persons should be able to access, modify and erase data via the X-Road.

All of this sounds good in theory, but how are these security requirements ensured in real life? First, the X-Road Centre collects statistics about X-Road usage from the security servers. This enables it to know what requests were made of data service providers. Sometimes a single request will be flagged as anomalous and the Centre can then ask the initiator to clarify its grounds for making the request.

Additionally, each security server has a security log reflecting every request it has ever made.

There are several options to ensure the continued integrity of the logs. One of these is chaining, which means making latter logs cryptographically dependent on those that precede them. Chaining makes it impossible to fabricate events.

It is also possible to digitally sign and timestamp requests made in a given time period (day, month, year). This makes it possible to later determine with a high level of certainty whether a request was ever made or not. In other words, requests are non-repudiable. This means, no one can deny they occurred or change the details recorded about them. For these reasons, starting with X-Road version 6, Secure Signature-Creation Devices (SSCD's) are used by all X-Road participants. These devices enable fast and secure digital timestamping.

One of the main principles of the e-State is that no one should be able to forge records. Security logs are central to ensuring this data goal. Regulations and procedures that make the professional and legal costs of attempting to forge records very high are another important tool for protecting data integrity.

About Duplicates: the dog named “Cat”

When the X-Road was born, it existed in only one place (the RIA-controlled X-Road Centre). In other words, it was impossible to differentiate between the abstract idea of “X-Road technology” and the applied “X-Road System”: these seemed to be one and the same. But then, private companies and neighbouring states took notice of this very useful technology and wanted to install X-Road technology for their own internal use.

This replication of the X-Road technology caused a problem. When two X-Roads communicate with each other, things can get messy. Imagine that you have two dogs in your house, both of whom are named “Cat.” In this case, when you holler for “Cat,” it is not clear which of the dogs are you calling. To solve this problem, the “instance name” attribute was added to the X-Road technology.

In the future, when the X-Roads in Estonia and Finland wish to communicate with one another, they could have the instance names “XTEE.EE” and “PALVELUVÄYLÄ.FI” respectively. Similarly, the X-Roads of private companies could theoretically communicate with one another via instances’ names like XROAD.SIEMENS or XROAD.PHILIPS.

A superstructure joining several X-Roads is called a federation. A federation enables data exchange between the clients of different governments. A multi-instance federation has not yet been launched, so we don't know who would govern it or how it would be managed. Perhaps Estonia’s RIA, or alternatively, the EU might take key roles.

About Data Exchange

And now, some light-hearted commentary about the terminology surrounding the X-Road.

The official X-Road documentation often mentions “Data Exchange.” This phrase has a specialized meaning within the context of the X-Road.

When a policeman stops a car and makes an inquiry about it and its driver via the computer in his patrol vehicle, that request is transmitted via the X-Road.

Specifically, the policeman produced a request which was transmitted as bits of data via the X-Road and a little bit later the answer arrives back to his patrol car computer, also via the X-Road. This set of interactions is a “data exchange.”

In the context of the X-Road the phrase “data exchange” should be interpreted narrowly. Registers do not “swap” data with one another; the data itself is not updated or modified. The word “exchange” here simply denotes that data is transmitted in both directions—the request data is sent from the initiator to the data provider and the response is sent back.

On the directionality of the data service

The directionality of data service is important. There are usage scenarios in which a customer simply asks for some pre-existing data. However, there are other usage scenarios in which the customer seeks to update data. For example, when a person is born, a whole new record is created. Similarly, when someone moves, the address field associated with them is updated etc.

Alternative notion of X-Road

This is an alternative notion of the X-Road

Conclusion

Below are a few short quizzes to help you test your knowledge about the technical aspects of the X-Road.

Quiz 1

The following advertising slogan is displayed on the website of AS Cybernetica to promote the X-Road:

Partial screenshot from www.cyber.ee

Partial screenshot from www.cyber.ee

The questions:

  1. In what ways is the X-Road the backbone of Estonian State?
  2. What are the X-Road’s information security features?
  3. What does it mean that the X-Road is “distributed”? What was the role of the late Imre Perli in highlighting why the X-Road should be distributed?
  4. Please explain your understanding of a “service bus” mentioned on the screenshot. What is transported by the service bus?
  5. What organizations and individuals exchange data via the X-Road? Please give at least one practical example.
  6. Why has such a complex system been created to exchange data? Why can’t data be “exchanged” itself without the involvement of specialized technologies?

Answers to Quiz 1

  1. The X-Road is the backbone of the Estonian State because the absolute majority of registers and databases kept by the Estonian State, are made available via X-Road. Without X-Road, if the State wanted to store and exchange its data it would have to build a Central SuperDatabase or establish a horse sleigh company to move data storage devices between municipalities and agencies across Estonia.
  2. There are three core tenants of the information security: data availability, integrity and confidentiality. Provided the X-road is functioning properly data availability is taken care of. The X-Road’s security features exist to promote data integrity—via the frequent creation of non-reputable log records—and data confidentiality—by limiting data access to those authorized people working within organizations authorized to access that particular set of data.
  3. The X-Road’s distributed architecture was designed: 1) to avoid the risks inherent in a central superdatabase; and 2) to avoid the seemingly unbearable price of central IT solutions of 90-s. Imre Perli was a hacker whose data theft highlighted the risks inherent in having centralized databases.
  4. This is data that moves back and forth via the data exchange bus.
  5. Data Exchange is a crucial term. When customer makes a request and gets an answer, then bits move around the data bus in both directions – an interaction has been made. The data involve may or may not be modified in the exchange.
  6. Data availability, integrity and confidentiality is s only possible when protocols and rules are strictly defined and followed.

Quiz 2

Read the following sentence (from a manual)

“The data exchange layer for Estonian state information systems, X-Road, is a technological and organizational environment enabling a secure Internet-based data exchange between X-Road members”,

and try to answer these questions:

  1. What does “State Information System” mean?
  2. What does the phrase “Data Exchange Layer for the State” refer to?
  3. What does the phrase “Technological environment [of X-Road]” mean?
  4. What does the phrase “Organizational environment [of X-Road]” mean?
  5. What type of data do state databases exchange with one another?
  6. Who are X-Road members and how does one become an X-Road member?

Answers to Quiz 2

  1. The state information system includes: databases, client programs that officials use to access data, e-mail programs, network connections and web servers.
  2. When the X-Road began it was only accessible by public sector entities. However, it soon became clear that including private companies in the X-Road would yield great efficiency and convenience.
  3. The X-Road’s technological environment includes servers, computer programs, internet connectivity etc. Pure IT, nothing more!
  4. The X-Road’s organizational environment includes rules and procedures, for example those governing how the X-Road is managed and who is responsible for what aspects of its maintenance.
  5. During an interaction, a human and a database exchange bits of information. A “Data Exchange” is everything that happens during this interaction cycle.
  6. Basically anyone can become an X-Road member (even a private enterpreneur) provided the membership application was approved by RIA (Estonia’s State Information System Authority). However, entities get X-Road membership not for fun, but because they have an institutional need exchange data faster, more conveniently, and with lower overhead.

Did you get the answer to your question?

Added 08.02.2016
Updated 09.02.2016

Back to page "Introduction of X-Road"