This document describes how Profile Based authorization is working.
Each dataset defines minimal required permissions per dataset/table/field, if needed.
This is done via auth
parameter on each level respectively.
{
"type": "dataset",
"id": "brp",
...
"auth": "BRP/R"
"tables": [...]
}
{
"type": "dataset",
"id": "brp",
...
"tables": [
{
"id": "ingeschrevenpersonen",
"type": "table",
"auth": "BRP/R",
"schema": {
...
}
}
]
}
{
"type": "dataset",
"id": "brp",
...
"tables": [
{
"id": "ingeschrevenpersonen",
"type": "table",
"schema": {
...,
"properties": {
"schema": {
"$ref": "https://schemas.data.amsterdam.nl/schema@v1.1.1#/definitions/schema"
},
"id": {
"auth": "BRP/R"
"type": "integer"
}
}
}
}
]
}
All of above require BRP/R
permission in order to access data.
In addition to Dataset Level Configuration we may define Profiles that expand access rights for given scope.
Each request may contain one or multiple profiles, this is controlled by scopes
definition of each profile.
NOTE: profile is assigned to request only if ALL profile scopes are subset of request scopes. Profile with no scopes will be assigned to all requests.
- name: Human Friendly profile name
- scopes: List of scopes required to use this profile
- datasets: Dictionary with details per dataset
Each dataset may define either permissions
or tables
definition that will apply to it's tables.
- permissions: string, defines permission to access all tables and all fields within dataset, overwriting dataset level configuration. (possible value:
read
) - tables: dictionary, defines detailed configuration for table or fields
Each dataset table may define either permissions
or fields
definition that will apply to it's fields.
- permissions: string, defines permission to access all fields within table, overwriting dataset level configuration. (possible value:
read
) - fields: dictionary, defines detailed configuration for each field
Each field can define representation level to be presented to user.
- read: plain text representation of field
- encoded: encoded string
{
"name": "medewerker",
"scopes": ["FP/MD"],
"datasets": {
"parkeervakken": {
"permissions": "read"
},
"klantbeeld": {
"tables": {
"BvAdresBewonershistorie": {
"fields": {
"bsn": "encoded",
"einddatum_bewoning": "read"
}
}
}
}
}
}
Each request may contain one or multiple Profiles assigned, each profile may only extend permissions given to user.
This means if there are 2 profiles, one of which allows access to one field only, while another allows access to all fields - user will see all fields.
Representations will be merged in favour of highest as well. Given 2 profiles with encoded
and read
permissions, user will see read
representation.
# dataset configuration
{
"type": "dataset",
"id": "brp",
"auth": "BRP/R"
...
"tables": [
{
"id": "ingeschrevenpersonen",
"type": "table",
"schema": {
...,
"properties": {
"id": {
"type": "integer"
}
"bsn": {
"auth": "BRP/RS"
"type": "string"
},
...
}
}
}
]
}
# profile configuration for BRP/RS
{
"name": "medewerker",
"scopes": ["BRP/RS"],
"datasets": {
"brp": {
"tables": {
"ingeschrevenpersonen": {
"fields": {
"bsn": "encoded"
}
}
}
}
}
}
# profile configuration for BRP/RSN
{
"name": "medewerker+",
"scopes": ["BRP/RSN"],
"datasets": {
"brp": {
"tables": {
"ingeschrevenpersonen": {
"fields": {
"bsn": "read"
}
}
}
}
}
}
In example above Dataset is not available to general public and requires BRP/R
scope to be given to request.
Requests with BPR/R
scope will see following fields in API output:
{
"id": 1
}
This is because field bsn
requires additional permission BRP/RS
to be seen.
Profile definition for BRP/RS
controls how bsn
field is seen, namely encodes field for this profile.
Requests with BRP/RS
scope will see following fields in API output. NOTE: BRP/R
scope is not required to be present in request.
{
"id": 1,
"bsn": "eabef034"
}
Profile definition for BRP/RSN
allows bsn
field to be seen in plain text, therefore requests with BRP/RSN
scope present will see plain text bsn:
{
"id": 1,
"bsn": 908923894
}