Get Some More REST

Over the last year and a half I’ve written multiple blog posts about X-Road and REST. Those blog posts have covered implementation plans, technical design details and release of the first X-Road version with REST support – the version 6.21.0 that was released in April 2019. All in all, the blog posts have covered the whole REST support journey from design to implementation and release. Currently we’re putting the finishing touches on the second stage of the REST support implementation which provides even more built-in REST-related features. The results are included in the version 6.22.0 that will be released in October 2019.

And for the readers interested in the technical details on source code level, the code implementing the REST support is available in the develop branch of the X-Road master repository on GitHub.

For clarity, adding support for REST does not mean dropping support for SOAP. No changes are required to information systems consuming and producing SOAP services via X-Road. Instead, the two architectural styles can co-exist side by side which means that all the current SOAP services are supported in the future too.

Basic Support for REST

The version 6.21.0 already provided a basic support for consuming and producing REST services:

• Basic REST functionality

  • Message exchange with signing and time-stamping

  • Message logging with archiving

  • Downloading and verification of log records

• Adding a REST service using an URL

• Operational monitoring of REST services

• Service-level authorization

• Certificate based authentication (clients + services) 

The version 6.22.0 will provide all the REST related features included in the previous version plus a set of whole new features. Let’s find out what they are!

Metaservices for REST

Metaservices are built-in Security Server services that can be used by X-Road member organisations to discover what services provided by other members are available and download the service descriptions of these services. Until now the metaservices have been available over SOAP only, but starting from the version 6.22.0 the metaservices are available over REST too. The responses of the REST metaservices are always returned in JSON as the Security Server does not currently support other content types in the responses.

In the version 6.21.0 the SOAP versions of the metaservices return information about available SOAP and REST services. This is somewhat confusing as a SOAP client is not very likely to be interested in receiving information about REST services, and vice versa. Therefore, in the version 6.22.0 the functionality has been changed so that the SOAP versions contain information about the available SOAP services only and similarly, the REST versions contain information about the available REST services only. This means that in case information about all the available SOAP and REST services needs to be collected, both SOAP and REST versions of the metaservices must be invoked.

More detailed information about the metaservices can be found in the Service Metadata Protocol for SOAP and the Service Metadata Protocol for REST.

Support for OpenAPI 3 Descriptions

Existing REST services can be published in X-Road as-is – just like in the version 6.21.0. Unlike with SOAP services, the Security Server does not require X-Road specific information to be present in the responses returned by REST services. Certain X-Road-specific information is still included in the response message returned to a client information system, but the Security Server takes care of adding the required information to response message’s HTTP headers.

In the version 6.21.0 publishing a REST API is done by defining the base URL of a REST API and a service code. This is still possible in the version 6.22.0, but in addition it is possible to publish a REST API using the OpenAPI 3 Specification. When a new REST API is published it is possible to choose whether it is done using the base URL of the API or the URL of an OpenAPI 3 description of the API. The description can be provided in both JSON and YAML formats. This means that providing an OpenAPI 3 description is supported, but not mandatory. All REST APIs added using the version 6.21.0 will continue to work without any changes in the configuration.

Image 1. Adding a REST API in the version 6.22.0.

The first benefit of providing OpenAPI 3 description is that other X-Road members can query the OpenAPI description using the new getOpenAPI metaservice – just like it is possible to query WSDL descriptions of SOAP services using the getWsdl metaservice. Another benefit of publishing an OpenAPI 3 description is that the Security Server reads all the API endpoints defined in the description and they become visible in the Security Server UI. The endpoints can then be used in access rights management – more about that later.

Image 2. List endpoints of a REST API.

In addition, it’s also possible to add endpoints manually. However, manually created endpoints are not visible to other X-Road members through the getOpenAPI metaservice, but they can be used in access rights management just like the endpoints read from an OpenAPI description. Manually created endpoints can be updated and deleted by Security Server administrators. Instead, endpoints read from an OpenAPI description cannot be manually updated or deleted. They can be updated and/or deleted by updating the OpenAPI 3 description and then refreshing it on the Security Server. The same logic applies updating SOAP services through WSDL descriptions.

Image 3. Adding an endpoint manually.

