Skip to content

Authorization Service

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

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.

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 DataStorageUnit, 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. Only read permission is granted implicitely.