Secure your account
Maintain a strong password, enable two-factor sign-in, keep verified contact channels, and control the sessions where your account is signed in.
Ownership
A dedicated installation with an accountable operator
Mirket LMS keeps each organization in a dedicated installation. Your team operates an on-premise deployment; Mirket operates a managed deployment under the agreed infrastructure and support terms.
IdentityMembershipPermissions
Access has a boundary.
Dedicated installation, membership checks and private materials. Security remains an operational responsibility.
Ownership
Organizational isolation
Separate organizations do not share the parts that matter.
- Application processes, PostgreSQL, Redis, and storage namespaces are not shared between organizations.
- Customer configuration is mounted at runtime rather than baked into the application image, so the artifact you run is not specific to you.
- Student, Instructor, and Administrator applications use separate origins. The optional Parent portal adds its own origin when enabled.
Ownership
Learning files
File access is checked against the request, not against possession of a URL.
- Exact-context access
- A protected check binds the requester’s identity to the exact resource context. Belonging to the organization is not the same as being allowed to open a particular file.
- Deny by default
- Access policy names deny unknown values by default, so a policy gap fails closed rather than open.
- Signed delivery
- Browsers receive time-limited signed URLs from a public storage endpoint. Learning material is not sitting behind a permanent public object URL.
- Separated buckets
- Public, protected, and chat objects live in separate buckets with their own rules rather than one bucket with conventions.
Ownership
Accounts and sessions
The account flows are where most real attacks land, so they carry explicit invariants.
- Two-factor authentication is part of the sign-in contract, and the development bypass cannot skip it.
- Reset and two-factor tokens are one-time, and only the most recent token for a user stays active.
- Token consumption uses conditional atomic updates, so two concurrent replays of the same token cannot both succeed.
- Forgot-password responses do not reveal whether an account exists.
- There is no authentication bypass outside an explicit development scope.
- Configured Google Workspace and Microsoft 365 sign-in bind to an existing active account through an explicit administrator action; matching email addresses do not create or link accounts.
Ownership
Communication boundaries
Chat is a place where a learning platform can quietly become unsafe for the people it serves. Blocking and direct-message controls are enforced inside the homeserver itself rather than only in the interface, so a client that ignores the UI still cannot route around them.
Ownership
What this does not claim
This page describes how the software behaves. It is not a certification, an audit report, or a statement about how any particular organization has configured and operates its installation. If you need those, talk to us about your own deployment.
The manual
Do it, step by step.
The manual covers this as a task, with prerequisites, what finishing looks like, and what to do when it does not work.
Administer an organization
Manage people, courses, communication, and operational visibility while preserving organization and role boundaries.
Operate a Mirket installation
Understand the organization-isolated runtime, configuration boundary, health checks, and recovery expectations.
Bring Mirket LMS to your organization.
Run it on your own infrastructure or let us host it for you. Both options provide the same product; the difference is who operates the infrastructure and data services.