Besides access rights management, the Security Server does not use the endpoint-related information for anything else, e.g. the Security Server does not validate if an endpoint defined in a request by a client information system exists under an API or not. In other words, if a client information system has sufficient access rights to invoke an API endpoint, the Security Server forwards the request to the specified endpoint without any further validations.

More Fine-Grained Authorisation

In the version 6.21.0 REST APIs are authorized on the API level. In practice, this means that access rights are defined for all endpoints of an API. Sometimes this is OK, but other times it might be needed to define access rights on more fine-grained level, e.g. access to a specific endpoint only or only read access, but no permissions to add or modify data. The use of endpoints makes it possible to define access rights on more fine-grained level.

Starting from the version 6.22.0 it’s possible to define access for REST APIs on two levels: REST API level and endpoint level. In general, a REST API usually has multiple endpoints. When access rights are defined on the API level, they apply to all the endpoints of the API. Instead, defining access rights on the endpoint level enables more fine-grained access rights managements as access rights are defined using HTTP request method and path combination. Therefore, it is possible to define access rights for a single endpoint or alternatively for a subset of endpoints using wildcards.

When a client application has access rights on the API level, it means that the client can access all the endpoints of the API. In case clients must not have access to all the endpoints, then access rights must be defined on the endpoint level. Security Server’s access rights management only supports allowing access – explicitly denying access is not supported, e.g. allow access to all endpoints on API level and then deny access to a single endpoint is not supported.

What’s Next?

The version 6.22.0-beta is already out and the official release version 6.22.0 will be released in October 2019. However, the beta version already provides all the REST-related features included in the final release. The last weeks are reserved for fine tuning and testing.

The REST support implementation has been done in phases which means that REST-related features have been added along several X-Road versions – every new version adding something new. However, the version 6.23.0 does not have any planned new REST-related features yet, but it’ll likely contain smaller improvements to existing features, e.g. performance optimisations. In addition, we hope to receive feedback and enhancement requests from you regarding the existing REST functionality. Improvements and new features may be added to the roadmap based on the received feedback.

In case you have not checked out the X-Road REST support yet, it’s time to do it now!

X-Road and eDelivery – Identical Twins or Distant Relatives?

Building a digital society and digitizing public services both nationally and across borders are hot topics in Europe right now. Standardised and secure data exchange is one of the key enablers that is required to be in place for succeeding in the task. The good news is that there are already solutions and building blocks available that can be used for the job. Instead of reinventing the wheel and building everything from scratch it is possible to use off-the-shelf, battle-proven solutions that have already been successfully used in multiple implementations.

It goes without saying that X-Road is one of the available solutions. Another solution that is often mentioned in the same context is eDelivery – a building block of the Connecting Europe Facility (CEF). X-Road and eDelivery are both data exchange solutions that have been successfully used in multiple implementations in several countries and / or projects. Technically, they are both based on distributed architecture and they are enablers of decentralized data management. At first glance they may seem very similar, even competitors to each other. But is that really the case? Let’s find out.

Architecture

On architectural level eDelivery and X-Road have many characteristics in common as they are both based on four-corner model. The basic idea of the model is that information systems do not exchange data directly with each other. Instead, information systems are connected through additional access points that implement the same technical specifications and therefore are able to communicate with each other. In addition, access points usually provide common features required in data exchange, e.g. message routing, security, logging, authentication etc. Both X-Road and eDelivery also have an address registry and tools for capability lookups that are used in message routing and service discovery.

Image 1. Four-corner model explained through X-Road architecture.

The similarities do not finish there. In both X-Road and eDelivery the trust model is based on digital certificates, and they both guarantee non-repudiation of messages and identities of message exchange parties using digital signatures. In addition, in both cases the message transport protocol used between the access points is based on MIME/multipart messages even if the structure of the messages is not the same. X-Road and eDelivery can be used to exchange both data and documents. In addition, they are both payload agnostic which means that they can be used for transferring any kind of data (structured, non-structured and/or binary), e.g. purchase order, invoice, JSON, XML, PDF etc.

Cross-Border and Cross-Sector Data Exchange

