Enterprise security model

What a DatumHue Enterprise deployment guarantees and where each guarantee ends, where trust lies, and what your organization must do. The Enterprise operator manual describes how to set up each part.

Overview

People run apps on workstations, in the app or a browser. Aggregators, the public entry point, admit workstations and providers and relay between them. Providers serve packages, folders, data, web services and events, each deciding access by its own rules. The Identity Provider connects your OIDC sign-in service, and the deployment tool makes every host's keys and authorizes providers. Aggregators renew the license with DatumHue unless it is airgapped.

Identity and sign-in

• Every sign-in is verified. Providers check each ID token's signature, issuer, expiry and audience: the deployment's client, or the audience you set, and no other. A token that fails verification is refused, never treated as no sign-in. Providers also refuse a token that marks itself as another kind, such as an access token, and use an email or phone number only when your sign-in service verified it.
• Sign-in keys come from authorized publishers. The Identity Provider publishes your sign-in service's keys to the aggregators, which take them only from a publisher the deployment authorized. They expire within a day, by each host's own clock. A provider that cannot confirm them with an aggregator fails closed: it refuses new sign-ins.
• Refresh credentials. For a sign-in service with a client secret, the Identity Provider holds the secret and the refresh credentials, and a copied workstation sign-in ends for both copies once both have refreshed. Without one, the workstation holds the service's refresh token, and a copy works until the service ends it.
• Signing out deletes the stored sign-in, ends it at the Identity Provider or, where it supports revocation, at your sign-in service, and ends the person's access through the workstation's folder and data mounts. datumhue logout --everywhere also ends the person's other sign-ins at the Identity Provider.
• Apps never see a token. Apps with the identity permission read who is signed in, email included, whether or not your sign-in service verified it; other apps learn only whether someone is. A mount an app holds acts as the signed-in person either way.

Access to data and services

• Deny by default. A request is allowed only when a rule grants the rights it asks for, and rules are set per resource and per sign-in service. No mount or channel is served without rules, and without publish rules nobody publishes. Reading packages is the exception: any program that reaches the package provider can read them.
• Open access is explicit. allow anyone admits, without a sign-in, anyone who can reach the provider, and every provider that grants it warns at start. It never grants writes to a data mount or the right to publish, and never opens a mount that requires the person's token.
• A refusal reveals little: which claim, or which package scope, failed, never the value the rule expects.
• Databases. A reader's session is read-only, enforced by the database. Beyond that, the database user's grants are the boundary, shared by everyone on the mount. On PostgreSQL the provider refuses a user that could run programs or reach files on the database's host.

When access ends

• Access follows the current sign-in. Access you withdraw at your sign-in service ends within the lifetime of the person's current ID token; a channel's events stay readable for up to two of its key rotation periods.
• Open access stays. What allow anyone grants outlasts any sign-in, unless the mount forwards the person's token.
• A replaced access key ends the sessions it admitted within seconds, though they can still reach the relay for up to an hour. Ending one session at the aggregator keeps no one out.

Credentials and keys

• The deployment secret is the root. Whoever holds it and reaches an aggregator can authorize providers, admit programs and publish sign-in keys, past every check. You make it and every aggregator holds it; DatumHue never sees it and cannot derive it from the license. If it leaks, datumhue-deploy reissue-capabilities --new-deployment-secret replaces it and every authorization, keeping the revocations.
• The access key admits workstations. The program holds no secret of its own: whoever holds the key, in the app or through the browser access link, connects as one of your people.
• Providers are authorized per namespace. Each authorization names one mount, channel, package namespace or sign-in service and one program's key, lasts a limited time, and works for that key alone.
• Revocation. datumhue-deploy revoke withdraws a provider key's authorization at any time: aggregators refuse the key at once, sign-in keys it published stop verifying sign-ins within a minute, and within five minutes workstations send it no new request for a folder, data or egress mount and take no channel keys or incoming events from it.

Data in transit

• Connections between DatumHue programs are encrypted and mutually authenticated, directly or through a relay, which cannot read or alter them undetected; browsers get the same. Any program the deployment admits can offer content and register its own address, but a false offer can only make a fetch fail or wait, never change what arrives.
• The aggregator's web side is served over HTTPS and hardened against framing and script injection.
• Incoming events are accepted only when signed with their channel's secret, and reach apps encrypted. The ingress provider takes plain HTTP, so TLS in front of it is yours to end.
• An aggregator's operator sees the addresses of the programs that connect, when, how much and to which program they send, and which shared documents and message topics each workstation joins. Anyone who knows a program's public key can look up its address there.

Data at rest

