Xenia features an extensive permission system that allows for fine-grained access control to Xenia features and customer data.
The Xenia permission system is based on permissions and roles. A permission allows the user to perform a specific action. For example, the models.list permission allows a user to list the models in a project.
Roles are collections of permissions, that can be assigned to users. A role can either apply to an entire project, allowing the user to perform the permissions included in the role anywhere in the project, or only to a specific object, such as a model.
There are many default roles in Xenia that can be assigned to users immediately, but you could also create custom roles. This gives you control over the exact permissions of each user.
There is a set of default roles which the users can use directly. These roles are mostly centered around our core concepts Models , Connectors and Pipelines. These default roles have three levels: Admin, Editor and Viewer.
Overall, the Viewer level is most restrictive, granting the user only rights to .list and .get. For example, the role of Model-Viewer assigned on project level means that a user can see all models in that project, but does not have permission to alter them.
The Editor level grants permissions to .list, .get, .create and .update objects. This allows users to not only see objects, but also create and update them.
The Admin level is the most permissive level and allows the user .list, .get, .create, .update and .delete permissions on either project or object-level.
The Viewer, Editor and Admin-levels are defined for the following objects in Xenia:
- Model (this includes permissions on Model Version, Model environment variables, Model Version environment variables, Model Version files and Model Version requests)
- Connectors (this includes Connectors metrics)
- Pipelines (this includes Pipeline objects, Pipeline objects attachments, Pipeline requests and Pipeline metrics)
- Service users
For an overview of what permissions are defined under a role, click on the role in the Roles tab to see Role details.
You can create custom roles by pressing the New role button in on the roles page. This way you can create roles that suit your needs.
A custom role can also be deleted, however, the role will also be deleted from every user that it is assigned to. This means that the users then lose the permissions that were linked to the role.
To be able to assign roles to a user, one must have the permissions to do so. The permissions to assign roles to other users may be assigned to non-admin users, but not to service users. The permissions to assign roles to users are part of the default Project-Admin role, but may also be part of a custom role. Assigning this custom role to a user, grants the user permissions to assign roles to other users.
Lastly, both custom and default roles may be deleted from users, which makes the user lose the permissions associated to the role.
Updated 12 days ago