Authorization¶

Introduction¶

Authorization has to be performed for any Authorization Subject with any Action toward Object, or in SDM context a Resource. To be able to decide for an Authorization (Authorization Decision), Authorization Policies has to be stated.

Term	Description
Subject	A user or system on behalf of a user
Action	performing an action (Authorization Privilege)
Resource	Every core entity is a resource. This includes Data Product and Data Product State, Data Subscription and Data SubscriptionState, Transport, ...
Authorization Policy	Rules for Authorization Decision.

There are 6 different cases where Authorization has to be defined:

CRUD (Resource Authorization): create, read, update and delete of a resource (excluding updating a reference to another resource).
Link (X-Resource Authorization): link another resource to a resource, e.g. create a Data Subscription to a Data Product.
Limited Read (Back Reference Authorization): Get information about a referenced resource.
Set Access Rights: define the privileges.
Context based Access Control (X-Resource Authorization II): taking attributes of the resource and referenced resources into account for any authorization case above.
Content (Resource Content Authorization): read data FROM a resource or write data TO a resource if the resource is able to transfer data (e.g. read samples of a DataPort)

Action/Privileges¶

Authorization Privileges have a hierarchy and inherit all privileges from the previous privilege level (bottom to top). Privileges are additive. When a subject Authorization Subject has multiple different Authorization Privileges the full combinations of permissions. For example, a user that is granted WRITE and READ from different sources his effective Privileges will be WRITE

Privilege	Description	Authorization Case	Example
ADMIN	Admin access to resource, managing permissions	Set Access Rights	User "admin" with privilege "ADMIN" gives user "b" privilege WRITE to resource "r1"
WRITE	Write access to resource	CRUD	User "user1" has WRITE privileges for resource "r2" and can therefore change its description
LINK	Referencing this resource. It's a special privilege which takes a source and destination resource into account	Link	User "user1" has LINK privilege for resource "DataPort1" and is therefore able to create a new Data Product out of "DataPort1" (if he has additional WRITE privilege to create a new Data Product).
READ	Read access to ALL attributes of a resource	CRUD	User "user1" has READ privilege on resource "dataSubscription1" and therefore the resource appears in any search or list and additionally the user has read access to all attributes of the resource.
READ_INFO	Read access to a subset of resource attributes	Limited Read	User "user" has READ_INFO privilege on a resource "dataOffer1" and is able to see minimal information about this resource.
none	No access granted to resource.		No access to resource.

Not supported yet:

Content (Resource Content Authorization)

Resource Grouping¶

All resources are matched against a Resource Path. Depending on the specific resource this path is stored either on the resource itself or on a referenced resource group. Resource Groups are a place to group resources together for defining defaults, permissions and accounting.

There are some important factors to consider when defining a resource group:

each resource has to be in one resource group (distinct groups)
a resource group is a resource itself and thus can be in other resource groups
a resource group is used to define the Resource Path of a resource.
a resource can be moved from one resource group to another resource group at any time. All restrictions of the new resource group apply immediately after moving (Resource Path gets updated).
all resource groups will form a directed graph without cycles.
a resource group that has no parent is automatically assigned to the root path / without actually having a resource group assigned.

Resource Type¶

Additionally to the Resource Path all resources belong to one Resource Type. Those types contain groupings to enable better handling of Resource Types.

Resource Match¶

To be able to decide which Resources are affected by an Authorization Policy, Resources can be matched by their Resource Path and Resource Type.

Resource matches are always inherited. Meaning that any resource that is located in a Resource Path it will inherit the closest definition.

Not supported yet:

Context based Access Control (X-Resource Authorization II)

Example¶

Permissions Definition¶

path	type	subject	privilege
`/`	`ALL`	`root`	ADMIN
`/org1/`	`ALL`	`/org1-users`	WRITE
`/org1/hr/`	`ALL`	`/org1-users`	NONE
`/org1/hr/`	`ALL`	`/org1-hr-users`	WRITE
`/org1/ops/`	`DataProfile`, `DataSchema`	`/org1-users`	NONE

Subjects¶

username	groups
`root`
`jaydan`	`/org1-users`
`brenna`	`/org1-users`, `/org1-hr-users`

Effective privileges for different users and paths¶

subject	path	type	privilege
`root`	any	any	ADMIN
`jaydan`	`/org1/it/`	any	WRITE
`jaydan`	`/org1/hr/`	any	NONE
`jaydan`	`/org2/`	any	NONE
`brenna`	`/org1/ops/`	`DataOffer`	WRITE
`brenna`	`/org1/ops/`	`DataProfile`	NONE
`brenna`	`/org1/ops/`	`DataSchema`	NONE
`brenna`	`/org1/it/`	any	WRITE
`brenna`	`/org1/hr/`	any	WRITE
`brenna`	`/org2/`	any	NONE

GraphQL API¶

Querying permissions in the GraphQL API is as simple as:

query {
  permissions {
    nodes {
      subjectId
      path
      privileges
    }
  }
}

The result according to the example above looks like the following snippet:

{
  "data": {
    "permissions": {
      "nodes": [
        {
          "subjectId": "root",
          "path": "/",
          "privileges": [
            "ADMIN",
            "READ",
            "WRITE",
            "READ_INFO",
            "LINK",
            "NONE"
          ]
        },
        {
          "subjectId": "/org1-users",
          "path": "/org1/",
          "privileges": [
            "READ",
            "WRITE",
            "READ_INFO",
            "LINK",
            "NONE"
          ]
        },
        {
          "subjectId": "/org1-users",
          "path": "/org1/hr/",
          "privileges": [
            "NONE"
          ]
        },
        {
          "subjectId": "/org1-hr-users",
          "path": "/org1/hr/",
          "privileges": [
            "READ",
            "WRITE",
            "READ_INFO",
            "LINK",
            "NONE"
          ]
        }
      ]
    }
  }
}

Please be aware, that responses in general (including the permission API) are always trimmed to entries the requestor has the requested permission level access to. By default the requested permission level is READ.

To change permissions, do a mutation accordingly, e.g.:

mutation {
  savePermission(
    input: { 
      path: "/org/sub-path", 
      subjectId: "user-x", 
      privileges: [READ] 
    }
  ) {
    subjectId
    path
    privileges
  }
}

Of course you need to have at least WRITE permission towards the path.

Moving Resources around¶

Authorization Subject privileges needed to move resources from one resource group (the source) to another (the destination):

WRITE privilege on the source Resource Path (otherwise it's not possible to change the ref).
WRITE privilege on the destination Resource Path (otherwise it's not possible to change the ref)