Access Control

Data-Centric Security

All data entering CORE is labelled with access control meta-data. These security labels are carried in the headers of all the Kafka data events, and finally picked up by the Smart-Caches and held against individual entities, relationships and attributes. Smart-Caches provide redacting access to the data either as an API or query endpoint. These redactors compare the credentials (attributes) of the authenticated user against the data and only release that data which the credentials allow. Because the labels can be applied atomically (entities, relationships, attributes) the data can be redacted in a very selective manner - maximising the amount of data that can be shared while still protecting the sensitive data.

Alt text

There are a number of access control standards that are applicable to a platform like CORE - usually developed by national government or NGO. So that CORE can be used across a number of territories and sectors, we have developed a low-level internal labelling format - RDF ABAC to act as a common format that all the others can be mapped into. The UK Government standard for secure data labelling is Enterprise Data Headers (EDH) which has not been published outside of government yet. For the purposes of UK government deployments, we have created a simple labelling format that closely resembles EDH - the Information Data Header (IDH)

Information Data Header (IDH)

The IDH is a standard for describing the metadata describing the handling and access control about the data item it is assigned to. This data label is used as part of access controlled test, determining whether a user can or cannot view the data. The usage of the data and what the user can do with the data is out of scope for the header and is down to local policy and controls.

The table below defines fields in the IDH, what they mean and if they are used as part of the access control decision.

key sub-key cardinality used in access control decision description
apiVersion - [1] No Version number of the IDH specification used
uuid - [1] No Unique identifier for the data header
creationDate - [1] No The date time that the label was created
containsPii - [1] No States whether the data contains personally identifiable information
dataSource - [1] No A reference to the original dataset which the data originates
ownership originatingOrg [1] No The organisation which created and owns the data
ownership user [1] No ???
access classification [1] Yes Protective marking of the data
access allowedOrgs [1…n] Yes List of organisations which can access the data
access allowedNats [1…n] Yes List of user nationalities which can access the data
access groups [0…n] Yes List of groups which the user must be a member of to access the data. These groups must exist within ACCESS

This is the definition of the IDH, but we make use of this within the platform via JSON objects following the schema below.

