Authorization schema tables

The authorization schema contains a set of tables with the information about the authorization of users and apps to grant access to specific Data Storage Units (DSU), Entities and Providers. The authentication in Sidra Data Platform is performed by an Identity Server instance installed in Core resource group. The authorization is performed using Balea.

authorization-schema

In the authorization process there are three key elements:

  • The user that is trying to get access to the resource
  • The type of permissions over that resource
  • The resource which is trying to be accessed

Applications table

An application represents a software system which permissions want to be managed. Balea supports handling the authorization for several applications, so the same subject can have a different set of permissions in each application. The Applications table is used to store the information of the applications. Currently Sidra Data Platform only uses Balea for the authorization to the metadata in Core, so the only application registered is Sidra.Core.

Column Description
Id Application identifier
Name Name of the application
Description Description of the application

Subjects table

A subject identifies a user -an individual- or a client -a software system, e.g. a client app- in the authorization system. Sidra is configured to map the UPN (User Principal Name) from the claims received from Identity Server to subjects in the authorization system.

Column Description
Id Identifier of the subject in the table (primary key)
Sub Subject identifier, e.g. email in case of a user, clientId in case of a client
Name Name of the subject

Roles table

This table represents roles. The authorization is performed by a role-based access model in which subjects are associated to roles and roles to a set of permissions.

Column Description
Id Identifier of the role
Name Name of the role
Description Description of the role
Enabled If the role is enabled or not
ApplicationId Identifier of the application

This table is populated with the default roles used in Sidra platform:

  • CanCreateDatalake
  • CanReadMetadata
  • CanWriteMetadata
  • CanDeleteMetadata
  • CanModifyTag
  • CanUnmaskData
  • CanAccessIdentityServer
  • Admin

RoleSubjects table

This table implements the association between Roles and Subjects.

Column Description
RoleId Role identifier
SubjectId Subject identifier

Permissions table

A permission is the ability to perform some specific operation. This table represents the permissions defined in Sidra.

Column Description
Id Permission identifier
Name Name of the permission
Description Description of the permission
ApplicationId Identifier of the application

This table is populated with the default permissions used in Sidra Data platform:

  • CanCreateDatalake
  • CanReadMetadata
  • CanWriteMetadata
  • CanDeleteMetadata
  • CanModifyTag
  • CanUnmaskData
  • CanAccessIdentityServer
  • Admin

RolePermissions table

This table implements the association between Roles and Permissions. As can be seen the predefined Roles are the same that the predefined Permissions since every predefined role is associated to the predefined permission of the same name.

Column Description
RoleId Role identifier
PermissionId Permission identifier

Delegations table

This table represents permission delegations between users. In role-based access model, permission delegation involves delegating roles to another users that can assume a set of permissions to access to the resources on behalf of the user.

Column Description
Id Delegation identifier
WhoId User (Subject Id) who delegates permissions
WhomId User (Subject Id) to delegating
From Date when delegation starts
To Date when delegation finish
Selected If the user is acting on behalf of. Only one should be selected, if there are more than one selected, Balea selects the first one the user have selected
ApplicationEntityId Identifier of the application

Mappings table

This table represents roles coming from authentication system so they can be mapped to the application roles.

Column Description
Id Mapping identifier
Name Name of the mapping

RoleMappings table

This table implements the association between the roles that comes from the authentication system -mappings- and the roles in the authorization system.

Column Description
RoleId Role identifier
MappingId Mapping identifier

Permissions types

A resource is the element which access want to be secured, e.g. an entity, an asset, a provider, a Data Storage Unit (DSU)... There are three permissions types -read, write and delete- that can be applied to the metadata of the resource or to the data of the resource:

  • Permissions applied to the metadata means that the subject will be able to read, write -including create new data and modifying existing one- and delete from the table of the resource, i.e. a subject with the "Write" permission over a specific provider metadata will be able to modify the row of the provider in the DataIngestion.Provider table in Core database.

  • Permissions applied to the data means that the subject will be able to read, write and delete the information stored in the DSU about the resource, i.e. a subject with the "Read" permission over a specific entity will be able to query the DSU and retrieve the information stored about that specific entity.

