Skip to main content

Overview

In Sedaro, teams can create Workspaces which house information related to individual & group membership, permission management, and the team's Projects.

A Project in Sedaro provides a logical way of organizing Content. Content is comprised of Ontologies, Simulators, Artifacts, Workflows, and Interfaces. Projects allow for the configuration of role-based access control for individuals and groups, enabling safe and traceable team collaboration on a specific scope of work.

Access Control​

Sedaro offers medium-fidelity access control, granting flexibility for teams while reducing complexity and preserving high-performance. Sedaro's architecture is built on Zero Trust principles, with authorization as a first-class feature.

Workspaces, Members, and Owners​

All resources in Sedaro live within your Workspace. Only Projects own entities (i.e. "Content") within a Workspace. Individuals do not own any Content.

Workspaces contain members, and one or more members are Workspace Owners. Owners are the super-users of a Workspace; they can invite more members, manage group membership, assign top-level roles, and view/modify all Content. Owners are also the legal and financial points of contact for a Workspace.

warning

Since Owners can view/modify all Content in a Workspace, assign your Owners with care.

Members can be organized by custom Groups, and each member can be in zero or more Groups. Only Owners can create, manage, and delete Groups.

tip

The primary utility of Groups is to simplify access control. When granting broad access, it is tedious to assign individual roles to individual people. By assigning N people to a Group, you can turn N role assignments into one. Learn more about roles below.

Typically, identities granted direct access to a Project who are not a member of the Workspace are considered "outside" contributors. Outside contributors are not supported in Sedaro. As a result, users may audit all members of a Workspace and guarantee that only those individuals have access to the entities within the Workspace's Projects.

Projects and Folders​

Projects are access-controlled containers of resource. Within a Project is its own Folder system, and all Content is tied to a Folder or its Project. Projects may not be nested – use Folders for organization and filtering.

Access control in Sedaro occurs at the granularity of Projects; each Project has its own access control configuration, and all resources within a Project share the same configuration. Use Projects to define meaningful scopes of work that can be cleanly and securely shared as a whole.

To grant access, assign your Workspace members a Role on the desired Project. An individual user or a whole Group can be assigned a Role. This Role applies exclusively to the Project and all its contents, and it has no impact on Workpsace permissions or other Projects. By default, each Workspace member has no permissions at all. See below for a description of the available roles.

To ease the burden of configuring access control, Workspace members and Groups can be assigned Global Roles. A Global Role is a Role assignment that sets base permissions for all Projects in the workspace. For example, a user can be given the Read Global Role to ensure they can view everything in the workspace at a minimum.

warning

If a user is granted a Role from multiple sources (Direct Role, Global Role, and/or inherited from a Group's Direct and Global Roles), they always assume their most capable permissions; in other words, permissions are calculated by taking the union of all applicable Roles.

If given a Global Role in a workspace, a user's permissions cannot be downgraded on a per-project basis. Apply the Principle of Least Privilege in your assignments.

Roles​

Sedaro exposes the following set of Roles. They can be assigned both directly (on a per-Project basis) or globally (for all Projects in the Workspace). They can be assigned to individual Workspace members or to all members of a Group.

info

Roles strictly define access to Projects. They do not impact a user's Workspace permissions. Administrative privileges on the Workspace are exclusive to Owners.

Assigning an Admin globally means they're an Admin on all Projects, but doesn't give them any permissions on the Workspace.

  • Admin:
    • Permits assignment of Roles to others for the respective Project (i.e. a Direct Role Assignment)
    • Permits RWX permissions on all Content within the respective Project
  • Read (R):
    • Permits reading all Content within the Project
  • Read/Write (RW):
    • Permits reading and writing all Content within the Project
  • Read/Execute (RX):
    • Permits reading and executing all Content within the Project
  • Read/Write/Execute (RWX):
    • Permits reading, writing, and executing all Content within the Project

For each action, permissions are computed as follows. If no applicable Role is found by the end, authorization against that action fails.

  • Determine the resource's Project and by association its Workspace.
  • If the user is an Owner of the Workspace, they have all permissions.
  • Add all permissions granted to the public globally on the Workspace.
  • Add all permissions granted to the user globally on the Workspace.
  • Add all permissions granted to any of the user's Groups globally on the Workspace.
  • Add all permissions granted to the public directly on the Project.
  • Add all permissions granted to the user directly on the Project.
  • Add all permissions granted to any of the user's Groups directly on the Project.

Public Access​

Workspace resources can optionally be made public. A built-in Public Identity exists which may be granted Roles to a Project. The Public Identity is any unauthenticated request to the Platform. Any "authenticated" requests also inherit permissions from the Public Identity.

Role assignments for the Public work identically to those for your workspace members; you can assign Roles directly on a Project or globally for all Projects in a Workspace. Global Roles cannot be downgraded on a per-Project basis.

tip

Public access is only possible in Workspaces that are "public-capable". Owners can toggle their Workspace public-capable or -incapable at any time. This is a safety hatch: toggling it capable does not automatically make any Projects public, but toggling it incapable immediately revokes all public access.

In Sedaro environments which support the US Government, Workspaces cannot be made public-capable.

If neither a Direct Role assignment nor a Global Role grant permissions — for the individual's identity, any of their Groups, or the Public Identity — authorization against that action fails.

Workflows and Project Integrations​

Ideally when a Workflows execute, they produce deterministic, consistent results, regardless of who initiates the Workflow. Sedaro facilitates this by assigning workflows a "Project Identity". When a Workflow runs "as its Project", it has all permissions to the Content in the Project – and no permissions outside that.

note

Since the Workflow runs as its Project, it can't even view the profile of the user that launched it. All it can do is read, write, and execute the Content in its Project.

This ensures consistent Workflow permissions and outputs, regardless of which User runs the Workflow, assuming the User has the necessary permissions to execute the Workflow in the first place. It also allows for non-User originated Workflow triggers (e.g. Scheduled Workflows, Chained Workflows).

To extend a Workflow's capabilities beyond its own Project, a Project can be granted an "Integration" to another Workspace and therefore can be assigned Roles to Projects within that Workspace. When a Workflow's Project is integrated to another Project, that Project becomes accessible at runtime.

Owners must establish the Integration into their Workspace before a Role can be assigned. This is similar to inviting users as Workspace members before assigning them Roles to actual Projects.

tip

Note that Projects within the same Workspace are implicit Integrations of that Workspace such that explicit Integrations are not required in order to assign a Project access to another Project within the same Workspace.

Similar to users, Projects inherit permissions from the Public Identity where configured, allowing their Workflows to access Content in any public Project.

Best Practices​

Scoping a Project​

When deciding how to segment an objective into one or more Projects, aim to draw a Project boundary that has:

  1. similar access control requirements for the contained Content
  2. a specific and easy to document purpose, and
  3. straightforward and intuitive interfaces to interoperable systems, including other Sedaro Projects

Project Hygiene​

A Project should always:

  1. perform some work (analyses, automations, etc) that provides an insight or answers a question and
  2. produce Artifacts that are consumable by end-users or other Projects

The team responsible for a Project in Sedaro should be careful not to only focus on (1). Instead, the responsible team should manage and work to guarantee the stability and integrity of their output Artifacts such that other teams can consume them risk-free. This involved managing Workflow execution schedules, configuring and monitoring Artifact and Interface health checks, and authoring unit and Artifact integrity tests.