Technically eDelivery supports both cross-border and cross-sector data exchange. However, eDelivery is typically implemented within a policy domain and different policy domains have their own implementations with domain specific operations and management models. In practice, each policy domain creates its own eDelivery subdomain, and all the eDelivery components that belong to the same subdomain trust each other. Usually, a component / participant from one subdomain, e.g. eHealth, is not considered trusted in another subdomain, e.g. eJustice. This means that there are multiple eDelivery subdomains and it might not be possible to exchange data between them.

X-Road's main idea is that it enables data exchange between organisations from different sectors (public, private, non-profit etc.) and different policy domains. X-Road is typically deployed on a national level so that it provides a nationwide data exchange layer for all kinds of organisations across sector and policy domain boundaries. Two X-Road environments can be joined together, federated, which enables cross-border data exchange between the member organisations of the two ecosystems. Federation means that members of two different X-Road ecosystems can exchange data as if they were members of the same ecosystem.

Trust Models

Both X-Road’s and eDelivery’s trust models are based on digital certificates. X-Road and eDelivery both use certificates to secure the communication between access points (TLS encryption), and sign the data and documents that are transferred. In addition, eDelivery also supports encrypting and decrypting the data and documents. In addition, how certificates are managed, configured and distributed differs between the systems.

eDelivery supports multiple trust models and the model that is used can vary between different eDelivery subdomains. Depending on the selected trust model the distribution of the digital certificates may be manual, automatic or something in between.

X-Road supports the use of multiple trust service providers within an ecosystem and the distribution of certificates is always handled automatically by X-Road. Two organisations may use certificates issued by different trust service providers, but this is fully transparent to the user organisations as the exchange and verification of certificates is automated. In X-Road's context, organisations and access points of the same ecosystem always trust each other. The trust can be expanded to cover other ecosystems using federation.

Messaging Models

One of the main technical differences between eDelivery and X-Road is related to supported messaging models. X-Road is based on synchronous communication that is well suited for real time data and document exchange. Instead, eDelivery is based on asynchronous communication that is well suited for reliable, non-time-critical document and data exchange. eDelivery also supports duplicate message detection and message retry / resending scenarios.

The difference between synchronous and asynchronous communication is that in synchronous communication a service consumer sends a request and stays on waiting for a response, but in asynchronous communication a service consumer sends a request and continues processing with other tasks. In synchronous communication the service consumer’s control flow is disrupted until the service provider has processed the service consumer’s request. Instead, in asynchronous communication the service provider sends a response later once it has processed the request.

Connecting Information Systems

Connecting an information system to eDelivery means that the information system must implement the eDelivery AS4 Profile so that communication between an eDelivery access point and an information system is technically possible. This means that an additional adapter or connector is usually required between an access point and an information system. The adapter/connector acts as a converter between the eDelivery AS4 Profile and the information system’s native format. Exchanging all kind of data is supported, but the data must always be wrapped inside a message that conforms the eDelivery AS4 Profile.

X-Road supports two alternative messaging protocols that can be used in the data exchange – a message protocol for SOAP and a message protocol for REST. When the SOAP protocol is used, an additional adapter or connector is usually required, because the data to be transferred must be wrapped inside a message that conforms the X-Road message protocol for SOAP. Instead, when the REST protocol is used, no additional adapter or converter component is required as existing REST services can be published and consumed as-is.

Operations and Management Model

eDelivery prescribes technical specifications that can be used to enable secure and reliable exchange of documents and data, and the specifications are based on standards. There are multiple software, both commercial and open source, available that implement the eDelivery specifications. Organisations are free to choose which software they use when exchanging data using eDelivery. eDelivery is managed through the specifications – once they change, vendors of the implementations update their products accordingly. Operations and management model is policy domain specific – each domain defines its own model and models between different domains may vary.

X-Road is a technical and organizational framework that provides secure and standardised way to exchange data between data providers and consumers over the Internet. Multiple standards are used in X-Road's implementation, but no X-Road specific parts have been standardised. However, X-Road’s source code and all X-Road protocols are open, and documentation is publicly available so anyone is free to create an implementation of X-Road protocol stack. Organisations that want to exchange data over X-Road must install X-Road software's Security Server component. X-Road and its protocol stack are managed as a software product – the protocol stack is managed and developed as a part of the X-Road software product. In addition, X-Road defines an organizational framework that describes the roles and responsibilities of different actors of an X-Road ecosystem.

