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
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.
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.