Permissions

Permissions are a declaration of an action that can be executed on a resource. They describe the intrinsic capabilities or operations available on that resource (e.g. read a datastream, or update a station), independent of any specific user.

Permissions granted to a user (also called privileges) can be found in up to three locations in Dendra Release 3.

Location	Description	Resource Domain	Example
Access Token	Permissions granted to a user based on their assigned roles in the IAM. Listed in the permissions claim in the access token.	System (Equipment, Units, Vocabularies)	create:unit update:vocabulary
Resource	Permissions granted to a user based on their assigned role in an organization. Listed in the resource’s effective_rights field.	Organization (Datastreams, Stations)	read:datastream update:station
Header Claim	Permissions granted for service-to-service API calls. Claimed when using a system API key.	Internal services	read:deleted:organization create:job

Note

Permissions to access datasets (metadata or data) are separate from permissions required to act upon a resource. Dataset access is determined by a combination of user’s role in an organization and the resolved access level on a resource. If you cannot view something (like a datastream or station), then you cannot act upon it either. See Access Level for more details.

Organization Resources

Organization resources (resources that belong to an organization) break this down even further to the individual resource level.

Resource	Field	Description	Example
Organization	effective_rights field of the Organization resource.	Statements of what you can do with or within the organization.	create:datastream update:organization
Datastream	effective_rights field of the Datastream resource.	Statements of what you can do with the datastream.	read:datastream update:datastream
Site	effective_rights field of the Site resource.	Statements of what you can do with the site.	read:site:geo.exact update:site
Station	effective_rights field of the Station resource.	Statements of what you can do with the station.	read:station:file.private update:station
Membership	effective_rights field of the Membership resource.	Statements of what you can do with the membership.	read:membership:email update:membership

Organization Role Policies

Based on a user’s role in an organization and the resource they are acting on, a role policy is selected to provide the list of permissions that the user has for that resource.

Below are the current role policies in the system by resource. These are subject to change.

Organization

Role	Permissions
Member	read:file_import_manifest read:integration_config read:organization:file.private
Curator	create:datastream create:file_import_manifest create:integration_config create:site create:station discover:table read:file_import_manifest read:integration_checkpoints read:integration_config read:integration_config:settings read:integration_pipeline read:integration_runtime read:integration_storage_target read:organization:file.private read:table_info update:file_import_manifest update:integration_config update:organization update:table_info
Admin	create:datastream create:file_import_manifest create:integration_config create:membership create:site create:station delete:integration_config delete:organization discover:table read:file_import_manifest read:integration_checkpoints read:integration_config read:integration_config:settings read:integration_pipeline read:integration_runtime read:integration_storage_target read:organization:file.private read:table_info report:integration_runtime restart:integration_runtime retire:integration_config set:organization:feature_flags update:file_import_manifest update:integration_checkpoints update:integration_config update:organization update:table_info

Datastream

Role	Permissions
Member	read:datastream:file.private
Curator	read:datastream:file.private update:datastream
Admin	delete:datastream read:datastream:file.private update:datastream

Site

Role	Permissions
Member	read:site:file.private read:site:geo.exact
Curator	read:site:file.private read:site:geo.exact update:site
Admin	delete:site read:site:file.private read:site:geo.exact update:site

Station

Role	Permissions
Member	read:station:file.private
Curator	read:station:file.private update:station
Admin	delete:station read:station:file.private set:station:feature_flags update:station

Membership

Role	Permissions
Member	None (default policy when acting on another user’s membership)
Curator	read:membership:email read:membership:join_message read:membership:note update:membership update:membership:is_pending update:membership:is_revoked update:membership:note
Admin	delete:membership read:membership:email read:membership:join_message read:membership:note update:membership update:membership:is_pending update:membership:is_revoked update:membership:email update:membership:name update:membership:note update:membership:role

Note

For Membership, the table reflects the default role policies (permissions when acting on another user’s membership). When a user reads their own membership, or when a user has organization-admin privileges, a different effective policy is provided.

System API Key Permissions

Internal services authenticate to one another with system API keys. Each request must explicitly claim the permissions for that call.

Reading soft-deleted records (example)

To facilitate orchestration teardown when a resource is deleted, a system API key can claim the read:deleted:{entity} permission to read a soft-deleted record.

Permission	Get call
read:deleted:organization	GetOrganization
read:deleted:integration_config	GetIntegrationConfig

Resolving Permissions

Permissions are assigned specifically at each level and are mutually exclusive across locations. You can therefore check a single location. If needed, permissions can be resolved in this order:

1. Check the effective_rights field of the resource itself.
2. Check the effective_rights field of the resource’s Organization resource (if applicable).
3. Check the permissions claim in the access token.