Architecturen RSS

1. Inleiding
2. Ontwikkeling van een project in het kader van de online gezondheid: wat men dient te voorzien, te begrijpen en te definiëren
   1. Voorwaarden inzake identificatie en toegangsbeheer
      1. Registratie
      2. Authenticatie
      3. Autorisatie
   2. Voorwaarden inzake informatieveiligheid
      1. Vertrouwelijkheid
      2. Integriteit
   3. Vaststelling van de communicatiestandaarden (talen/protocollen)
   4. Vaststelling van één of meerdere types van stromen
      1. Deel 'Identity & Access Management'
         1. een toepassing die bestemd is om te functioneren op het mobiele toestel van de gebruiker (native app/public client)
         2. een server-based toepassing, die gehost wordt door een partner en opgeroepen wordt door de gebruiker voor gebruik op zijn mobiel toestel (confidential client)
         3. een toepassing die geen menselijke tussenkomst vereist en die bedoeld is om automatisch te functioneren van server tot server, voor de automatische update van gegevensbanken bijvoorbeeld (system client)
      2. Deel 'informatieveiligheid'
3. Schematische voorstelling use cases
   1. Registratie van een publieke sleutel (use case: registratie van een sleutel in het kader van de aanvraag van een eHealth-certificaat binnen een architectuur van het type SOAP)
   2. Registratie van een symmetrische sleutel (use case: registratie van een sleutel in het kader van Recip-e)
   3. Gekende bestemmeling, synchrone mededeling (meest voorkomende use case: wanneer een klant rechtstreeks een dienst van het eHealth-platform moet contacteren die het versleutelsysteem vereist)
   4. Gekende bestemmeling, asynchrone mededeling (use case: eHealthBox)
   5. Onbekende bestemmeling (use case: Recip-e)

1. Inleiding

In het kader van de ontwikkeling en het onderhoud van zijn projecten en diensten biedt het eHealth-platform diverse structuren en organisaties van de informaticasystemen of 'architecturen' aan.

Die modellen zijn gebaseerd op de behoeften van de partners, maar beantwoorden ook aan bepaalde kwaliteits- en veiligheidsnormen. Ze evolueren continu in rechtstreekse relatie met de sector.

Bij het opstarten van een project is het dus belangrijk om de verschillende aangeboden systemen goed te begrijpen met het oog op een optimale implementatie van de diverse componenten, maar ook om te anticiperen op mogelijke toekomstige evoluties.

Het eHealth-platform biedt voornamelijk 2 types architectuur aan:

• een architectuur van het type SOAP (Simple Object Access Protocol ) , bestemd voor toepassingen en diensten die bedoeld zijn om te functioneren op één enkel toestel, één enkele computer.
• een architectuur van het type REST (Representational State Transfer) bestemd voor toepassingen en diensten die bedoeld zijn om te functioneren op verschillende toestellen (gelijktijdig op een computer, smartphone, tablet, ...).

Zoals reeds aangestipt, is informatica een domein dat constant evolueert. Bij het opstarten van het eHealth-platform stond het gebruik van mobiele apparaten zoals tablets en smartphones nog in zijn kinderschoenen. Daarom werd dan ook voornamelijk de architectuur van het type SOAP ontwikkeld en bepaalt dat type architectuur ook vandaag nog een groot aantal systemen dat in samenwerking met onze partners geïmplementeerd werd. Het onderhoud en de ondersteuning van dat model blijft ook nu een van onze opdrachten en verantwoordelijkheden, maar voor de ontwikkeling van projecten voor mobiele apparaten is het gebruik ervan niet aanbevolen (laat bv. geen versleuteling van berichten toe) en wordt prioriteit gegeven aan een architectuur van het type REST.

2. Ontwikkeling van een project in het kader van de online gezondheid: wat men dient te voorzien, te begrijpen en te definiëren

2.1. Het project dient te beantwoorden aan voorwaarden inzake identificatie en toegangsbeheer

Om de mobiele toegang tot de eHealth-diensten mogelijk te maken, dienen we ALLE gebruikers die behoefte hebben aan de diensten van het eHealth-platform te kunnen authenticeren, ongeacht het toestel of het systeem dat gebruikt wordt voor de connectie.

We onderscheiden twee categorieën gebruikers van onze diensten:

• personen (Belgische of buitenlandse burgers, professionals, leden van een organisatie, lasthebbers);
• systemen.

Voor elk van hen moet het mogelijk zijn om een digitale identiteit te construeren.

2.2. Het project dient te beantwoorden aan voorwaarden inzake informatieveiligheid

Het project dient de communicatiestandaarden vast te stellen uit de voorgestelde lijst

Identificatie & Toegangsbeheer

• SAML 2.0
• Oauth 2.0
• OIDC 1.0
• JWT
• Signed JWT Assertion
• PKCE

Informatieveiligheid

• TLS
• JWS
• JWE
• JWK
• WebAuthn

2.4. Het project moet één of meerdere types van stromen definiëren uit de voorgestelde lijst

3. Schematische voorstelling use cases

3.1. Registratie van een publieke sleutel (use case: registratie van een sleutel in het kader van de aanvraag van een eHealth-certificaat binnen een architectuur van het type SOAP)

3.2. Registratie van een symmetrische sleutel (use case: registratie van een sleutel in het kader van Recip-e)

3.3. Gekende bestemmeling, synchrone mededeling (meest voorkomende use case: wanneer een klant rechtstreeks een dienst van het eHealth-platform moet contacteren die het versleutelingssysteem vereist)

3.4. Gekende bestemmeling, asynchrone mededeling (use case: eHealthBox)

3.5. Onbekende bestemmeling (use case: Recip-e)

De portal 'API Catalog' is de catalogus van de webservices die aangeboden worden door het eHealth-platform en zijn partners via de API Gateway, die onder meer instaat voor het beheer van het gebruik van de webservices.

Het betreft:

• technische informatie: URL, versie, formeel contract (WSDL+XSD voor de SOAP-diensten of Swagger voor de REST-diensten
• functionele informatie: link naar de beschikbare documentatie, beschrijving van de online diensten.

Toegang tot de API Catalog