Skip to content

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 Offer and Data Offer 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 Offer.
  • 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 Offer out of "DataPort1" (if he has additional WRITE privilege to create a new Data Offer).
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)