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)