Ga naar inhoud
labs.kadaster.nl | federatief.datastelsel.nl

Conclusies en aanbevelingen

Lock-Unlock richt zich op Linked Data, voortbouwend op de Integrale Gebruiksoplossing (IGO) en de Kadaster Knowledge Graph (KKG) ontwikkeld door het Kadaster. Er zijn weinig gestandaardiseerde mogelijkheden voor autorisatie van data in het Linked Data domein. Dit project is een verkenning om de (on)mogelijkheden te onderzoeken en te testen.

Conclusies

Hoewel het doel van dit project vooral lag op autorisatie als Linked Data, is een deel van de aandacht ook gegaan naar federatieve bevraging. Dat schetst namelijk de context waarin afscherming zou moeten plaatsvinden. Uiteraard hebben we ook beproefd in hoeverre autorisatie als Linked Data mogelijk en haalbaar is via prototype implementaties met 2 verschillende aanpakken. Over de voor- en na-delen van de 2 aanpakken hebben we apart een korte evaluatie geschreven. De conclusies volgen hier:

⚠ Zie ook disclaimer.

Autorisatie als Linked Data

Afschermen van Linked Data is mogelijk

Het is mogelijk om fijnmazig autorisatieregels declaratief te modelleren op basis van een autorisatie ontologie voor federatieve bevragingen op basis van Linked Data. We hebben dit aan kunnen tonen in onze demonstrators, waarin we een eerste toepassing van een door ons ontwikkelde autorisatie ontologie hebben uitgewerkt. Hieruit blijkt dat het mogelijk is om een sparql-endpoint op te zetten die alleen informatie teruggeeft waarvoor je de benodigde rechten hebt.

Declaratieve autorisatieregels als Linked Data

Met autorisatieregels doelen we op toegangsregels die gelden voor een specifieke situatie. Voor een bepaalde gebruikersgroep wordt toegang verleend voor een specifiek data-schema, een specifieke ontologie. De regels die gelden kunnen zeer fijnmazig zijn en de verschillende afschermingspatronen bevatten. We hebben in onze demonstrators aangetoond dat verticale en horizontale subsets mogelijk zijn. Afscherming van een zoek richting is helaas niet beproefd. Is het mogelijk? Wij denken van wel.

De autorisatieregels zijn declaratief. Dat betekent dat de gewenste toegang of juist afscherming gespecificeerd kan worden. Onderliggende uitvoering en zelfs uitwerking wordt overgelaten aan een 'engine' die zorgdraagt voor de afscherming.

