Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.siftstack.com/llms.txt

Use this file to discover all available pages before exploring further.

Sift access control uses two strategies: Role-Based Access Control (RBAC) and Data Access Governance (DAG). RBAC is the default system. DAG is an attribute-based access control (ABAC) implementation that provides more granular control.

​
RBAC vs DAG

The following table compares RBAC and DAG to help you determine which model fits your organization’s needs:
When to use DAG: Not all organizations need DAG. RBAC is often easier to configure and manage. DAG is not a one-size-fits-all solution. Most organizations will find RBAC sufficient and easier to manage.

​
Role-Based Access Control (RBAC)

Role-based access control (RBAC) is the default access control system in Sift. RBAC uses predefined roles and groups to manage user permissions across resources. RBAC sets the maximum permissions a user can have. DAG can only further restrict access within that boundary.

​
Roles

RBAC uses four predefined roles that determine the level of access granted to users:
  • Admin: Full access to data, configuration settings, and user management. Admins can create and modify groups, manage users, and configure system settings.
  • Editor: Can view, edit, and write time series data and metadata. Editors have full data access but cannot manage users or system configuration.
  • Collaborator: Can view time series data and add metadata. Collaborators can annotate and tag data but cannot modify the underlying time series data.
  • View-only: Read-only access to time series data. View-only users can explore and analyze data but cannot make any changes.
Custom roles: Custom roles in RBAC are not supported at this time. All organizations use these four predefined roles. For custom defined roles an organization needs to use ABAC.

​
Role permissions

The following table shows which permissions are available for each role. An * indicates that the role has that permission:

​
Groups

Groups are collections of users that share the same role and Asset access permissions. Groups simplify access management by allowing administrators to assign permissions to multiple users at once. Key characteristics of groups:
  • Role assignment: Each group is assigned one of the four predefined roles (Admin, Editor, Collaborator, or View-only).
  • User membership: Users can belong to one or more groups, inheriting permissions from all groups they belong to.
  • Default groups: Internal users (those with email addresses matching the organization’s domain) are automatically added to a default group during sign-up. External users are assigned to a specified group during invitation.

​
Asset access

Asset access determines which resources (Runs, Channels, Reports, etc.) a group can access. Groups can be configured with:
  • All assets: Access to all resources in the organization.
  • Specific assets: Access restricted to a defined subset of Assets.
This allows administrators to create groups with the same role but different data access. For example, you might have an “Engine Team - Editors” group with Editor role and access to Engine Assets, and a “Propulsion Team - Editors” group with Editor role and access to Propulsion Assets.

​
How permissions work

Permissions in RBAC are determined by a user’s group memberships:
  1. Group role: Each group has a role that defines what actions its members can perform.
  2. Asset access: Each group has access to either all Assets or a specific subset of Assets.
  3. Combined permissions: When a user belongs to multiple groups, they inherit the union of permissions from all groups. For example, if a user belongs to a group with Editor role and access to Engine Assets, and another group with Collaborator role and access to Propulsion Assets, they will have Editor permissions on Engine Assets and Collaborator permissions on Propulsion Assets.

​
Data Access Governance (DAG)

DAG controls access using attributes assigned to users and resources. While RBAC uses fixed roles to set the boundary of what a user can do, DAG evaluates attribute-based policies to further restrict access within that boundary.
How RBAC and DAG work together: DAG does not replace RBAC. RBAC sets the maximum permissions a user can have. DAG can only further restrict access within that boundary. A DAG policy cannot grant permissions that the user’s RBAC role forbids.

​
User attributes

User attributes are key-value pairs that describe who a user is. You can assign attributes directly in Sift or sync them from an Identity Provider (IdP).

​
Resource attributes

Resource attributes are key-value pairs that describe Sift resources. DAG uses them alongside user attributes to evaluate policies.

​
Supported resource types

You can assign attributes to the following resource types:
  • Assets
  • Channels
  • Runs

​
Access inheritance

