Multi-tenancy

Kodjin supports two income parameters for multi-tenancy logic - custom header from internal services - smart-on-fhir token from external clients

Custom headers

configuration file shows whether multi-tenancy is switched on. Also config file has information for urls that are excluded from multi-tenancy logic. Config file path - etc/kodjin/{env}/values/

Example of the file

"enabled": true,
"mandatory_metadata": {
  "tenant-id": {"rbac_claim": "pracitce_ids"},
  "owned-by":  {"rbac_claim": "organization_id"},
},
"exclude_resources": [
    "CapabilityStatement",
    "ImplementationGuide",
    "SearchParameter",
    "ValueSet",
    "CodeSystem",
    "ConceptMap"
  ]

By this configuration we allow to work with custom headers. All custom headers that are connected to multi-tenancy tasks should be like x-kodjin-metadata-{key}. If section with those headers present in config file, then we understand that those headers are mandatory. And we return error in case request doesn't have those headers error 422 - according to kodjin configuration headers: {$headers} are mandatory and should be present in the request.

RBAC is responsible for transformation token-claim into headers.

x-kodjin-metadata-{key} is a json array with strings which has min a 1 value. Example: organisation_id: ["abc"] or organisation_id: ["abc","123"]

x-kodjin-metadata-{key} may contain a wildcard * value that means "all", i.e. full access. Example: organisation_id: ["abc","123","*""] or organisation_id: ["*"]

if API requested to write-operations: POST,PUT,DELETE and contain more than one value in the x-kodjin-metadata-{key} we have return an error 422 and operation outcome with message: {$header} contain more than one value.

Kodjin saves data from header in db in metadata section

Search through custom headers

Search will be done with filtering by headers. Headers with wildcard have access to all data in DB.

Token

From external clients all requests should be set with specific Information in the token. This information will be responsible for tenant.

Each multi-tenancy header shall be mapped (configured) to corresponding token claim.

Example:

"mandatory_metadata": {
  "tenant-id": {"rbac_claim": "pracitce_ids"},
  "owned-by":  {"rbac_claim": "organization_id"},
}

Kodjin with the help of RBAC will retrieve the data from the token and save tenant data to metadata during POST, or filter resources with data from token during get/search.

Validation

There are different logic for read and write operations.

Read (GET, Search, related $operations):

If all values in the token claim match to the corresponding resource metadata the write operation is allowed. Wildcards are allowed for read interactions. Any value could be substituted by wildcard *.

Write (PUT, PATCH, DELETE):

Only one value for each token claim is allowed. Additional value for Wildcard * is optional and will be ignored for write-interactions, but could be presented at the token-claim. If more than one value presented in the token (except *) we must return an error 422. “Multiple values in the header {$header} for write-operations aren't allowed".

Wildcards must be ignored (excluded) from the token-claim.

PUT, PATCH, DELETE is allowed only if the values in the token claims are matched to resource metadata.

POST is allowed if all headers/token-claims are defined and contain only one value or on value+ wildcard for each header/token-claim (rule 1).