Mapping Institutional Roles to tiCrypt
- tiCrypt has no built-in "PI" or "Lab Manager" role. You compose the right access from three independent layers: system role, user profile, and VM role
- System role controls visibility, user profile controls actions, VM role controls data access. These three layers operate independently
- Start from the persona mapping table to find the configuration for each person in your group
- Use the wizard below for a quick 2-click recommendation
Your institution already has a role structure: Principal Investigators, Lab Managers, Graduate Researchers, Data Custodians, and IT staff, each with its own set of expectations and responsibilities. tiCrypt does not have a matching "PI role" or "Lab Manager role" anywhere in its interface. Instead, what a person can actually do in tiCrypt is the product of three independent layers: their system role, their user profile, and, inside any given virtual machine, their VM role.
A PI might hold the ordinary "User" system role while being the Owner of every VM their lab depends on. An IT administrator might hold the "Admin" system role, with broad authority to manage infrastructure, and yet have zero access to any VM's data. tiCrypt enforces separation of duties by design: administrative power and data access remain separate.
This page shows you how to compose these layers to reproduce the institutional personas you already manage, so that each person gets exactly the access their role requires and nothing more.
The Three Permission Layers
Before mapping any institutional role, understand that these layers are independent of each other. A person's configuration in one layer tells you nothing about their configuration in another.
- System Role (Site Key Admin, Escrow User, Super-Admin, Admin, Sub-Admin, User): determines visibility (which users and objects you can see) and who you can manage. It does not determine what actions you can take. Full details are on the User Roles page.
- User Profile: the named, admin-defined bundle of granular permissions that actually determines what actions a person can take in the tiCrypt web interface, things like managing project memberships, sharing drives, or viewing audit logs. Every user is assigned a profile. See User Profiles.
- VM Role (Owner, Co-Owner, Manager, User): a completely independent hierarchy that exists only inside a single virtual machine. It is determined by who started the VM and who that Owner has explicitly granted access to, not by anyone's system role. See VM Roles and Permissions.
Two more dimensions round out the picture, and both come up repeatedly in the persona mapping below:
- Team membership determines resource quotas (CPU, memory, storage) and whether a user account is active at all. A user removed from every team is deactivated.
- Project membership and certification determine access to project-tagged resources. Certification verifies that a user meets the security requirements attached to a project before they can touch its restricted resources.
A person's actions are shaped by four independent inputs: System Role, User Profile, VM Role, and Team plus Project membership. System Role's contribution is limited: it controls which tabs and sections are visible, and only Super-Admin bypasses all permission checks and unlocks system-wide functions (deployment settings, services, licensing) that no profile can grant to other roles. For every other role, it is your User Profile that unlocks capabilities, while VM Role governs data access and Team plus Project membership governs quotas and certification. A high system role with a minimal profile has limited capabilities; a "User" with a well-built profile can manage projects, share drives, and perform most day-to-day operations.
Find Your Configuration in 2 Clicks
Not sure which system role and profile to assign? Select the persona below and the wizard will recommend a starting configuration.
Institutional Persona Mapping Table
Use this table as a starting point for translating the roles your institution already recognizes into tiCrypt configuration. Treat it as a template, not a mandate. Every institution's governance model is different, and you should adjust profiles and scopes to match your own policies.
| Institutional Role | Typical Responsibilities | tiCrypt System Role | Recommended User Profile Permissions | Typical VM Role | Setup Actions |
|---|---|---|---|---|---|
| Principal Investigator (PI) | Oversees research direction, manages lab personnel, accountable for data compliance | User, or Sub-Admin if delegated management is needed | Project Management permissions (manage memberships, certify users) | Owner or Co-Owner on shared VMs | Set as PI on the Project. If Sub-Admin, assign Managed Objects scoped to their team and project |
| Lab Manager / Research Coordinator | Handles day-to-day operations, manages access for lab members | Sub-Admin | Project Management + Team Management permissions | Co-Owner or Manager on shared VMs | Assign as Sub-Admin with Managed Objects covering the team and its projects |
| Research Staff / Postdoc | Conducts analysis, creates and runs VMs, manages own data | User | Basic Vault permissions + Basic VM Interaction + Project Interaction | Owner on their own VMs, User on shared VMs | Add to team and project, certify per User Certifications |
| Graduate Researcher | Uses VMs for analysis, limited administrative needs | User | Basic Vault + Basic VM Interaction, often restricted (no download, no drive sharing) | User on shared VMs | Add to team and project with restrictions, certify as required |
| Data Custodian | Manages sensitive data intake and distribution across the lab | User, or Sub-Admin for broader scope | Vault + File Sharing + Group Management + Inbox Management | Owner or Manager on data-staging VMs | Set as the primary contact for ingress data; grant permissions to share with researchers and manage inboxes |
| HPC / System Administrator | Manages infrastructure, builds VM images, configures Slurm | Admin, or Super-Admin for global configuration | Full administrative profile (infrastructure, images, hosts, storage) | None by default | Configure access to VM Images, hardware setups, storage pools, hosts, and Slurm; no path to user data is needed |
| Compliance Officer / Auditor | Reviews audit logs, monitors compliance posture | Admin (narrowly scoped), or a dedicated audit-only profile | Audit query and reporting permissions only | None | Grant Audit query and reporting permissions; no VM or Vault access is needed |
It is tempting to give a Lab Manager or Data Custodian broad Admin access so they "can do everything the lab needs." Resist this. Sub-Admin scoped with Managed Objects, paired with a tightly built User Profile, almost always covers the real need without exposing the rest of the institution's teams and projects.
PI in tiCrypt: A Closer Look
A recurring point of confusion for new administrators is that tiCrypt has no "Principal Investigator" system role. PI is a metadata field on a Project, set when the project is created or edited. It records who is institutionally responsible for that project, nothing more. Setting someone as PI does not, by itself, grant them any permission at all.
A PI's actual capabilities in tiCrypt come entirely from the other layers you assign them:
- Their system role (typically User or Sub-Admin)
- Their user profile (which permissions they hold)
- Their VM roles on any VMs they use or oversee
PI as Sub-Admin
Assign as Sub-Admin scoped to their project and team with Project Management permissions. The PI can add/remove lab members and certify users without full Admin access.
PI as plain User
Keep as User and route all membership changes through a Lab Manager or departmental Sub-Admin. Simpler for PIs who do not want administrative overhead.
Choose the model that matches your institution's actual governance and approval chain, then configure profiles and Managed Objects to match.
Composing a User Profile
User Profiles are built from granular, individually toggled capabilities. The table below describes the most common capabilities in plain language, mapped to the personas most likely to need them.
| Capability | What It Allows | Recommended For |
|---|---|---|
| View and manage own files | Browse, upload, download, share, and delete files in the Vault | All users |
| Create and use VMs | Create VM Configs, start VMs, connect, transfer files | Research Staff, Graduate Researchers, PIs |
| Share drives with others | Share encrypted drives read-only or read-write | Research Staff, Data Custodians |
| Manage project memberships | Add/remove users from projects, certify users, create subprojects | PIs, Lab Managers |
| Administer all projects | View all projects, override membership decisions | Departmental Admins, IT Admins |
| Manage VM infrastructure | Create/edit VM images, hardware setups, hosts, storage pools | HPC / System Administrators |
| View audit logs | Query and report on audit events | Compliance Officers |
Start from one of tiCrypt's built-in profiles that is closest to the persona you need, then clone and adjust it. This reduces the chance of accidentally omitting a permission the persona actually needs, and keeps your custom profiles easy to compare against the defaults later. See User Profiles for the full workflow.
VM Roles Are Independent
VM roles have nothing to do with system roles. Owner, Co-Owner, Manager, and User inside a VM are assigned by the person who started the VM, or granted by that person to others. They are not derived from anyone's Admin, Sub-Admin, or User status in the main system. For the full mechanics of how Owner status is established, how Co-Owners inherit drive access, and how permissions are configured within a running VM, see VM Roles and Permissions.
Onboarding Checklist: Setting Up a New Research Group
When a new PI or research group joins your institution, use this sequence to translate their needs into tiCrypt configuration.
| Step | Action | tiCrypt Feature | Guide |
|---|---|---|---|
| 1 | Create a Team with appropriate resource quotas | Teams | Teams |
| 2 | Create User Profiles for each persona type in the group | User Profiles | User Profiles |
| 3 | Create a Project with the PI set as Principal Investigator | Projects | Projects |
| 4 | Set a Security Level and Security Requirements if compliance obligations apply | Security Levels | Security Levels |
| 5 | Add users to the team and project, and certify them as needed | Memberships | Project Memberships |
| 6 | Assign a Sub-Admin for the PI or Lab Manager, if delegated management is desired | Sub-Admin Managed Objects | Sub-Admin Managed Objects |
| 7 | Prepare VM images with the software the group needs | VM Images | VM Images |
For a broader walkthrough of onboarding new users to tiCrypt, see Onboarding.