Conclusions

On high level it may seem that eDelivery and X-Road are very similar, but more detailed review reveals that there are many significant differences between them. Even if they provide many same features and they have many common components on logical level, the implementation details vary greatly.

One of the key differences between eDelivery and X-Road is that eDelivery is a set of technical specifications with multiple implementations, and X-Road is a technical and organizational framework. In other words, eDelivery and X-Road are conceptually two different things. eDelivery is also missing a detailed organizational framework that defines the roles and responsibilities regarding the operations and management of an eDelivery policy domain.

Another important difference is related to the supported messaging models – asynchronous and synchronous communication. Both messaging models have their pros and cons, and it depends on the use case which one is a better a fit. Choosing a wrong messaging model may result in additional complexity which requires more implementation and maintenance effort.

All in all, eDelivery and X-Road are not identical twins and they should not be considered competitors either. X-Road is well suited for synchronous real-time data and document exchange, whereas eDelivery is a good fit for reliable, non-time-critical document and data exchange. Therefore, eDelivery and X-Road are not mutually exclusive, and they can be used side by side to fulfill different kind of data exchange needs. In the future it might be even possible to exchange data between eDelivery and X-Road. NIIS is currently studying alternatives for implementing a gateway between eDelivery and X-Road that would enable data exchange between eDelivery and X-Road ecosystems. A technical proof-of-concept level implementation has already been completed, but there are legal and administrative questions yet to be resolved. However, that’s another story.

Netflix of Public Services

Everyone knows Netflix, the online streaming service where users can watch films, documentaries and TV series online 24/7. Netflix has over 100 million subscribers globally, and they all expect the service to work flawlessly and provide first-class user experience and content each and every time. To be able to meet users’ expectations the service must be resistant to failure and it must adapt to changing demand quickly and automatically. Technically, this is a huge challenge to any information system – especially when we’re talking about over 100 million users.

Of course, the most important thing to the users is high-quality content. World class technical solutions and architecture mean nothing if a service does not provide interesting and meaningful content to its users. When it comes to delivering the content to the users, technical solutions and architecture are key enablers, and without those it is not possible to get access to it or the user experience is poor. Great technical solutions are transparent to their users – the users don’t even know that they’re there.

Netflix has been able to meet the expectations well. At the same time they’ve managed to keep the underlying architecture fully transparent to users – as it should be. Netflix has built the underlying system so that it is highly available, fault tolerant, resilient and scalable. One of the key factors in their success lies in the architectural choices. Instead of building one monolithic system, Netflix has built its system around multiple loosely coupled services. This approach is called microservice architecture. Another key factor in Netflix’s technical success is the use of cloud services.

Size does matter

Microservice architecture pattern is one of the most commonly used architecture patterns in the recent years. It is based on the idea that a system is composed of multiple small, independently deployable and loosely coupled services that communicate with each other using language-agnostic APIs. Usually the services are organized around business capabilities. Each service can be developed and deployed independently of one another which simplifies the development and deployment of large, complex applications as each part of the application can be developed and deployed independently instead of deploying the whole application every time when a single component is updated.

Image 1. Microservice architecture.

On the other hand, microservice architecture also increases the complexity of a system. The complexity comes from multiple fine-grained services operating together seamlessly. A single business feature may span multiple microservices which requires an additional layer for coordination and orchestration, service discovery, error handling etc. Locating a malfunctioning component from such a system is not a trivial task. In addition, each service can be developed independently, but testing of a business feature requires that all the related services or their mock versions are available.

At this point you might be wondering what all this has to do with X-Road? Keep on reading, you will find it out soon.

What about X-Road?

X-Road is an open source data exchange layer solution that enables organizations to exchange information over the Internet. X-Road is a centrally managed distributed data exchange layer between information systems that provides a standardized and secure way to produce and consume services. X-Road ensures confidentiality, integrity and interoperability between data exchange parties. The data is always exchanged directly between a service consumer and a service provider, and no third parties have access to it.