{
    "idh": {
        "apiVersion": str,
        "uuid": str,
        "creationDate": datetime,
        "containsPii": bool,
        "dataSource": optional<str>,
        "ownership": {
            "originatingOrg": str,
            "user": optional<str>
        },
        "access": {
            "classification": enum['O', 'OS', 'S', 'TS] ,
            "allowedOrgs": array<str>,
            "allowedNats": array<str>,
            "groups": array<str>
        }
    }
}

User Attributes

Each user has a set of attributes which are used to make access control decisions within the platform. The users and their entitlements are held, out of the box, within Telicent ACCESS1. The table below states the details held about the user and highlights the attributes used as part of access control decisions.

Attribute Type Used in access control decision Description
Name str false Identifying name of the user
Email str false  
Active bool true Represents if the user is activated. If this is false when an access control decision requests information about the user attributes return as empty
Classification str: [‘O’ or ‘OS’ or ‘S’ or ‘TS’] true Represents the high water mark for data the user is allowed to see
Nationality str: valid country Alpha3 code true The nationality of the user
Deployed Organisation str true The name of the organisation which the user is acting on behalf of
Groups set true The set of groups which the user is a member of, these are selected from the Groups created in Access

Access Control Decisions

There are currently two points in the system where access control decisions are made.

  • Authenticated user requesting data
  • Filtering for data sharing to a second CORE

Authenticated Users Requesting Data

When a user requests data, each piece of data must have its IDH assessed against the user’s attributes. The mechanism for doing this access control decision is a library called RDF-ABAC, which is provided the user’s attributes and the Security-Label assigned to the data. The creation of the Security-Label is described here. The Security-Label for the piece of data holds a policy to evaluate the user against using the following logic.

Data Label Key User Attribute Evaluation logic
idh.access.classification classification classification >= idh.access.classification
idh.access.allowedNats nationality idh.access.allowedNats.exists_one(nat, nat === nationality)
idh.access.allowedOrgs deployed_organisation idh.access.allowedOrgs.exists_one(org, org === deployed_organisation)
idhaccess.groups groups idh.access.groups.all(group in groups)

The only exception to this is the active attribute which acts as an override. If the user has not been activated, the object passed to RDF-ABAC will contain no attributes at all.

Filtering for data sharing to a second CORE

When a federation client is setup, they are assigned similar attributes to a user. We currently implement a set policy over the data being shared via federation. Lets say the we can describe the data which the federation client can hold (or the agreed parameters of the data sharing request) using the below representation

Attribute Type Used in access control decision Description
name str false Identifying filters name of the user
classification str: [‘O’ or ‘OS’ or ‘S’ or ‘TS’] true Represents the high water mark for data the classification which is both agreed to be shared and/or which the system can hold
nationalities set: valid country Alpha3 code true The nationalities supported in the federation client
organisation str true The organisation owning the federation client
groups set true The set of groups which the organisation can see

The way these are evaluated against IDH are described in the table below.

Filter Attribute Data Attribute Evaluation logic Notes
filter.classification idh.access.classification filter.classification >= idh.access.classification  
filter.organisation idh.access.allowedOrgs idh.access.allowedOrgs.exists_one(i, i == filter.organisation) This check is making sure the organisation the filter is being provided for can see the data
filter.nationalities idh.access.allowedNats idh.access.allowedNats.all(n, n in filter.nationalities) This check is to ensures that the nationalities supported by the federation client only data with both these labels get through. This reduces the chance of sending GBR only data over to somewhere another nationality could see it
filter.groups idh.access.groups idh.access.groups.all(g, g in filter.groups) This checks ensures that all groups the data holds will be satisfied by the filter, including empty sets

Examples

Using the Federation Filter:

type: Federation Filter
attributes:
  name: CORE2 Example
  classification: S
  organisation: Org2
  nationalities:
    - GBR
    - USA
  groups:
    - square
    - circle
    - rectangle
Example 1 - Rejected IDH, classification too high 
type: IDH Label
---
access:
  classification: TS
  allowedOrgs:
    - Org1
    - Org2
  allowedNats:
    - GBR
    - USA
  groups:
    - square

As the classification of the IDH is high than the classification is allowed to be shared with the federation client (S < TS).

Example 2 - Rejected IDH, organisation not allowed 
type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
  allowedNats:
    - GBR
    - USA
  groups:
    - square

As the organisation “Org2” is not included in the allowedOrgs of the IDH label.

Example 3 - Rejected IDH, nationalities not included 
type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
  allowedNats:
    - FRA
  groups:
    - square

The federation clients nationalities are not included in the IDH labels allowed Nats.

type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
  allowedNats:
    - GBR
  groups:
    - square

As the allowedNats does not include both the nationalities in the federation client, the IDH will be rejected.

Example 4 - Rejected, due to groups 
type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
  allowedNats:
    - FRA
  groups:
    - triangle

The federation client’s groups does not include the triangle group, so the IDH will be rejected.

type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
  allowedNats:
    - FRA
  groups:
    - square
    - triangle

Although the federation client’s groups includes square, the IDH will be rejected because the client groups does not include triangle.

Example 5 - Accepted 
type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
    - Org2
  allowedNats:
    - GBR
    - USA
  groups:
    - square

This IDH would pass the filter as the classification of the IDH is the same as that allowed by the filter, the filters organisation is included in the allowedOrgs, both nationalities are satisfied and the IDH groups is a strict subset of the federation clients filter groups.

type: IDH Label
---
access:
  classification: S
  allowedOrgs:
    - Org1
    - Org2
  allowedNats:
    - GBR
    - USA
  groups: []

This is also accepted, for the same reason as above and the IDH groups is the empty set and is subsequently a strict subset of the federation clients filter groups.

  1. Telicent ACCESS is for demo and development purposes only, it should not be used within production environments. ↩

[EARLY DRAFT RELEASE] Copyright 2020-2025 Telicent Limited. All rights reserved