IdentityAccess table

This table stores the access that a subject has over the different resources.

Column Description
Id IdentityAccess identifier
IdSubject Identifier of the subject
MetadataAccessLevel Access level to the metadata of the selected element type -DSU, entity, provider-. A sample of value would be ReadWriteDelete
DataAccessLevel Access level to the data of the selected element type -DSU, entity, provider-. A sample of value would be ReadWriteDelete
SecurityPath Path of identifiers of the selected element to be authorized. The path follows the Metadata hierarchy model, e.g. 1/10/100 represents the entity with Id 100 that is associated with the provider with Id 10 that belongs to the DSU with Id 1
Filter JSON structure containing a list of pairs -attribute and values- used for filtering. The values property is also list
IdDataStorageUnit Computed value. Identifier of the selected Data Storage Unit to which the access levels will be applied based on the value of the SecurityPath
IdEntity Computed value. Identifier of the selected Entity to which the access levels will be applied based on the value of the SecurityPath
IdProvider Computed value. Identifier of the selected Provider to which the access levels will be applied based on the value of the SecurityPath

A sample of value for the Filter column:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
"filter": [​
  {​
    "attribute": "country",​
    "values": ["Ireland", "Spain"]​
  },​
  {​
    "attribute": "department",​
    "values": ["marketing", "finances"]​
  }
]​

The previous Filter sample means that the subject has access only to those entities that have the value of the attribute country equals to Ireland or Spain and the value of the attribute department equals to marketing or finances.

The access level can have the following values:

AccessLevel Definition
None No access
Read Subject can only read
ReadWrite Subject can Read, Insert and Update
ReadWriteDelete Subject can Read, Insert, Update and Delete

The authorization is based on SecurityPath which is a path of identifiers separated by /. The order of the identifiers in the path follows the Metadata model hierarchy: 

1
{Data Storage Unit (DSU) Id}/{Provider Id}/{Entity Id}

For example, the SecurityPath 1/10/100 identifies an entity with Id 100 which belongs to a provider with Id 10 that is contained in a DSU with Id 1.

Access resolution for data and metadata

The access that a subject has over a resource -an entity, a provider or a Data Storage Unit (DSU)- will depend on the access type that the subject has on the resource and the access level. The access type is calculated by comparing two SecurityPath:

  • On the one hand, the SecurityPath of the resource that want to be accessed. The DataLake, Provider and Entity tables contains a SecurityPath field.
  • On the other hand, the list of SecurityPath from the accesses granted to the subject. Those accesses are stored in the IdentityAccess table which also contains a SecurityPath field.

Depending on the comparison of those two SecurityPath, there are three types of access:

  • Explicit access

    The SecurityPath of the resource is the same that the one in the IdentityAccess table. That means that the access to the resource has explicitly granted.

  • Inherited access

    The SecurityPath of the resource is more specific that the one in the IdentityAccess table. For example an Entity has the value 1/10/100 in its SecurityPath and the IdentityAccess table contains a row with the value 1/10 in its SecurityPath. The subject does not have explicit access to the entity but it has explicit access to the provider to which the entity belongs. In this case, the subject has inherited access to the entity.

  • Implicit access

    The SecurityPath of the resource is more generic that the one in the IdentityAccess table. For example a Provider has the value 1/10 in its SecurityPath and the IdentityAccess table contains access with the value 1/10/100 in its SecurityPath. The subject does not have explicit access to the provider but it has explicit access to one of the entities associated to that provider. In this case, the subject has implicit access to the provider.

It can happen that for the same resource, there are more than one type of access. In that case the more explicit access prevails: Explicit > Inherited > Implicit.

Once the access type has been determined. The permissions of the subject over the resource will be:

Access Type Metadata access Data access
Explicit The value of the MetadataAccessLevel The value of DataAccessLevel
Inherit The value of the MetadataAccessLevel The value of DataAccessLevel
Implicit Read Read