X-Road is not based on microservice architecture, but the X-Road ecosystem shares many of the same characteristics – on a higher level, though. Instead of a single information system consisting of multiple small atomic services, X-Road is a data exchange layer between service consumers and business services provided by various information systems owned by different organisations. The services available via X-Road are independently deployable and loosely coupled, and they communicate with each other using language-agnostic APIs. Each service can be developed, deployed and scaled independently without affecting other services as long as the API remains unchanged. Sounds familiar?

However, X-Road is just a data exchange layer – an enabler for secure and standardized data exchange that is transparent to end-users. Just like microservice architecture is enabler for building scalable, fault-tolerant and highly-available systems. The real value comes from services that are built on top of the technical infrastructure and the content that they provide to users.

It’s all about content

X-Road enables citizens, entrepreneurs and officials to operate via different portals and applications (document management systems, institutional information systems) in a more efficient and flexible manner. For example, it helps to check for relevant information in various base registries or securely exchange documents between organisations.

X-Road is used nationwide in the Estonian data exchange layer X-tee and in the Suomi.fi Data Exchange Layer service in Finland. Both Estonia and Finland have their own state portals that provide users access to different public registers and services. In general, a state portal is a single point-of-entry to public services for citizens, entrepreneurs and officials. X-Road is used in the background to connect the portal to different information systems and registers maintained by various organizations. Instead of going through websites and portals of different authorities one by one, there’s one centralized place to search and access services.

Image 2. A state portal connected to various information systems and base registers via X-Road.

A state portal is a Netflix of public services. It is a centralized place that gives 24/7 access to public services provided by different authorities. It is a platform that citizens can use to communicate with different authorities, and search, access and update information. New services are added to the platform and old ones are removed. Also the platform itself is constantly developed based on the feedback received from users. X-Road is a transparent data exchange layer in the background that enables secure and standardized data exchange between the portal and various information systems and base registers. X-Road plays a key role in the architecture, but the most important thing is the actual content – what would be the value of Netflix without all films, documentaries, TV series etc.? The same goes with a state portal, it’s all about the available content and services.

Two Steps from X-Road REST Support

Over the last year I’ve written multiple blog posts about X-Road and REST. In those blog posts I have shared insights on our implementations plans, details about the technical design and status updates on the progress. In the last months we’ve concentrated on the technical implementation of the X-Road Message Protocol for REST and now we’ve arrived at a point when only the finishing touches are missing from completing the first stage of the REST support implementation. Therefore, in this blog post, I’m not going to write about plans, but the actual implementation instead. 

And for the readers interested in the technical details on source code level, the code implementing the REST support is now available in the develop branch of the X-Road master repository on GitHub. 

For clarity, adding support for REST does not mean dropping support for SOAP. No changes are required to information systems consuming and producing SOAP services via X-Road. Instead, the two architectural styles can co-exist side by side which means that all the current SOAP services are supported in the future too.

REST support implementation

For a recap, let’s start with defining what REST means in the context of X-Road. Unlike SOAP that is a protocol with a detailed specification, REST is an architectural style consisting of the best practices and guidelines. In X-Road’s case supporting REST means consuming and producing REST-style API’s via X-Road. A loose definition would be supporting any content type over HTTP.

One of the guiding principles in designing the X-Road Message Protocol for REST has been the ease of use for both service providers and service consumers. Therefore, consuming and producing REST-style services via X-Road is made possible without an additional adapter service component. X-Road-specific information required by Security Server (e.g. service client identifier, service provider identifier, message id etc.) is transferred and processed so that existing REST-style services and service consumers can be connected to X-Road with minimal changes or no changes at all. This has been achieved by transferring X-Road specific information required by Security Server in HTTP headers and URL parameters, outside of the message payload.

X-Road’s REST support is not limited to just JSON and XML messages as Security Server does not set any restrictions to the content type of the payload that is transferred between a service consumer and a service provider. The content type of the payload is defined using “Content-Type” HTTP header that is transferred between a service consumer and a service provider just like the payload itself. The payload is transferred as-is, Security Server does not modify, convert or validate the processed payload. The same goes with almost all the consumer and service provider defined HTTP headers and URL parameters – they are passed as-is between a service consumer and a service provider. The list of filtered HTTP headers is included in the X-Road Message Protocol for REST specification – all the other headers are passed as-is.

