Goals

  • Multi-user concept for StreamPipes
  • State-of-the-art authentication system, including support for third-party authorization servers (OAuth2)
  • Fine-grained permission management for users and resources

Core Concepts

  • Privilege (e.g., READ_PIPELINE)
  • Roles (e.g., PIPELINE_ADMIN, with CRUD privileges for pipelines)
  • Users  (a concrete user)
  • Groups (a group with zero or more users and assigned roles)

Core Resources in StreamPipes relevant for managing privileges

  • Adapter
  • Data Stream/Data Set
  • Data Processor
  • Data Sink
  • Pipeline
  • Data Explorer Dashboard
  • Live Dashboard
  • App


Authorization approaches

  • I see three general ways:
    • Role-based Access Control (RBAC)
    • Attribute-based Access Control (ABAC)
    • Workspace-based Access Control (WBAC)

RBAC

Role-based access control is the most simple concept - users can have one or more of pre-defined roles which have fixed privileges.

Examples for roles:

  • Admin
  • Pipeline Admin (has full privileges for managing pipelines)
  • Dashboard Admin (has full privileges for managing dashboards)
  • Dashboard User (can view dashboards)

With RBAC, example policies that are possible included:

  • An admin can do everything
  • A dashboard admin can create new dashboards
  • A pipeline user can read data streams, processors and sinks
  • A pipeline user can view pipelines
  • A pipeline admin can start pipelines

Pros:

  • rather easy to implement

Cons:

  • Resources are globally available and no fine-grained permissions on resource level are possible (e.g., a user can only see specific pipelines).


ABAC

ABAC is the most advanced concepts - privileges can be assigned for each resource individually.

Examples for roles

  • Admin 
  • Resource Owner (can change privileges for a resource)

With ABAC, example policies include:

  • A resource owner can share a pipeline with another user or another user group
  • A pipeline can be viewed by user X, but not by user Y
  • All users in group Y can create dashboard

Pros:

  • powerful

Cons:

  • rather hard to implement
  • performance (all resources must be filtered for permissions)
  • from a user point of view, rather hard to configure, as permissions neet to be set individually


WBAC

We introduce a new concept "workspace" in StreamPipes. A workspace consists of a set of users and resources. Within a workspace, resources can be created and viewed. For instance, a workspace has a set of adapters, data streams, processors and pipelines. All users in a workspace have a role that manages the permissions per workspace.

Examples for roles

  • Admin
  • Workspace Owner (can manage workspace users)
  • Workspace User
    • Pipeline Admin
    • Pipeline User
    • Dashboard User
    • ...

With WBAC, example policies include:

  • A workspace user with role "Pipeline user"  can read all pipelines in a workspace
  • A workspace user with role "Dashboard Admin" can read and create dashboards.
  • A workspace owner can add new users to a workspace and assign roles


Pros:

  • workspaces are a good fit for managing "projects" in StreamPipes
  • more powerful than RBAC, less complicated from a users point of view than ABAC

Cons:

  • Not so easy to share resources across workspaces (e.g., an adapter should be managed globally but available to multiple workspaces to avoid redundancy)


  • No labels