Dit houdt ook in dat de autorisatieregels zelf data zijn (#data-gedreven). Dit betekent:

  • dat de autorisatieregels kunnen worden bevraagd (wie heeft toegang tot wat en eventueel zelfs waarom (niet)). Wellicht is het mogelijk om te verwijzen t/m de wettelijke grondslag?
  • dat de autorisatieregels kunnen worden opgesteld en gedefinieerd onafhankelijk van de software (engine) waarmee de regels worden afgedwongen
  • dat de autorisatieregels als knowledge graph toegankelijk zijn
  • dat de autorisatieregels opgesteld kunnen worden gebruikmakende van de Linked Data schema's

Autorisatie ontologie voor standaardisatie

De autorisatieregels kunnen worden gestandaardiseerd in een autorisatie ontologie. Dat betekent dat een software implementatie van deze ontologie als engine gebruikt kan worden om de data van de autorisatieregels uit te voeren. Doordat een ontologie programmeertaal onafhankelijk is, kunnen er meerdere implementaties gemaakt worden voor de autorisatie ontologie.

Declaratieve autorisatieregels gekoppeld aan bestaande ontologieën

Het is mogelijk om in de declaratie van de autorisatieregels volgens de autorisatie ontologie, een relatie te maken naar al bestaande ontologieën. Dat wil zeggen dat de toegang (of juist ontzegging daarvan) gedeclareerd kan worden volgens de autorisatie ontologie en daarbij kan gedeclareerd worden over welke andere ontologie die regels gelden. In ons voorbeeld zijn dat de registratie ontologieën van de BRK, BRP en NHR. De autorisatieregels zijn daarmee direct gekoppeld aan de schema-elementen van deze register ontologieën.

Deze vorm biedt inzicht in wie waar toegang toe heeft of juist niet. Daarmee biedt het mogelijkheden tot verificatie van de autorisaties (eventueel aan andere partijen, zoals een toezichtshouder).

Conclusies van beproevingen

  • het is mogelijk om gebruik te maken van de data om autorisatieregels op te stellen. Zo kunnen er bijvoorbeeld toegangsregels opgesteld worden voor een bepaalde gemeente. De daadwerkelijke gemeente wordt uit de dataset opgehaald.

  • De geïdentificeerde afschermings patronen zijn generiek en bieden veel mogelijkheden tot afscherming via configuratie van deze patronen.

  • De PoC implementaties laten zien dat veel autorisatie patronen makkelijk implementeerbaar en haalbaar zijn. (Deze implementaties zijn niet bruikbaar voor productie en eventuele problemen mbt veiligheid en schaalbaarheid zijn niet onderzocht. Zie ook disclaimer.)

  • Fictieve data van gekoppelde registers in Linked Data is makkelijk te realiseren.

  • Rewritten queries uit de implementatie rewrite zijn complexer dan de orginele queries. Dat geeft extra belasting bij de uitvoering van de query. Daarom zijn optimale queryplannen noodzakelijk zijn om prestatie (performance) redenenen. Alleen triplestores met goede optimalisatie van queryplannen kunnen deze queries performant uitvoeren.

  • Het afschermen van gegevens zo dicht mogelijk bij de triplestore biedt grotere zekerheid dan afscherming van gegevens door applicaties.

  • Bewijs dat de queries 'waterdicht' zijn is niet aanwezig in dit project noch was dit de doelstelling van de PoC implementaties. Zie ook aanbeveling Volledigheid en effectiviteit meetbaar maken.

Federatieve bevraging

Linked Data maakt federatieve bevraging gemakkelijk

Een federatieve bevraging is op meerdere manieren mogelijk. Een omgeving met REST API's biedt ook wel de mogelijkheid voor federatieve bevragingen, maar dit legt een grote beheerlast bij de 'vrager'. Met GraphQL zijn daar stappen in gemaakt, maar daarin is nog steeds behoefte aan gateway oplossingen.

Linked Data is ontworpen met federatie in de basis. Vanuit het ontwerp is federatieve bevraging daarom al beschikbaar. In de Linked Data Query Language, SPARQL, is dit gespecificeerd met de service clause. Daarmee is het relatief eenvoudig om een federatieve bevraging, een SPARQL query, te schrijven die uitvoerbaar is. Daarmee is Linked Data van nature geschikt voor federatief bevragen. In applicaties die ondersteuning hebben voor Linked Data en SPARQL is het eenvoudig om rijke en federatieve functionaliteit te ontwikkelen.

Open Source triplestores maken testopstelling gemakkelijk

Door gebruik te maken van Open Source producten voor Linked Data databases, zogenaamde triplestores, is het opbouwen van een testopstelling relatief gemakkelijk. In onze cloud omgeving wordt gebruik gemaakt van Cloud Native tools en daarvoor was nog geen standaard deployment script beschikbaar. Tegelijk was het niet extreem moeilijk om, met kennis van zaken natuurlijk, deze te ontwikkelen en te gebruiken voor de testopstelling.

Open Source maakte het ook mogelijk om eigen implementaties te ontwikkelen tbv van autorisatie als Linked Data. Ons eigen werk is ook openbaar beschikbaar tbv verdere ontwikkelingen, zie opleveringen.

Performance van federatieve bevraging varieert

Dat federatieve bevraging standaard in de Query Language zit en in de basis van Linked Data wil dat niet zeggen dat er geen 'problemen' zijn. In concept is het al ingewikkeld om een generieke werkwijze te bedenken die een query snel uitvoert. Daar is vrijwel altijd een analyse van de query voor benodigd om uit te werken wat de snelste manier is om de vraag (query) te beantwoorden. Deze analyse en uitwerking naar snelle uitvoering van federatieve vragen, is niet gestandaardiseerd in SPARQL of Linked Data. In de verschillende implementaties van triplestores zijn hier grote verschillen. In dit project is er gebruik gemaakt van een open-source triplestore waarbij query performance achterloopt t.o.v. de commerciele toppers.

Er zijn wel ontwikkelingen rondom federatieve bevraging in het Linked Data domein. Zie ook aanbeveling Meer onderzoek naar performance federatieve bevragingen

Duurzame koppeling van silo's vraagt om een expliciet ontwerp

Impliciet zijn registers koppelbaar vanwege (impliciet) aanwezige koppelsleutels. In alle gevallen zullen sleutels tussen registers / silo's op elkaar moeten passen. Linked Data biedt daar standaard al enige constructen voor om in een query transformaties of iets dergelijks te doen. Dit is echter een punt oplossing en moet voor elke query opnieuw toegepast worden.

Om duurzaam over silo's van data heen goed te kunnen navigeren en federatieve bevragingen te vergemakkelijken, dient minimaal deze data gekoppeld te zijn. Linked Data biedt hiervoor verschillende mogelijkheden. Een mogelijkheid is bijvoorbeeld om een upper ontology voor de registers af te spreken. Door adoptie van deze upper-ontologie kunnen relaties tussen de informatie modellen maar ook relaties tussen de datasets toegevoegd worden.

Zie ook informatiekundige kern.

Aanbevelingen

Linked Data adoptie vergroten

Linked Data biedt veel mogelijkheden voor federatieve bevragingen, expliciete verplichting voor semantiek, informatiemodellen en begrippen. En met de autorisatie ontologie komt ook afscherming in de mogelijkheden van Linked Data. Het succes en toepassen van deze technieken staat of valt echter met de adoptiegraad van Linked Data in het algemeen. Het vergroten van deze adoptie is daarom van belang. Hierbij kun je vragen stellen zoals wat is het minimum noodzakelijke voor een registerhouder om data als Linked data te publiceren. Wat is de minimale infrastructuur hiervoor en hoe kan er snel en robuust Linked Data gecreëerd worden. Ook onderzoek naar de usecases waarbij Linked Data een grote meerwaarde biedt boven REST API's met autorisatie toevoegingen in de onderliggende implementaties zijn zinvol. Usecases met een beperkt aantal gebruikers (en daardoor beperkte schaalbaarheid implicaties) maar met grote functionele meerwaarde zijn interessante kandidaten om Linked Data toe te passen.

Autorisatie ontologie verder uitwerken

De Authorisation Ontology waar in dit project een eerste opzet van is gemaakt, dient verder te worden uitgewerkt. Idealiter ontstaat er een geadopteerde standaard autorisatie ontologie. Dat betekent ook dat vendors van triple stores deze standaard kunnen implementeren zodat het écht gaat werken. Federatief!

Het is daarin van belang dat ook alternatieven goed geanalyseerd en overwogen worden. In dit onderzoek hebben we daar wel kennis van genomen, maar zijn we te weinig toegekomen aan een 'in depth' vergelijking.

Voor de ontwikkeling zou een W3C Working Group uiteraard een mooi middel zijn!

Beperking van richting uitwerken

In dit project hebben we uitgewerkt en beproefd hoe verticale en horizontale subsets afgeschermd of juist ontsloten kunnen worden. We hebben geen aandacht kunnen besteden aan het beperken van de richting. Hier dient extra (vervolg)onderzoek op gedaan te worden.

Volledigheid en effectiviteit meetbaar maken

In dit onderzoek is aangetoond dat het mogelijk is om mbv een autorisatie ontologie een 'secured SPARQL endpoint' te ontwikkelen (twee zelfs! 😁). We hebben echter niet aangetoond dat dit volledig waterdichte toegangscontrole biedt. Sterker nog, we zijn niet eens toegekomen aan de richting beperken.

Om (later) aan te tonen dat de autorisatie ontologie volledig is en effectief wordt toegepast voor een 'secured SPARQL endpoint' is het noodzakelijk om een betrouwbare en herhaalbare meetmethode te hebben. Hierin zullen de verschillende afschermingspatronen opgenomen moeten zijn en allerlei variaties en combinaties hierin.

Opvolging organiseren tbv volledigheid en effectiviteit

Verdere R&D bewijsvoering dat de implementatie waterdicht is. Eventueel in samenwerking met academici voor een wetenschappelijk fundament.

Meer onderzoek naar performance federatieve bevragingen

De performance van federatieve bevragingen is nog weinig onderzocht en er is waarschijnlijk veel ruimte om dit te verbeteren. De voornaamste aspecten hierin zijn de schaalbaarheid en de optimalisatie van de queries. Het gebruiken van HDT-bestanden, en specifiek de header-sectie, kan interessante mogelijkheden bieden hierin.

Informatiekundige kern

Relaties tussen registers en silo's is zonder afspraken nogal ingewikkeld. Deze relaties zijn ook niet altijd absoluut. Dat wil zeggen dat met 100% zekerheid gesteld kan worden dat een object van de ene silo gerelateerd is aan een object van de andere silo. Het helpt dus om relaties expliciet te ontwerpen.

In Linked Data zijn relaties en matching patronen gemakkelijker te leggen en te gebruiken dan bij niet-Linked Data oplossingen. Linked Data is standaard gebaseerd op informatiemodellen en ontologieën. Daarom zijn er met Linked Data vele mogelijkheden voor het dynamisch maken en leggen van relaties. Heel uitgebreide voorzieningen en afspraken zijn daarom minder noodzakelijk indien Linked Data gebruikt wordt.

Het is (natuurlijk) wel mogelijk om de relaties méér nadruk en belang te geven. Oplossingen die Linked Data daarvoor kan bieden, zijn een upper ontology en/of gematerialiseerde relaties. Daarmee zouden relaties gestandaardiseerd en geformaliseerd kunnen worden. Daarna zouden (gelijke) functionele zaken gestandardiseerd kunnen worden. Denk aan "ID"'s en versie beheer en meta-data van registers in Linked Data.

Zie hiervoor ook onze uitgebreide beschrijving van deze concepten in informatiekundige kern.

Meer onderzoek naar performance van de afscherming

Naast de performance van een Linked Data oplossing in het algemeen, voegt de afscherming nieuwe en extra complexiteit verhogende eisen en karakteristieken toe. Onderzoek naar de performance van specifiek dit onderdeel verdient meer aandacht.

Implementaties doorontwikkelen

Een eerste aanzet en prototyping rondom implementaties is gedaan, maar verdient meer opvolging. Er zijn twee verschillende strategieën uitgewerkt om ervaring op te doen met deze twee richtingen. Er was geen mogelijkheid om deze uitgebreid te vergelijken en voordelen en nadelen van de verschillende strategieën scherp naast elkaar te zetten; alleen een korte evaluatie. Hier is nog aanvullend onderzoek nodig.

Uitgaande dat er gewerkt is aan standaardiseren van de autorisatie ontologie en dat aanvullend onderzoek is gedaan in implementatie strategieën, zouden implementaties wél (of ook) in triplestores toegepast kunnen worden. Daarom kan bij deze aanbeveling gedacht worden aan vervolgonderzoeken in samenwerking met open source projecten als Apache Jena, vendors van triplestores en academici.

Disclaimer

Dit project is een onderzoeksproject. De opleveringen die ontstaan zijn, zijn van het niveau Research & Development. Goed ter inspiratie en voor vervolgonderzoek zeer geschikt. Voor productie ... ongeschikt! ⚠

  • ⚠ Authenticatie is uitgesloten van dit project en als gegeven beschouwd. Hier is echter ook nog veel in te kiezen en te onderzoeken!

  • ⚠ De autorisatie ontologie die opgeleverd is in dit project, is slechts een eerste prototype en voorbeeld! Dit is uitsluitend voor Research & Development doeleinden. Zie ook aanbeveling autorisatie ontologie verder uitwerken

  • ⚠ De implementaties zijn nog niet bruikbaar voor productie en eventuele problemen mbt veiligheid en schaalbaarheid zijn niet onderzocht