When it comes to non-repudiation of REST messages, message payload, URL parameters and HTTP headers are all included in the digital signature and logs generated and verified by Security Server. Hence, X-Road guarantees non-repudiation of REST request and response messages just like it does for SOAP messages. Currently it is possible to disable logging of SOAP message body and the same feature is available for REST services too. In that case REST message payload, URL parameters and consumer/provider defined HTTP headers are excluded from the message log.

Consuming REST services 

Consuming REST services via X-Road is simple – the service to be called is defined in the request URL and the X-Road client subsystem sending the request is defined in an HTTP header. Other X-Road specific information (e.g. user ID, issue, id) is optional and it is passed using HTTP headers. Other HTTP headers, path parameters and URL parameters are passed end-to-end as-is which means that from a service client’s perspective the only difference compared to a direct service call is the mandatory HTTP header defining the X-Road client subsystem.  

Providing REST services 

Producing REST services via X-Road is as simple (if not even simpler) as consuming services. Existing REST services can be published in X-Road as-is – it is enough to add the base URL of the REST API to be published and define access rights on the Security Server UI. Unlike with SOAP services, Security Server does not require X-Road specific information to be present in the responses returned by REST services. Certain X-Road-specific information is still included in the response message returned to a client information system, but Security Server takes care of adding the required information to response message’s HTTP headers. 

Service descriptions for REST 

Currently SOAP services must be described using WSDL descriptions. It is not possible to publish a SOAP service in X-Road without providing a WSDL description for the service.  

In the first X-Road version including REST support (v6.21.0) service descriptions for REST services are not required. When a new REST service is added, it is enough to provide the base URL of the REST API to be published. In later versions support for describing REST services using OpenAPI 3 specification will be added.  

How about automatic SOAP-REST conversions?

Services must be consumed using their native implementations – SOAP or REST. If a service provider wants to provide both SOAP and REST versions of the same service, the provider must implement both versions. In other words, Security Server will not provide automatic SOAP-REST conversion. In case automatic SOAP-REST conversion is needed, REST Adapter Service X-Road extension could be used. REST Adapter Service is an off-the-shelf component that provides an X-Road compatible REST-SOAP converter. The service supports a limited set of use cases. 

Machine-to-machine authentication 

The REST implementation supports mutual TLS authentication between a Security Server and a REST service consumer/provider. Support for JWT (JSON Web Token) based authentication between a Security Server and an information system may be provided in later versions. 

However, it is already possible to use JWT based authentication between a service client and a service provider. As described before, Security Server passes all HTTP headers between a service consumer and a service provider as-is, so there aren’t restrictions for implementing JWT based authentication on application level.

It’s time for beta! 

Soon it’s time to release the beta version of 6.21.0 that includes the long-awaited REST support. The official release version of 6.21.0 will be released at the end of April 2019. However, the beta version already provides all the REST-related features included in the final release. The last weeks are reserved for fine tuning and testing.

The version 6.21.0 will provide a basic support for consuming and producing REST services which includes:

• Basic REST functionality

  • Message exchange with signing and time-stamping

  • Message logging with archiving

  • Downloading and verification of log records

• Adding a REST service using an URL

  • No support for OpenAPI definitions

• Operational monitoring of REST services

• Service-level authorization

• Certificate based authentication (clients + services)

• X-Road Message Protocol for REST 1.0

That’s not all folks!

The REST support implementation will be done in phases which means that REST related features will be added along several X-Road versions – every new version adding something new. The next versions 6.22.0 and 6.23.0 will add more REST-related features later.

X-Road 6.22 (full support)

• Minor fixes and enhancements based on user feedback

• Metaservices for REST (listClients + listMethods)

• Support for OpenAPI

  • Add APIs using OpenAPI specification

  • Meta-service for querying services' OpenAPI definitions (getOpenAPIDefinition)

• Potential improvements

  • Path and method level authorization

  • JWT-based authentication (clients + services)

X-Road 6.23 or later (advanced support)

• Support for URI rewriting by Security Server

• Other API-Gatewayish features based on user feedback

X-Road Core Development in 2019

