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.
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 | Subject´s internal identifier (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 |
CanRead | Read permissions of the element type -DSU, entity, provider-. It's a boolean value, the default value is false. |
CanWrite | Write permissions of the element type -DSU, entity, provider-. It's a boolean value, the default value is false. |
CanDelete | Delete permissions of the element type -DSU, entity, provider-. It's a boolean value, the default value is false. |
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 |
|
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 |
|
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. TheDataLake
,Provider
andEntity
tables contains aSecurityPath
field. - On the other hand, the list of
SecurityPath
from the accesses granted to the subject. Those accesses are stored in theIdentityAccess
table which also contains aSecurityPath
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 theIdentityAccess
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 theIdentityAccess
table. For example anEntity
has the value1/10/100
in itsSecurityPath
and theIdentityAccess
table contains a row with the value1/10
in itsSecurityPath
. 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 theIdentityAccess
table. For example aProvider
has the value1/10
in itsSecurityPath
and theIdentityAccess
table contains access with the value1/10/100
in itsSecurityPath
. 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. Only read permission is granted implicitely.