Access Control
Access control in Sedaro is fully customizable. Workspace administrators have the power to create custom roles and assign resource-specific permissions for users and roles. Your permission policies can be as coarse- or fine-grained as you like.
Roles
Roles are the primary mechanism for labeling or grouping workspace members. A user can have zero or more roles in a workspace, indicating the labels or "groups" under which the user falls. These roles can align with organizational titles or reflect how they are intended to be used in Sedaro.
Functionally, roles exist to grant permissions within Sedaro. Each role is associated with a set of permissions. If a user is granted a role, they are equivalently granted all permissions associated with that role. If a user is granted multiple roles, they are granted the union of all permissions across all of their roles. These permissions apply to all resources within the associated workspace. In this way, roles define global permissions.
For example, consider a user with the following two roles:
- Model Manager: Can view and edit models
- Simulator: Can run and analyze simulations
This user can view/edit models as well as run/analyze simulations, and this is true for any resource across the workspace (given that no other permission configuration exists – see below).
Role creation is entirely within your control. The roles may have well-defined permissions, or they may have no permission at all (in which case, they are pure labels). The roles may be completely disjoint or highly overlapping. The role names may reflect the permissions they grant, or they may reflect internal organization titles. The choice is yours.
Default Roles
Upon creation, all workspaces contain four default roles, which constitute our recommended baseline. They should suit your needs for many use cases. As with all roles, you may edit or delete these as you see fit.
- Guest: Permissions to view
- Can view, but not edit, repositories and branches
- Can view the progress and results of, but not launch, simulations
- Designer: Permissions to edit
- All Guest permissions
- Can edit repositories and branches
- Can launch/abort simulations
- Can view workspace members and their associated roles
- Administrator: Permissions to share
- All Designer permissions
- Can add and remove workspace members
- Can assign roles to members
- Can manage the workspace’s Sedaro license
- Owner: Legal point of contact
- All Administrator permissions
- Can edit or delete the workspace itself
The Owner role is unique. Because it designates the legal/financial "leaders" of a workspace, this role cannot be edited or deleted. Furthermore, a workspace must always have at least one Owner, or one user with the Owner role.
Permission overrides
Custom, composable roles are well-suited for defining dynamic, secure access control policies. However, roles have limited flexibility; they can grant permissions across an entire workspace, but they cannot control access to individual resources. For this, global permissions must be overridden.
Permission overrides allow you to grant or revoke access to individual resources. They may be defined for a specific user, or they may apply to all the members of a certain role. A permission override, as the name implies, overrides the permissions granted by a user's workspace roles to redefine their access to a particular resource.
For example, consider the following specification for an override:
- User: John Doe
- Resource: Project "Mission X"
- Allow: View/edit models
- Deny: View simulations
In this example, we override the default permissions for the user "John Doe", and we do so specifically for the project "Mission X" as well as the project's descendents – its contained repositories, branches, and simulations. It prescribes the following:
- Regardless of role permissions, John Doe can view/edit models within this project.
- Regardless of role permissions, John Doe cannot view simulations within this project.
- Inherit all other permission configuration from John Doe's workspace roles.
Resource specifics
Permission overrides can be defined on projects, repositories, and branches. This allows for the most flexible, granular configuration, if necessary. In the most extreme case, you could grant a user a permission through a role, revoke it for a project, re-grant it for a repository within that project, and revoke it again for a branch within that repository. Though this may be hard to track (see below), we leave the full might of this capability in your hands.
Many permissions can be configured, both at the role and override level. However, each resource type has an associated permission which configures base "access". Without this permission, the resource is inaccessible, and the other permissions are ineffective. The following lists the "access" permission for each resource type:
- Projects: "View project & repository hierarchy"
- Repositories: "View project & repository hierarchy"
- Branches: "View branch contents"
- Simulations/Studies: View simulation progress and results
Order of operations
To compute a permission check, Sedaro's policy engine performs the following checks in order. To each question, Sedaro asks, "Is there a role/override that configures this permission for the given user/any of the user's roles?" If the result is ALLOW by the end of the computation, the user is authorized. Otherwise, the user is rejected.
- ALLOW based on workspace roles
- DENY based on project overrides for roles
- ALLOW based on project overrides for roles
- DENY based on project overrides for users
- ALLOW based on project overrides for users
- DENY based on repository overrides for roles
- ALLOW based on repository overrides for roles
- DENY based on repository overrides for users
- ALLOW based on repository overrides for users
- DENY based on branch overrides for roles
- ALLOW based on branch overrides for roles
- DENY based on branch overrides for users
- ALLOW based on branch overrides for users
In short, permissions configured on the most specific resource always take precedence over those on its parents.
Recommended usage
Sedaro supports creating highly granular access control policies when needed. However, users must take great care in configuring these permissions, as each additional override can be hard to mentally track. Overly complex policies can cause mistakes, misconfigurations, and security gaps for your data.
Follow this rule of thumb: keep it simple. Use the broadest mechanism possible to fit your solution.
- Utilize workspace roles by default, either the pre-built roles or your own custom roles. These will apply permissions for all resources in the workspace.
- If custom roles don't fit your needs, utilize permission overrides on roles. These will specify permissions on a resource (and its children) for all users with a specified role.
- If role overrides don't fit your needs, only then should you look to permission overrides on users. These will specify permissions on a resource (and its children) for only the specified user.
Example use cases
Although the default roles work well in many cases, some situations require fine-grained access control. The following examples highlight cases where granular tools described above can be helpful.
- An organization brings in a specialized consultant to diagnose the issues for a failing simulation. That member should only have access to that simulation's branch and optionally the agent templates that went into it. Nobody else outside of the organization should gain this access.
- A group can only afford a limited Sedaro license, and so their cloud compute capability is limited. They want to allow all group members to edit repositories and branches, but only a select few should have permission to launch simulations.
- A professor has designed one project for every unit in a university course, and she would like to "unlock" each project one at a time as the course progresses. Students should see the projects that have been unlocked so far.
- An engineering team fully designs a satellite in secret, but they need input from a third party to design the thermal unit. They would like to silo that party's work in a certain branch to keep the rest of satellite's secrets from being revealed to the third party. When the thermal unit is complete, it can be merged back into the secret branch.
- A company has no desire for public sharing of information. They are entirely happy with the default roles provided, but they would like to make it impossible for anyone to make a shareable link.
- A competition is held for designing a high quality mission within certain constraints, and a workspace is created for just the occasion. Initially, all contestants are granted all permissions within their own project, but they have no access at all to others' projects. At contest end, judges are allowed to view all projects. Once the winners are announced, all members of the workspace are allowed to view the projects of the top 3 winners.