Access control

Last reviewed: [DATE]

This document sets out who can see and do what in Innorve Academy, how access is granted and removed, and how Innorve personnel access production systems.

How access is enforced

Access is enforced twice:

1. In the database. PostgreSQL row-level security checks every query against the user's institution memberships and roles.
2. In server code. Authorization is checked again on every request and every export.

The application holds no database service key. It always acts as the signed-in user. An automated test suite checks tenant isolation and role boundaries.

Role matrix

A person can hold more than one role in an institution. Their permissions are the sum of their roles. Reviewers and facilitators can be scoped to specific cohorts.

"[CONFIRM]" cells reflect behavior that Innorve must confirm against the current build before the packet is shared.

Innorve facilitators and reviewers who work with a credit union are given the facilitator or reviewer role in that credit union's institution. They then have that role's access, with the same limits as credit-union staff in the same role. The "Innorve platform staff" column describes the separate administrative designation.

Role summaries

• Learners see their own work and released feedback.
• Reviewers see submitted (not draft) work in their assigned institution or cohorts, and the answer keys. They cannot assess their own work.
• Facilitators see enrollment and activity status and released results, but not learner drafts.
• Sponsors see cohort aggregates with denominators, the binder status and the workflow results, but not individual drafts or detailed scores.
• Institution admins manage membership only.
• Innorve platform staff administer institutions and cohorts. Database rules deny them learner drafts.

How access is granted

1. Invitation. An institution admin, or Innorve platform staff at the credit union's request, invites a person by work email address and assigns roles and, for learners, a cohort.
2. Acceptance on sign-in. The invitation is accepted when the person signs in with that exact email address, using a one-time link or 6-digit code sent to it. The person then receives the membership and, for learners, the enrollment.
3. Expiry. Unaccepted invitations expire after 30 days and can be revoked before then.
4. Role changes. Institution admins can change roles within their institution. Role changes are recorded in the audit log.

Because access follows the email address, the credit union's control of its own mailboxes is part of the access control. When a person leaves, the credit union should both remove them from the platform and disable their mailbox.

How access is removed

• An institution admin removes a person's membership or roles. The change is audited.
• Innorve platform staff can deactivate a membership on request.
• At the end of an engagement, institution data is deleted under RET-v1. See Retention and deletion.
• Access reviews: the credit union is responsible for reviewing its user list. Innorve can provide the current membership list on request. [CONFIRM]

Innorve personnel access

Through the application

Innorve platform staff are designated in the database. They administer institutions and cohorts through the application, subject to row-level security. Database rules deny them learner drafts.

The list of platform staff is limited to [CONFIRM names or number] and reviewed [CONFIRM frequency].

Through provider consoles (production access)

Some tasks need direct access to production systems: the Vercel and Supabase consoles, and the database itself. Console access with database-owner privileges is not subject to row-level security. It can reach all stored data. For that reason:

• it is limited to named personnel: [CONFIRM names];
• it requires multi-factor authentication on every provider account: [CONFIRM];
• each use requires a recorded justification (ticket or log entry stating who, when, why and what was accessed): [CONFIRM process];
• provider-side access logs are retained: [CONFIRM what each provider logs and for how long];
• personnel with this access are bound by confidentiality agreements [CONFIRM] and have had background checks [CONFIRM].

Where personnel are located

[CONFIRM: country or countries where personnel with production access are located.]

Authentication summary

• Passwordless sign-in by email: a one-time link or a 6-digit code.
• No passwords are stored.
• Session cookies are HttpOnly, Secure and SameSite=Lax.
• Single sign-on is planned but not yet available.
• There is no separate second factor in the platform. The strength of sign-in depends on the security of the user's work mailbox, which the credit union controls.