Role-Based Access for Genomics Projects

Research projects often include principal investigators, laboratory staff, analysts, collaborators, and reviewers. Giving every participant identical permissions increases the chance of accidental changes or inappropriate access.

Role-based access control (RBAC) replaces ad hoc per-person permissions with a smaller set of roles tied to responsibilities. It is useful because a laboratory can reason about what a contributor or reviewer needs to do, then assign people accordingly. It is not useful if everyone becomes an administrator “just in case.”

For genomics projects, access design is part of research governance. Sequence files may carry sensitive or controlled information; results can be changed or deleted; and external collaborators may need access for only one project and one period. A role model should reduce routine risk without obstructing legitimate work.

Start with actions, not job titles

“Principal investigator,” “bioinformatician,” and “student” describe organizational positions, not application permissions. Two PIs may need different access. A data steward may administer membership but not interpret results. A collaborator may need to upload data during collection and become read-only during review.

Build the role model from actions:

Read project metadata, files, samples, analyses, and reports.
Upload source files or create sample metadata.
Start pipelines, trees, or reports.
Correct metadata or record a scientific resolution.
Invite people or change their roles.
Delete records or source objects.
Transfer accountability or close the project.

Define the threat and failure model

RBAC is often discussed as defense against a malicious outsider, but common research failures are more ordinary.

Accidental deletion. A routine contributor mistakes a source file for a duplicate. Restricting deletion more tightly than creation reduces the number of people who can cause irreversible loss, although backup and recovery are still required.

Over-broad collaboration. An external analyst is added to an organization-wide drive when only one project is relevant. Project-scoped membership limits that exposure.

Stale access. A student leaves, a contract ends, or a manuscript review concludes, but access remains. RBAC makes removal manageable; it does not perform the review automatically.

Shared credentials. A team uses one laboratory login because provisioning is slow. Activity cannot be reliably attributed, and revoking one person’s access disrupts everyone. Each person needs an individual identity.

Privilege accumulation. Temporary administrative access becomes permanent. Role assignment needs an owner, reason, effective date, and review date outside or inside the platform.

Compromised account. Correct permissions do not help if an owner’s credentials are stolen. Authentication and incident-response controls must complement authorization.

Bypass through infrastructure. Application RBAC may be irrelevant to a person with direct database, object-storage, backup, or cloud-console access. Infrastructure permissions and service accounts need their own least-privilege design.

Cross-project implementation errors. An API can check that a user is authenticated but forget to constrain a query to projects where that user is a member. Authorization must be enforced on list, detail, create, update, delete, download, and background-task entry points, not only hidden in the user interface.

A practical four-role pattern

Many research workspaces can start with four roles:

Owner: carries project accountability and can perform all project operations, including destructive and membership-sensitive actions. Every project needs a continuity plan so ownership does not depend on one departing person.

Admin: performs operational administration and destructive actions on behalf of the project. This should remain a small group because it combines broad write and delete capability.

Member: carries out normal work such as uploading data, editing records, and starting analyses, but cannot delete project resources. This separation protects against a common class of accidental loss.

Viewer: reads files and results without changing project state. It suits reviewers and collaborators who need evidence but do not need to produce or alter it.

These names are not universal standards. Document their exact permissions. In particular, decide whether “read” includes downloading source files, viewing identifying metadata, and obtaining reports. A read-only role can still expose the full dataset.

Separate authorization from approval

Permission to perform an action is not the same as scientific approval. A member may be allowed to run HaploGrep3, but that does not make the call reviewed. An admin may be allowed to delete a failed run, but policy may require retention until an investigation closes.

Where consequences are significant, add workflow controls around RBAC:

Require a second person to approve deletion or release.
Distinguish draft, reviewed, and approved scientific states.
Record a reason for exceptional access or a manual result resolution.
Use time-limited membership for external collaborators.
Retain evidence of periodic access reviews.

If the application does not implement these workflows, the SOP must say where they occur and how their evidence is retained.

Questions for an access-control SOP

Who may create a project, and who becomes its accountable owner?
Who approves a new member and verifies that the correct identity was invited?
What can each role read, download, create, update, and delete?
Are membership management and data deletion restricted more than routine analysis?
How are temporary access and end dates recorded?
What event triggers immediate removal: departure, contract end, protocol change, or security incident?
How often are memberships reviewed, by whom, and against which source of truth?
How is ownership transferred during leave or departure?
Which service accounts, storage administrators, database operators, and backup staff bypass application roles?
What logs or history can investigators consult after an inappropriate change?
How are restored backups protected from users whose access has since been revoked?

How GeneFlow scopes project access

GeneFlow makes each project an access boundary. A user sees projects and project resources through an explicit membership. Each membership has exactly one role: owner, admin, member, or viewer.

All four roles can use read-only requests. Owners, admins, and members can create and update project resources. Deletion is limited to owners and admins. The same write-role check is used for file uploads and for creation-side operations on project-linked resources such as analyses and reports. Project querysets are filtered through membership rather than relying only on what the interface displays.

Project creation also creates an owner membership, and GeneFlow prevents removal of the last owner. That protects against one form of orphaned project. It does not establish who an institution should appoint as owner, ensure periodic review, or provide time-limited membership.

GeneFlow’s role model should be treated as an application control, not as a claim of complete data governance. Deployment operators remain responsible for identity lifecycle, authentication policy, object-store and database credentials, backup access, network controls, monitoring, and incident response. Selected scientific and project records retain model history, but membership records do not use that same history mechanism; teams needing a durable membership-change record should plan an appropriate logging or governance control.

Implementation checklist

Inventory every operation, including downloads, exports, deletion, and membership changes.
Map each operation to the least-privileged role that needs it.
Give every person an individual account; prohibit shared laboratory credentials.
Keep owner and admin assignments small and documented.
Use viewer access by default for review-only collaboration.
Record approver, purpose, and expected end date for external access.
Review membership at a defined cadence and at project milestones.
Remove or adjust access promptly when responsibilities change.
Maintain at least two suitable owners where continuity requires it.
Test authorization at API and download boundaries, not only in the UI.
Review direct cloud, database, storage, worker, and backup access separately.
Decide what membership and authorization events must be logged and retained.

RBAC works best as a boring, visible contract: people know what their role permits, owners review assignments, and exceptional powers remain exceptional. The goal is not to create an elaborate permissions taxonomy. It is to make routine collaboration possible while limiting the blast radius of mistakes and compromised accounts.