Autorisatie

Autorisatie

Doel van dit document is een eenduidige definitie van autorisatie binnen Amsterdam Schema en de interactie met Profiles.

Data autorisatie is altijd gekoppeld aan scopes. Een scope is een bepaalde groep gebruikers (medewerkers) met gedeelde rechten. Een gebruiker kan meerdere scopes hebben.

De default scope is "OPENBAAR", en dus in principe publiekelijk toegankelijk. Daar waar data niet publiek toegankelijk mag zijn, wordt een scope aangebracht door middel van een "auth" attribuut. Data kan expliciet openbaar worden gemaakt met "auth" : "OPENBAAR".

De autorisatie hierop is op verschillende plaatsen geïmplementeerd:

• database (aan de hand van postgres roles)
• dso-api (een custom Django permission framework)
• ...

In het volgende (voorbeeld) schema vindt autorisatie plaats op 3 niveaus:

{
  "type": "dataset",
  "id": "gebieden",
  "title": "gebieden",
  "auth": "LEVEL/A",
  "status": "beschikbaar",
  "version": "0.0.1",
  "crs": "EPSG:28992",
  "temporal": {
    "identifier": "volgnummer",
    "dimensions": {
      "geldigOp": ["beginGeldigheid", "eindGeldigheid"]
    }
  },
  "tables": [
    {
      "id": "bouwblokken",
      "mainGeometry": "geometrie",
      "type": "table",
      "auth": "LEVEL/B",
      "schema": {
        "$id": "https://github.com/Amsterdam/schemas/gebieden/bouwblokken.json",
        "$schema": "http://json-schema.org/draft-07/schema#",
        "type": "object",
        "additionalProperties": false,
        "identifier": ["id"],
        "required": ["schema", "id"],
        "display": "id",
        "properties": {
          "schema": {
            "$ref": "https://schemas.data.amsterdam.nl/[email protected]#/definitions/schema"
          },
          "id": {
            "type": "string",
            "description": "Unieke identificatie voor dit object, inclusief volgnummer"
          },
          "beginGeldigheid": {
            "type": "string",
            "format": "date",
            "description": "De datum waarop het object is gecreëerd.",
            "auth": "LEVEL/C"
          },
          "eindGeldigheid": {
            "type": "string",
            "format": "date",
            "description": "De datum waarop het object is komen te vervallen.",
            "provenance": "eindgeldigheid"
          },
          "ligtInBuurt": {
            "type": "string",
            "relation": "gebieden:buurten",
            "provenance": "ligtinbuurt",
            "description": "De buurt waar het bouwblok in ligt."
          }
        }
      }
    }
  ]
}

Scope LEVEL/A heeft dataset level autorisatie op gebieden, scope LEVEL/B heeft tabel level autorisatie op bouwblokken en scope LEVEL/C heeft autorisatie op veld beginGeldigheid.

Met autorisatie wordt lees permissie bedoeld. Uitbreiding hierop kan door middel van een profile.

Vier mogelijke, legitieme interpretaties zijn mogelijk:

OF-OF model, inclusief

• Een user met scope LEVEL/A mag alles uit de dataset gebieden zien.
• Een user met scope LEVEL/B mag alle velden van tabel bouwblokken zien.
• Een user met scope LEVEL/C mag veld beginGeldigheid zien.

OF-OF model, exclusief

• Een user met scope LEVEL/A mag alles uit de dataset gebieden zien, behalve tabel bouwblokken.
• Een user met scope LEVEL/B mag alle velden van tabel bouwblokken zien, behalve beginGeldigheid.
• Een user met scope LEVEL/C mag veld beginGeldigheid zien.

EN-EN model, inclusief

• Een user met scope LEVEL/A mag alles uit de dataset gebieden zien.
• Een user met scopes LEVEL/A en LEVEL/B mag alle velden van tabel bouwblokken zien.
• Een user met scopes LEVEL/A, LEVEL/B en LEVEL/C mag veld beginGeldigheid zien.

EN-EN model, exclusief

• Een user met scope LEVEL/A mag alles uit de dataset gebieden zien, behalve tabel bouwblokken.
• Een user met scopes LEVEL/A en LEVEL/B mag alle velden van tabel bouwblokken zien, behalve beginGeldigheid.
• Een user met scopes LEVEL/A, LEVEL/B en LEVEL/C mag veld beginGeldigheid zien.

Met OF-OF wordt dus bedoeld dat een LEVEL/B scope gebruikt kan worden zonder LEVEL/A; met EN-EN heb je in dit voorbeeld niets aan een LEVEL/B zonder ook LEVEL/A te hebben.

Met inclusief wordt bedoeld dat in dit voorbeeld LEVEL/A ook toegang behoudt tot lagere niveaus, zoals bijv. veld beginGeldigheid, ook al heeft dat veld op dat niveau een andere scope.

Gekozen wordt voor het "OF-OF model, exclusief".

Volgens het meta schema mag het auth veld zowel een string als een list zijn. Voor het geval het auth veld een list zou zijn, dan zou dat geinterpreteerd moeten worden als een "OF" lijst. Dus: "auth": ["LEVEL/X", "LEVEL/Y"] geeft zowel scope "LEVEL/X" als scope "LEVEL/Y" toegang, maar het is niet nodig om beide scopes te bezitten.

Profiles

In een profile kunnen additionele permissies worden ingesteld.

Mogelijke principes:

1. Met een profile kunnen alleen restricties worden toegevoegd; restricties uit het schema kunnen nooit worden versoepeld. Dus nooit een dataset via een profile OPENBAAR maken wat volgens het schema beperkt is tot een bepaalde scope. Dit is waarschijnlijk te restrictief en niet hoe het bedoeld was, maar dat hangt ook af van de keuzes voor schema autorisatie.
2. Of andersom, dat je via een profile restricties kunt versoepelen. Bijv. het geven van write permissions. De scope moet dan wel overeenkomen, anders komen we uit op de volgende mogelijkheid:
3. Of een OF-OF relatie, waarin schema en profile naast elkaar leven en beiden onafhankelijk permissies kunnen geven.

Keuze 2) zou een mooie tussenvorm kunnen zijn tussen privacy technisch sterk (in het schema wordt de scope vastgelegd), en praktisch (in een profile kun je dan de permissies regelen die niet in het schema passen).