A single Omniscope server can host several independent customer groups ("tenants") side by side, with each group able to see only its own reports and data. This uses the built-in folder permissions, per-folder authentication and project resource controls, together with how you lay out the sharing folder on disk. No custom development is required.
The settings below are the controls Omniscope provides. The security design, validation and sign-off for your environment, including the operating system, network and storage layers, remain the responsibility of your own infrastructure and security teams.
How the sharing folder is laid out
Omniscope serves everything from a single "sharing folder" (the root folder, for example /home/ubuntu/omniscope-server/files/). Omniscope only ever knows about this one root path.
Inside it, you create one subfolder per tenant. There is no limit to the number:
files/
A/ (tenant A)
B/ (tenant B)
C/ (tenant C)
Omniscope treats each of these as an ordinary subfolder. It performs plain file reads and writes against paths beneath the sharing folder and has no concept of where that storage physically lives.
This is what makes physical storage segregation possible without any Omniscope configuration. On Linux, each tenant subfolder can be a separate mount point pointing at its own physical disk or network drive:
files/A -> mounted to drive (or network share) for tenant A
files/B -> mounted to drive (or network share) for tenant B
files/C -> mounted to drive (or network share) for tenant C
The operating system transparently routes each path to its underlying device. Omniscope sees one sharing folder with subfolders; behind the scenes each subfolder is a distinct directory on separate storage. This lets your infrastructure team manage each tenant's backups, retention and storage location independently, even in different data centres.
NOTE: Setting up these mounts is an operating-system task (for example mount or entries in /etc/fstab), handled by your infrastructure team. It involves no Omniscope settings.
There are two practical points for that team:
Mount before Omniscope starts. If Omniscope starts first and writes to files/A before the mount exists, it will create a plain directory there and the later mount will hide that data. Ensure the mounts are in place at boot, before the Omniscope service starts.
Account for storage performance. The sharing folder is read and written constantly. Local SSD is fastest; network drives work but add latency, so size and test them for the expected report load. See the sharing-folder configuration article for guidance.
Confining each tenant to its own folder
Storage layout segregates the data on disk. The permissions layer ensures that, within Omniscope itself, a project in one tenant's folder can never reach another tenant's content. Configure the following on each tenant folder, via Edit permissions on that folder (or its folder.xml).
Restrict access to within this folder. This is the core control. With it set, a project in a tenant folder can only reach its own folder and sub-folders, never a sibling tenant, the parent folder, or anywhere else on disk. Sub-folders may tighten this further but can never relax it. See Resources projects can access.
Disallow sub-folder permission overrides. Set this on each tenant's root folder so its security scope is fixed and cannot be re-opened by a project or sub-folder inside it.
Apply a "Report viewer" permission set to the tenant's group: list directory, access to static resources and shared-report viewing only, with no editing, file management, data management, publishing, design or API permissions. Allow data refresh or export only if the tenant needs them. See Omniscope Evo user roles - managing permissions settings.
Disable anonymous access. Set the anonymous permissions to "No to All". Any permission left enabled for anonymous would allow that resource to be reached without logging in, and would consume a seat.
Disable uploads for viewers, so report viewers cannot write files into the tenant folder. If a tenant should only consume finished dashboards, you can also restrict the folder to serving published reports (IOR) only.
Authenticating each tenant
Each tenant folder has its own authentication, so Group A's users sign in through one identity provider and Group B's through another, with no overlap.
Configure one OpenID Connect provider per tenant folder. Users in Group A authenticate through OIDC A, Group B through OIDC B. See OpenID Connect settings.
Match groups by claim or role rather than by individual email. Restricting a group on an OIDC claim (for example a roles claim) is more robust than listing email addresses, and does not need updating each time the tenant's users change.
NOTE: Where more than one group could apply to a user, the first matching group is used. Order your groups from most restrictive to least restrictive.
Administrators across tenants (Optional)
Define your administrators as a super-group at the root folder. A super-group is inherited by every folder beneath it and cannot be overridden by a tenant's own settings, so it is the mechanism for retaining oversight, support and recovery access across all tenants.
One point to be aware of with per-tenant authentication: a super-group's permissions are inherited everywhere, but its authentication is not merged with a tenant folder's own OpenID Connect settings. When a tenant folder defines its own provider, the administrator super-group takes effect there only if its users can also be authenticated by that folder; otherwise it has no effect. There is no implicit cross-tenant administrator login, so the administrator super-group needs an authentication mechanism that is recognised in every tenant folder. Two common approaches:
a list-of-users (local credentials) super-group, which is independent of any tenant's OpenID Connect configuration; or
an OpenID Connect provider or claim that every tenant folder also accepts.
Server-wide hardening
Beyond the per-tenant controls, the following apply to the whole instance:
HTTPS with a trusted certificate (not the bundled self-signed one), with HTTP redirected to HTTPS. See the Web Server SSL configuration and HTTPS and URL redirection articles.
Session and OpenID Connect expiry set to suit your risk appetite. "Provider" logout clears the identity-provider session on sign-out; see the OpenID Connect scenarios article.
Single session per identity, to prevent one credential being used from several places at once.
Iframe embedding disabled ("Allow render in any iframe" off) unless you deliberately embed dashboards in another site, to reduce clickjacking exposure.
A reduced public API surface: disable the scheduler, workflow and data-edit public APIs unless a tenant genuinely needs them.
Cloud-metadata credential loading left off (EC2 and Compute Engine metadata), to close a metadata-theft path.
Tight host and drive access. The operating system is the outer boundary: anyone with file-system or host access to the server, or to the mounted drives, can read the data on them, so restrict and audit that access as part of your overall security model.
Related articles
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article