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
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
|Name||Name of the application|
|Description||Description of the application|
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.
|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|
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.
|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:
This table implements the association between Roles and Subjects.
A permission is the ability to perform some specific operation. This table represents the permissions defined in Sidra.
|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:
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.
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.
|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|
This table represents roles coming from authentication system so they can be mapped to the application roles.
|Name||Name of the mapping|
This table implements the association between the roles that comes from the authentication system -mappings- and the roles in the authorization system.
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.Providertable 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.
This table stores the access that a subject has over the different resources.
|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
|IdEntity||Computed value. Identifier of the selected Entity to which the access levels will be applied based on the value of the
|IdProvider||Computed value. Identifier of the selected Provider to which the access levels will be applied based on the value of the
A sample of value for the
1 2 3 4 5 6 7 8 9 10
Filter sample means that the subject has access only to those entities that have the value of the attribute
country equals to
Spain and the value of the attribute
department equals to
The access level can have the following values:
|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:
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
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
- On the one hand, the
SecurityPathof the resource that want to be accessed. The
Entitytables contains a
- On the other hand, the list of
SecurityPathfrom the accesses granted to the subject. Those accesses are stored in the
IdentityAccesstable which also contains a
Depending on the comparison of those two
SecurityPath, there are three types of access:
SecurityPathof the resource is the same that the one in the
IdentityAccesstable. That means that the access to the resource has explicitly granted.
SecurityPathof the resource is more specific that the one in the
IdentityAccesstable. For example an
Entityhas the value
IdentityAccesstable contains a row with the value
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.
SecurityPathof the resource is more generic that the one in the
IdentityAccesstable. For example a
Providerhas the value
IdentityAccesstable contains access with the value
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. Only read permission is granted implicitely.