Sharing a subsystem between several organisations
This article shows an example of an implementation needed for sharing a subsystem between several organisations.
Subsystems are usually organisation-specific and can be used to identify organisations in the Data Exchange Layer. In a situation where several organisations use the same subsystem, it is not possible to identify the organisation based on the subsystem alone.
Considerations before deploying a shared subsystem
Service provider;
• Find out if your service can allow the use of a shared subsystem (issues to be solved, e.g. the implementation of authentication)
• Make sure that the terms of use of your service consider, if necessary, the shared subsystem and the related information security requirements and responsibilities
Intermediary;
• Determine whether the service you are deploying allows the use of a shared subsystem
• Familiarise yourself with the authentication method used in the service
• Agree on policies with the service provider
Please note! Before introducing a shared subsystem, you must ensure that the service utilised through the Data Exchange Layer supports the shared subsystem.
Depending on the service to be utilised, the implementation may differ from the example below and have different aspects to consider. You can find out whether the service can be used with a shared subsystem by contacting the organisation providing the service.
What is a shared subsystem?
A shared subsystem allows multiple organisations to join the Data Exchange Layer through a ready-made Security Server and subsystem owned by an intermediary. Sharing a subsystem between several organisations has been made possible so that, for example, each municipality or wellbeing services county does not need to create its own Security Server and subsystem when they join the Data Exchange Layer This means that joining the Data Exchange Layer will be easier, faster and simpler.
The intermediary represents organisations using the shared subsystem in the Data Exchange Layer.
- Applying for and managing Data Exchange Layer certificates is carried out by the organisation that owns the security server, not by the organisations that use the shared subsystem.
The figure below illustrates a situation in which a shared subsystem is enabled.
-25d14701261aa30bd71764b79c0b8d46.webp)
What are the requirements for using a shared subsystem?
The shared subsystem works slightly differently from the traditional Data Exchange Layer integration. The implementation requires changes in order to identify organisations in queries sent to other information systems via Security Servers. The implementation is based on the use of authentication, and in this case, we recommend the use of JSON Web Token (JWT)Opens in a new window. authentication, as it is the most common and simplest way to authenticate. The steps of the authentication process are visualised in the figure below.
JWT authentication is an example solution. The service provider can also implement authentication in other ways.
Please note! With regard to testing services, it is good to note that we offer them for the reference implementation described in the article.
-7572fc26d7c5e59f9dd159d2ecbd6c8f.webp)
The steps of the authentication process must be carried out precisely as instructed, or the implementation will not work. It is also important to remember to use HTTPS for traffic between Security Servers and information systems.
Both the service provider and the intermediary representing the service consumer have their own responsibilities in the authentication process.
Service provider's responsibilities
The service provider is responsible for the following matters, which are described in more detail in a separate article:
- We recommend that your subsystem is service-specific, meaning that there is only one service in one subsystem
- The service has one API endpoint for authentication
- Providing user IDs to the intermediary representing the service consumer
- Authenticating a user via an identification query
- Generating and sending a JWT identifier or other similar identifier as part of a response message
- Validating a JWT identifier or other similar identifier when calling a service after authentication
Intermediary's responsibilities
The intermediary representing the service consumer is responsible for the following matters, which are described in more detail in a separate article:
- Using the mTLS server certificate policy between the intermediary’s information system and the organisation using the subsystem
- Using the mTLS server certificate policy between the Security Server and the information system
- Submitting the organisation’s identifying data and the user ID received from the service provider in the first identification query
- Using the JWT identifier or other similar identifier returned by the service provider after the first identification query