Permission — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub
RUEN

Permission

A permission in Versola is a named set of resource endpoints, granted to users through roles and to service apps directly

A permission is a named set of resource endpoints. Roles and service clients use permissions to describe what they may call. Neither lists endpoints directly. For the conceptual picture, see Entities.

Fields

FieldWhat it isRules
Permission IDThe name roles and clients refer toLowercase letters, digits, underscores and hyphens in segments separated by : only, each segment starting with a letter (^[a-z][a-z0-9_-]*(:[a-z][a-z0-9_-]*)*$). orders:read, orders:write:managed and auth-settings:manage are valid. Dots are refused, in the console and by the Central API, wherever a permission ID is created, updated or referenced (in a role or a client). Unique within the tenant. Cannot be changed after creation
English descriptionA label for the permission in the consoleOptional. If you leave it empty, the console stores the permission ID as the description
Resources and endpointsThe endpoints this permission coversPicked from the resources of the same tenant. A permission can span several resources

The form and the Central API set no maximum length for the ID or the description.

Permission IDs use the colon as the separator. Scope IDs contain neither colons nor dots.

The list filters permissions by All, Unlinked and Detached, and by resource: the Resource field is a typeahead, so type part of a host to narrow the choices and pick one. A row shows at most two resources and two endpoints, with +N for the rest; hover it to read them. A permission’s panel lists its endpoints under each resource’s host.

What references what

  • A permission stores the IDs of the endpoints it covers, not their method and path. The endpoint list on the permission page is looked up from the resources.
  • A role lists permission IDs. A client of the service kind lists permission IDs too.
  • In a resource’s endpoints table, the Who may call column shows the permissions that cover each endpoint. Several permissions are alternatives: holding any one of them is enough.

edge uses permissions on two paths:

  • Through a role. A user’s token carries the role IDs, and edge collects the permissions of all those roles in the token’s tenant. A user who holds a role including the permission can call every endpoint it covers.
  • Directly on a client. For the client_credentials grant there is no user, so edge reads the service client’s own permissions. It reads a client’s permissions only for such tokens.

Covering an endpoint is necessary and not sufficient. edge still evaluates the endpoint’s Allow (CEL), step-up and max auth age. See Endpoint policies.

Editing and deleting

You can change the description and add or remove resources and endpoints. The permission ID is not editable.

If an endpoint is later removed from its resource, or the resource is deleted, the permission keeps the stale reference and shows it under Detached endpoints, with a button to remove it.

Deleting a permission removes only the permission record, after a confirmation. Roles and clients keep its ID in their lists, but it no longer covers any endpoint, so it grants nothing. edge applies the change after its next configuration refresh. Tokens that were already issued are affected too, because edge reads permissions at request time.

Next steps