DAG enforces access inheritance between related resources:
  • Channels inherit from their parent Asset. If a user is denied an action on an Asset, the same action is denied on all of that Asset’s Channels, even if a separate policy allows it on the Channel. The Asset-level decision always wins.
  • Runs check Asset access only for viewData. To view telemetry data on a Run, the user must have viewData access to at least one of the Run’s associated Assets. If all associated Assets deny viewData, the Run is denied too. Other actions on Runs (such as editDetails or archive) are evaluated on the Run alone.

​
Attribute data types

The following table describes the supported data types for attributes:
Best practice: Use Enum instead of Boolean for statuses like employment type. It is easier to add a third value (for example, “Part-Time”) to an Enum than to restructure Boolean logic later.

​
Attribute key uniqueness

Attribute key names must be unique across your organization. You cannot create two attributes with the same name, even if they have different data types.

​
Policies

Policies define the logic that governs access.

​
Evaluation model

Sift evaluates access in two layers: DAG uses a default-deny model. For a user to access a DAG-controlled resource, there must be at least one allow policy that matches. If no policy matches, access is denied.
Initial setup: When DAG is first enabled for an organization, a blanket allow policy is typically configured so that existing access is preserved. Specific deny policies are then added to restrict sensitive resources. Without a blanket allow, all non-admin users lose access to DAG-controlled resources.

​
Precedence

When multiple policies match, Sift resolves them using strict precedence:

​
Actions

Every policy must define which actions are allowed or denied. The viewDetails action serves as a prerequisite for all other operations. If a user cannot viewDetails on a resource, all other actions on that resource are automatically denied. The following table lists all available actions:

​
Policy settings

The following table describes the settings available when creating or editing a policy:

​
Operators by attribute data type

The following table lists the available operators for each attribute data type:
User group operators: When the attribute type is User group, only Enum Set operators are available (Contains, Contains All, Contains Any, Intersects With, Is Empty). The Intersects With operator compares a user group’s attribute against a resource attribute, enabling dual-match conditions without specifying fixed values.

​
Admin bypass

By default, users with the Admin RBAC role bypass DAG policy evaluation entirely. Admin access is governed solely by RBAC.

​
Best practices

​
Plan your policy

Define the scope before configuring anything.
  • Subject: Who is affected (internal staff, contractors, systems)?
  • Object: Which resources are being protected?
  • Action: Should the policy allow or deny access?

​
Organize with groups

Apply policies to user groups, not individual accounts. Create dedicated groups for specific needs (for example, a Vendor-Access-Group). This simplifies auditing because you can remove a user from the group instead of updating multiple policies.

​
Choose the right attribute type

​
Use dual-match conditions

Require matching attributes on both the user and the resource. For example, to restrict access to Artemis Mission assets, create an intersect policy with two conditions:
  1. User has Mission = Artemis
  2. Resource has Mission = Artemis
Access is granted only when both conditions are satisfied.

​
Naming conventions

  • PascalCase: EmploymentStatus, ClearanceLevel
  • Subject-property pattern: UserDepartment, ResourceProject
  • Boolean prefixes: IsActive, HasMFA
  • Avoid redundancy: Use ClearanceLevel, not ClearanceLevelInteger

​
FAQs

​
What happens if I don’t assign attributes to a resource?

If no DAG policies target a resource, access depends on your policy configuration. With a blanket allow policy in place, the resource is accessible to anyone whose RBAC role allows it. Without a blanket allow, unmatched resources are denied by default.

​
Can I restrict access to specific Channels?

Yes. You can assign resource attributes to individual Channels and Runs, not just Assets. For example, you can allow a user to see an Asset but deny access to a specific sensitive Channel within that Asset. Note that the reverse also applies: if access to an Asset is denied, all Channels belonging to that Asset are also denied.

​
What happens if a user matches multiple policies?

Sift prioritizes security: if any matching deny policy denies access, access is denied immediately, regardless of any allow policies. Access is only granted when at least one allow matches and no deny applies.

​
Behavior

The following table describes known constraints and behaviors to be aware of when working with authorization models in Sift: