Overwegingen

Applicaties en niet gebruikers

In Koppeltaal worden de rollen en rechten op de FHIR resources toegekend aan de applicatie-instanties in een domein, en niet aan de individuele gebruiker die van de applicatie gebruik maakt. Dit is in de kern een legacy probleem, omdat Koppeltaal 1.x nauwelijks een security model heeft, en het model dat er is, is gebaseerd op applicaties en hun rol in het domein. De keuze om hier niet wezenlijk een ander model in te voeren is meerledig, namelijk:

Koppeltaal 2.0 dient zoveel mogelijk de bestaande functionaliteit van Koppeltaal 1.x te vervangen, en juist geen nieuwe toe te voegen.
De huidige applicaties hebben, door het ontbreken van een geëlaboreerd security model in Koppeltaal 1.x, zelf inmiddels een eigen securitymodel ontwikkeld. Om hier een geünificeerd model van te maken die voor alle bestaande applicatie werkt ligt voor nu buiten scope.
Kijkende naar de toekomst van Koppeltaal lijkt een persoonlijk toegangsmodel onontkoombaar, de vraag is bij welke ontwikkeling en/of standaard het beste aangesloten kan worden. Een vraag die afhankelijk is van een nog te ontwikkelen visie.

Vertrouwen gedelegeerd & centraal

Een Koppeltaal domein bestaat uit een aantal applicatie-instanties die ieder in hun eigen rol met elkaar samenwerken om de Use Cases (TODO: link) van Koppeltaal te realiseren. In deze samenwerking, die als kern gegevensuitwisseling kent, is onderling vertrouwen essentieel. In Koppeltaal wordt voor een gedelegeerd vertrouwensmodel gekozen. Binnen het domein is er één enkele autoriteit die bepaalt wat een applicatie mag en kan, en vertrouwen de applicaties die in het domein toetreden deze autoriteit. Hiermee wordt het vertrouwen gedelegeerd en centraal in het domein belegd.

Identiteit en identificatie

Een applicatie binnen een domein maakt zichzelf kenbaar door een identiteit. Deze identiteit kent een cryptografische manifestatie die gefundeerd is in cryptografisch bewijs. In Koppeltaal wordt gewerkt met publieke en private sleutelparen. De houder van een private sleutel publiceert de publieke sleutel als verificatiemiddel. Door een verzameling gegevens te ondertekenen met de private sleutel kan de ontvanger met de publieke sleutel onomstotelijk bewijzen dat de ondertekenaar de eigenaar van de private sleutel is. Om die reden gaan we ervan uit dat het sleutelpaar, de combinatie van publieke en private sleutel de identiteit van de applicatie-instantie is.

Geheimhouding en vertrouwen

Om dit systeem van private en publieke sleutels goed te laten werken, zijn de volgende voorwaarden van toepassing:

Private sleutels moeten beschermd worden, ze mogen op geen enkele wijze gedeeld worden. Het is dus niet de bedoeling dat iets of iemand de hand kan leggen op de private sleutels van een actor in het Koppeltaal domein.
Publieke sleutels op een betrouwbare manier worden uitgewisseld, zodat niets of niemand de publicatie van de actor kan overnemen. Het overnemen van deze publicatie, dus als het iemand lukt andere publieke sleutels te publiceren dan die van de eigenaar, maakt het mogelijk een actor te impersoneren, hetgeen zeer onwenselijk is.

Het fundament van het vertrouwen is dus staat op de volgende principes:

Het vertrouwen dat de private sleutels geheim zijn.
Her vertrouwen dat de publieke sleutels ook echt van de actor zijn van wie we verwachten dat ze zijn.

Dit fundament kan versterkt worden door:

Het toe te staan dat meerdere sleutelparen actief zijn, dit zodat de actor in het domein de sleutels zo geheim mogelijk te maken. Zo hoeven ze niet in de infrastructuur gedeeld te worden.
Het mogelijk te maken sleutelparen direct te kunnen publiceren en intrekken. Dit kent twee voordelen:
- Applicatie-instanties (POD of Virtuele Machine) kunnen bij het opstarten een sleutelpaar genereren, publiceren en gelijk gebruiken.
- Snelle rotatie van sleutelparen mitigeert mogelijk verliezen of lekken van de private sleutels.

De uitwisseling van sleutels

De uitwisseling van de sleutels is de kern van het vertrouwensmodel. Dit topic wordt in detail besproken inTOP-KT-020 - Uitwisseling publieke sleutels. In Koppeltaal wordt dat met voorkeur geregeld via JWKS URLs. Per applicatie-instantie binnen het domein wordt een URL gepubliceerd waar een lijst van actieve sleutels in wordt bijgehouden. Een sleutelpaar kan in gebruik worden genomen door een publieke sleutel aan de lijst van publieke sleutels aan het JWKS endpoint toe te voegen, een sleutelpaar kan per direct worden uitgefaseerd door deze van deze lijst te verwijderen.

De JWKS URL wordt in het applicatiebeheer geconfigureerd. De autorisatie service maakt van deze URLs gebruik voor het identificeren en authenticeren van de applicatie-instanties en het valideren van JWT tokens van applicatie-instanties binnen het domein. Dit kent een aantal voordelen:

Applicatie-instanties hoeven elkaar niet te kennen en vertrouwen; de autorisatie service neemt deze verantwoordelijkheid op zich.
Het is een eenduidige en gestandaardiseerde manier van werken.
Het faciliteert het snel inzetten van meerdere sleutelparen per applicatie-instantie.

Nadelen zijn:

Een online behoefte van de applicatie-instantie betreffende de JWKS url.
Een sterke afhankelijkheid van de beschikbaarheid, en tevens correct functioneren, van de autorisatie service.

Vanuit een beveiligingsperspectief gelden de volgende overwegingen:

Het systeem leunt sterk op de DNS, een DNS overname van een applicatie-instantie vormt een reëel gevaar. Om die reden wordt ook geadviseerd om de JWKS URL niet een “well-known“ URL te laten zijn.
De verantwoordelijkheid voor het intrekken van compromitteerde sleutels ligt bij de applicatie-instanties.

Overzicht van het vertrouwensmodel

Het vertrouwensmodel van Koppeltaal bestaat uit de volgende logische onderdelen.

Sleutelparen

Een applicatie-instantie genereert één of meerdere sleutelparen, het private deel dient geheim te worden gehouden. Het publieke deel dient gedeeld te worden.

Acceptatie

Een applicatie-instantie treedt een domein toe door de JWKS URL of publiek sleutel te registeren bij domeinbeheer.

Publicatie

Een applicatie-instantie kan zijn actieve publieke sleutels door middel van JWKS op een geconfigureerde JWKS URL delen. De publieke sleutels die op de JWKS URL beschikbaar worden gemaakt dienen enkel de sleutels te zijn die in gebruik zijn. Het terugtrekken van een sleutel gebeurt door deze niet langer op de JWKS url beschikbaar te maken.

Identificatie en verificatie

Een applicatie-instantie bewijst zijn authenticiteit door het ondertekenen van een JWT token met een private sleutel. De autorisatie service valideert deze door de publieke sleutel op te zoeken in het JWKS URL dat de applicatie-instantie publiceert. Het JWT token kent een kid header die moet overeenkomen met de key ID van de publieke sleutel die gepubliceerd is op de JWKS URL.

Gedelegeerd vertrouwen

De applicatie-instanties in het domein kunnen door middel van het introspection endpoint alle tokens die in het domein gebruikt worden valideren. Dit zijn:

HTI launch tokens van een andere applicatie-instantie
access_tokens van de authorisatie service.
id_tokens van de authorisatie service.

Voorsorteren op de toekomst

Het zal niemand ontgaan zijn dat er op het gebied van vertrouwensnetwerken veel aan de hand is in Nederland, in de Kamerbrief over landelijk dekkend netwerk infrastructuren wordt dan ook onomwonden het volgende advies gegeven:

Ontwikkel een landelijk vertrouwensmodel los van bestaande infrastructuren en scenario’s. Het project TwiinxNuts bevat een voorstel voor een gezamenlijke visie op een vertrouwensmodel waarbij meerdere afsprakenstelsels tot elkaar komen.

Koppeltaal staat hier niet verre van los van. De oplossingsrichting die met de huidige implementatie is gekozen is dan ook een stap in een richting anders dan een eindstation. Echter, door het gebruik van publieke / private sleutels, het gebruik van verificatie op basis van JWTs (JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication (rfc7523)) en het gedelegeerd beheer op basis van token introspectie (OAuth 2.0 Token Introspection (rfc7662)) wordt dan ook voorgesorteerd op een dergelijk vertrouwensmodel.

Als vervolgstappen in de richting van gestandaardiseerd vertrouwensmodel zien we de volgende bewegingen van Koppeltaal op de korte to middellange termijn:

Het gebruik van DIDs via een vertrouwesinfrastructuur (NUTS) ipv JWKS URLs voor het uitwisselen van publieke sleutels en identiteiten.
In het verlengde van het vorige punt; het publiceren van endpoints van diensten via DID documenten.
Het gebruik van Verifiable Credentials (VCs) voor het creëren van een autorisatienetwerk binnen het Koppeltaal domein. Zo kan een applicatie-instantie toetreden door de centrale domeinautoriteit te vertrouwen, en de autoriteit applicaties toelaten door de uitgifte van VCs.
Het uitwisselen van gegevens tussen domeinen door middel van autorisaties (VCs) door middel van een een vertrouwesinfrastructuur.

De keuzes die gemaakt zijn bij de ontwikkeling van het Koppeltaal standaard is zoveel mogelijk voorgesorteerd en geanticipeerd op de ondersteuning van DIDs en VCs. Zo bevat de access_token van de autorisatie service voor de FHIR resource service de toegangsrestricties in een Domain Specific Language (DSL), om zo de introductie van VCs niet in de weg te zitten.

Toepassing, restricties en eisen

Het vertrouwensmodel wordt in de volgende topics besproken:

Koppeltaal stelselarchitectuur

TOP-KT-008 - Beveiliging aspecten: Vertrouwensmodel van Koppeltaal