X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. It is a centrally managed distributed data exchange layer between information systems and provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties.
Image 1. X-Road components, roles and responsibilities.
X-Road is used nationwide in the Estonian public administration and in Finalnd’s Suomi.fi Data Exchange Layer service. X-Road is released under the MIT license and is available free of charge for any individual or organization. Nordic Institute for Interoperability Solutions (NIIS) is responsible for the development of the X-Road core and provides support and insights to the X-Road community.
X-Road implements a set of common features to support and facilitate data exchange. X-Road provides the following features out of the box:
- address management
- message routing
- access rights management
- organization level authentication
- machine level authentication
- transportation layer encryption
- time-stamping
- digital signature of messages
- logging
- error handling.
Trusted Network
The identity of each organization and technical entry point (Security Server) is verified using certificates that are issued by a trusted Certification Authority (CA) when an organization joins an X-Road ecosystem. The identities are maintained centrally, but all the data is exchanged directly between a consumer and provider. Message routing is based on organization and service level identifiers that are mapped to physical network locations of the services by X-Road. All the evidence regarding the data exchange is stored locally by the data exchange parties, and no third parties have access to the data. Time-stamping and digital signature together guarantee non-repudiation of the data sent via X-Road.
Image 2. X-Road architecture
An X-Road ecosystem is a community of organizations using the same instance of the X-Road software for producing and consuming services. The owner of the ecosystem, the governing authority, controls who’s allowed to join the community, and the owner defines regulations and practices that the ecosystem must follow. The ecosystem may be nationwide, like in Estonia and Finland, or it may be limited to organizations matching certain criteria, e.g. clients of a commercial service provider. Technically, the X-Road software does not set any limitations to the size of the ecosystem or to the member organizations.
Two X-Road ecosystems can be joined together, federated. Federation is a one to one relationship between two ecosystems. Members of the federated ecosystems can publish and consume services with each other as if they were members of the same ecosystem. For example, Finland’s and Estonia’s data exchange layers are connected to one another which enables cross-border data exchange between the countries. Federation provides members of the federated ecosystems a single access point to both local and cross-border data sources. However, it must be noted that federation is not only about technology as both legal and administrative agreements are needed between the X-Road operators and member organizations that exchange data.
Image 3. X-Road federation – connection between two X-Road ecosystems.
Producing and Consuming Services
The use of X-Road requires that all the message exchange parties are members of an X-Road ecosystem and they have access to an X-Road entry point, Security Server, which is required for both producing and consuming services. The Security Server mediates service calls and service responses between information systems, and it encapsulates the security aspects of the X-Road infrastructure: managing keys for signing and authentication, sending messages over secure channel, creating the proof value for messages with digital signatures, time-stamping and logging.
X-Road logs contain all the messages processed by the Security Server. Each message is time-stamped and signed which makes it possible to verify the message content afterwards. By default, the logs are stored locally by the Security Server — external parties do not have access to them.
Both data using services and data sources are identified using X-Road’s globally unique identifiers. The identifiers contain information about the X-Road ecosystem, member organization and information system that is consuming or producing data via X-Road. The identifiers are used internally by X-Road for routing messages between data using services and data sources. A data using service does not need to know the network address of a data source — X-Road automatically maps the service identifier to the correct network address.
Own Your Data
Built-in features provided by X-Road can also be used for managing access rights to data sources. Access rights management is based on the X-Road service identifiers. The key idea of X-Road is that each service provider owns its data and is responsible for managing access rights of its services. In other words, publishing a service to X-Road does not mean that the service is automatically accessible to all X-Road member organizations. Usually, access rights are granted on information system level — a service provider grants a specific information system access to a service. This approach provides a tight control, but it may also generate much administrative work if the number of service consumers is changing frequently.
X-Road is an open source technology, and anyone has access to it for free of charge. An X-Road ecosystem is managed by a governing authority that controls who is allowed to join the ecosystem. In Estonia and Finland the ecosystems are open for all kind of organizations (public, private, non-profit etc.) and joining them is free. Joining an X-Road ecosystem does not require an organization specific Security Server as a Security Server can be shared between multiple organizations or provided as a service by a third party, e.g. a commercial service provider. The process that is required to join an ecosystem is more time consuming compared to implementing a direct point-to-point integration, but it is necessary for creating trust between the members of the ecosystem. In addition, the process is required only when a new organization joins the ecosystem or a new Security Server is registered.
Image 4. X-Road compared to point-to-point integrations.
X-Road Development
NIIS is responsible for developing X-Road core technology, and welcomes everyone to submit source code contributions, new ideas and enhancement requests regarding X-Road. The backlog is public — anyone can access it, leave comments and submit enhancement requests through the X-Road Service Desk portal. Accessing the backlog and service desk requires creating an account which can be done in few seconds using the signup form.