The new year 2019 has kicked off a few weeks ago, and X-Road core development keeps on rolling. Even if there haven’t been many updates regarding the X-Road core development lately, it doesn’t mean that NIIS has been resting on its laurels. Instead, we have been working on the version 6.20.0 and features for the other upcoming versions. We have also published the high-level X-Road development roadmap for 2019 so that everyone can see what kind of new features are coming out and when. The roadmap is available on the X-Road website.

The version 6.20.0 will be released on 25th January and it is the first of the three releases to be published in 2019. The official v6.20.0 release notes will be published in the X-Road Knowledge Base on the date of the release. The biggest change in the version 6.20.0 is support for Ubuntu 18.04 LTS operating system. The improvement is important, because the currently supported Ubuntu 14.04 LTS will quit receiving maintenance updates in Q2/2019 which is why migration is required. In addition, there’s a number of other improvements and fixes included in v6.20.0.

REST support

One of the most important features in 2019 is the long-awaited, native REST support. NIIS has been working on the X-Road REST support since spring 2018. Since then we have organized workshops and surveys for collecting input and feedback from X-Road users on the required features. We’re currently working on the implementation using all the comments and feedback as an input.

The implementation will be done in phases which means that REST related features will be added along several X-Road versions – every new version adding something new. The first version to support REST is v6.21.0, and it will be released in April 2019. Versions 6.22.0 and 6.23.0 will add more REST related features later.

X-Road 6.21 (basic support)

• Basic REST functionality

  • Message exchange with signing

  • Message logging

• Adding a REST service using an URL

  • OpenAPI definition not required

• Service-level authorization

• Certificate based authentication (clients + services)

• Metaservices for REST (listClients + listMethods)

• X-Road Message Protocol for REST 1.0

X-Road 6.22 (full support)

• Minor fixes and enhancements based on user feedback

• Path and method level authorization

• Support for OpenAPI

  • Possible to add a service using OpenAPI specification

  • Meta-service for querying services' OpenAPI definitions (getOpenAPIDefinition)

  • OpenAPI definition required

• JWT based authentication (clients + services)

X-Road 6.23 or later (advanced support)

• Support for URI rewriting by Security Server

• Other API-Gatewayish features based on user feedback

Right now, the version 0.3.0 of the Message Protocol for REST is out for comments – it is possible to leave comments until 28th January. All the feedback will be reviewed, and the protocol will be further developed based on the received input. NIIS welcomes everyone to comment the protocol draft!

API Based UI

Another major change taking place in 2019 is a new UI for both Security Server and Central Server. The new UI is not just a facelift – the UI will be redesigned and implemented from scratch. The aim of the change is to improve the usability and user experience of X-Road. Therefore, X-Road users will be closely involved in the design and implementation process so that their voice will be heard.

Together with the new UI, an administrative REST API will be implemented. The new UI will be using the API, but the API can be used for automating maintenance and configuration tasks too. The API will provide Security Server and Central Server administrators with the opportunity to automate maintenance and configuration tasks that currently require manual work.

According to the current schedule the new UI and the administrative API will be included in the version 6.22.0 that will be released in autumn 2019.

Streamlined onboarding process

Onboarding process of new X-Road members is one of the focus areas in X-Road core development this year. The aim is to streamline the onboarding process and reduce the number of steps that require manual work in the process. In practice this means enabling automatic approval of registration requests which speeds up the registration process and reduces the daily management tasks of the X-Road operator.

X-Road 7

The development of the core components of X-Road version 6 continues actively throughout the year 2019. At the same time NIIS is already looking ahead and the preparations for X-Road version 7 are already kicked off. Research and planning phase will be completed in 2019 so that the implementation can begin in 2020. Research and design are based on user-centered approach, and users are involved through the whole design and research process. Input, feedback and ideas are collected through interviews, workshops, events and surveys. In addition, one part of the research and planning phase is academic research in selected areas through collaboration with Estonian and Finnish universities.

And there is more!

This writing covers only the most important changes to be implemented in 2019. In addition, many smaller changes will be included in every release. It seems that we have a busy year ahead of us. If you’re interested in more detailed information about the upcoming changes, please visit the X-Road backlog. Anyone can access the backlog, and 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.

Functional changes and new features implemented this year change the X-Road technology stack too. X-Road Tech Radar provides up-to-date information on different technologies used in X-Road.

Stay tuned!