Tenant isolation
Tenant-owned database records use PostgreSQL row-level security and tenant-scoped transactions to separate institutional data.
Security by responsibility
The right access. A clear record of important decisions.
School operations involve sensitive learner information and consequential approvals. VidyOmni combines tenant boundaries, scoped permissions, account controls and recorded changes to support responsible administration.
Institution-aware workflows Role-based access
THE CONNECTED INSTITUTION
Clear responsibilities. Informed decisions.- 01Assign a defined role
Start with the person’s duties and assign the institution and campus scopes they need to carry them out.
- 02Secure the account
Use an individual account, a strong password and an enrolled authenticator. Confirm the recovery channel before relying on it.
- 03Review consequential changes
Use the independent approval steps supplied by the relevant workflow. Supported changes automatically retain actor, action and time details in the audit history.
- 04Revisit access as duties change
Review memberships and roles, remove access that is no longer needed and use session revocation when an account or device needs attention.
A practical journey to explore
A CLOSER LOOK
Security starts with who can do what, and for whom.
A teacher taking attendance, a cashier collecting a fee and an administrator changing access have different responsibilities. Server-side policy checks and institutional scope are part of the workflow, with additional approval controls for selected sensitive decisions.
Role and scope checks
Server-side policy checks consider permissions, tenant context and applicable institutional or learner relationships. A visible menu is not an authorization grant.
Authenticator MFA
Users can enroll an authenticator from their profile. A valid fresh code is required to complete sign-in once the factor is enabled.
Reviewable account sessions
Signed-in users can review active sessions, revoke a selected session or revoke their other sessions from the account workspace.
HOW IT WORKS
Build access around real responsibilities.
Make access review part of joining, moving roles and leaving the institution.
- 01
Assign a defined role
Start with the person’s duties and assign the institution and campus scopes they need to carry them out.
- 02
Secure the account
Use an individual account, a strong password and an enrolled authenticator. Confirm the recovery channel before relying on it.
- 03
Review consequential changes
Use the independent approval steps supplied by the relevant workflow. Supported changes automatically retain actor, action and time details in the audit history.
- 04
Revisit access as duties change
Review memberships and roles, remove access that is no longer needed and use session revocation when an account or device needs attention.
Concrete controls
Protect the account throughout its session.
Account protections work together, from password verification through session recovery and sign-out.
Passwords and recovery
Passwords use Argon2id hashing. The recovery flow uses expiring, attempt-limited verification and reset capabilities; a completed reset revokes refresh sessions.
Rotating sessions
Opaque refresh tokens are stored as hashes and rotate on use. Reuse of an old token revokes its session family, and authenticated requests check session revocation.
Browser protections
Production authentication uses Secure, HttpOnly cookies. Mutating browser requests carry a CSRF token, and refresh-cookie scope is limited to the refresh endpoint.
Accountability for changes
Important administrative and record changes write audit events with actor and correlation context, action, outcome and available before/after summaries or reasons.
Institutional assurance
Review the deployment, as well as the software.
Security also depends on operating decisions. Ask for evidence that matches your institution’s deployment and provider configuration.
Hosting and recovery arrangements
Agree hosting location, operational ownership, backup handling and recovery objectives with the deployment owner. These are deployment decisions rather than a universal product guarantee.
Provider and key management
Review enabled providers, credential access, secret rotation and production callbacks. An available configuration field does not mean a service is enabled.
Access and incident ownership
Name the people who approve privileged access, receive incident reports and coordinate the institution’s response before onboarding live records.
COMMON QUESTIONS
A few details
worth getting right.
Questions about your institution’s exact setup? Prepare a focused request.
Find the right contact routeIs MFA automatically mandatory for every user?
Authenticator enrollment and verification are implemented as account controls. This page does not claim a tenant-wide mandatory-MFA enforcement policy. Agree the institution’s enrollment and access-review process during rollout.
Do you publish SOC 2, ISO certification or an uptime SLA here?
No certification or universal uptime commitment is represented on this page. Security evaluation should use the controls and deployment evidence available for the proposed service, with any contractual commitments confirmed in the institution’s agreement.
What should I do if a device or account is compromised?
Use a trusted device to revoke affected sessions and change your password, then inform your institution administrator through its established channel. If you cannot sign in, use password recovery and ask the administrator to review access and affected records.
BUILD A CLEARER OPERATING DAY