• The stored sign-in is protected by the operating system's user account or the browser's site isolation. Its encryption key is built into the workstation, the same in every copy of a release, so it does not protect a copy from anyone who has that release.
• The Identity Provider's session store holds your sign-in service's refresh tokens, encrypted; with the Identity Provider's key file, it exposes current sign-ins.
• Keys and the deployment secret are refused while other accounts can read them. Keys the deployment tool makes are encrypted under your passphrase; one a provider makes itself, only when you set one.

Outbound requests and credential forwarding

• The origin is the boundary. Each egress mount reaches one origin you set; its requests and redirects stay within it, and read access sends only read requests.
• No internal addresses. The provider never connects to loopback or link-local addresses, where cloud instance metadata lives, or to the major clouds' metadata services. Private networks, the host's own network address included, stay reachable, and through an outbound proxy the proxy decides.
• Credentials belong to the mount, sent only over HTTPS; the app never chooses or reads them. A person's access token leaves the workstation only for a mount that forwards it.
• Forwarding shares authorization. The web service can use the token until it expires, and every app the person runs with the mount acts as the person there. A credential you set on the mount is lent to everyone the mount admits.
• Tokens are tied to the person where your sign-in service makes that possible, and refused when issued for someone else; otherwise the provider forwards them unchecked.

Shared documents and messages

• Spaces separate apps by accident only. Documents, message topics and presence are kept apart by an app's package scope and source, or shared by every app that opts in. A modified workstation reaches any of them: treat their contents as input from anyone in the deployment. Local messages reach every app on the workstation.
• An unbound grant is a bearer secret. A document grant made for one workstation works only there, whoever uses that workstation; any other works for whoever holds it.
• Grants cannot be withdrawn. A grant opens the document's history. One to a document shared between workstations lasts as long as its app sets, 30 days by default, never longer than its maker's access; one to a document kept on the workstation never expires. A write grant's holder can still add changes dated within its period after it ends.
• Clocks decide order. The newest change wins, and changes dated too far ahead of a host's clock are refused.

Apps and packages

• Apps are sandboxed. An app has no operating-system access, reaches files, mounts and other apps only through what it was given, and passes on only what it holds. It gains a permission only from the app that started it, and the window manager asks the person first.
• The first app holds every permission. In a browser, a link that starts an app other than the window manager, or grants a mount, waits for the person to confirm it in the workstation's own dialog.
• Apps share one process, so one can exhaust the workstation's memory, and the screenshot permission captures other apps too.
• Native plugins hold full authority, loaded only from the folder --plugins-dir names.
• Sealing is not protection. It makes an app's code harder to read, not hidden. Sealed code runs in the same sandbox as any app, and the package provider serves it unchecked.

Logging

• Logged: each access a provider allows or refuses, each sign-in it cannot verify, and each session it ends when a refreshed sign-in fails the rules. A line names the resource, program, person and any failed claim; an open is logged, not each operation after it. The Identity Provider logs the sign-ins it ends, and aggregators log changes to the sign-in keys and each session an administrator ends.
• Never logged: tokens, refresh credentials, secrets, the values rules expect, and the bodies of web requests and events.
• Where: each program's own log, where your log settings keep or drop it; DatumHue keeps no durable or tamper-evident copy.

Your responsibilities

• Keep every host's clock synchronized.
• Register a client at your sign-in service for the deployment alone.
• Keep the deployment secret, license, access key and tool passphrase in your secret store; the first three together run an aggregator.
• Move the deployment tool's bundle, which holds every private key, over a secure channel, and delete working copies.
• Keep keys, secret files and the Identity Provider's session store, backups included, readable by their service alone.
• Share the access key and unbound grants privately; replace the key with datumhue-deploy new-access-key when someone leaves.
• Write the narrowest rules, keep allow anyone to public content, and give each database user only the grants and statement time its mount needs.
• Narrow forwarded tokens' audience; without a client secret, turn on refresh-token rotation with reuse detection at the sign-in service.
• End TLS in front of the ingress provider, firewall the egress provider's host, and control the native plugin folder.
• Revoke a compromised provider key and replace its host's secrets.
• Keep the access log in a store you control.
• Update every program of the deployment together.

Trust assumptions

• One operator per deployment, your organization, which runs the aggregators and providers. Independent operators sharing one are not supported: whoever runs an aggregator vouches for the sign-in keys every provider accepts.
• Your sign-in service and your Identity Providers are trusted for who people are: keys any Identity Provider publishes for a sign-in service verify its sign-ins at every provider, so protect each one's host like the sign-in service.
• Providers see sign-ins. Each provider a person opens receives their ID token, which the deployment's other providers accept until it expires: a compromised provider can act as those people until then, and an egress provider also holds the tokens it forwards.

Report a vulnerability

To report a vulnerability, write to security@datumhue.com with the version, the steps that reproduce it and its impact.

Report a vulnerability covers what happens to a report.