Access Control and Authentication

Access control in Parascope has two halves: what a person or a key is allowed to do, and which of your infrastructure data it is allowed to see. Your own superadmins configure both, inside your tenant, and both start empty. This page describes the permission model, the four API key tiers, where multi-factor authentication is enforced and how far it reaches, the lockout behaviour on repeated login failures, and the audit log that records all of it. RBAC Administration is the how-to guide for the same surface; this page is the reviewer's version.

Teams, permissions, and data scopes

User accounts are provisioned on first login through your tenant's own identity realm. Access is granted through teams, and a user inherits the permissions and data scopes of each team they belong to. Grants can also be attached to an individual user for cases teams do not fit.

A permission is a resource paired with a set of actions. The resources are configuration items, collectors, sources, correlation rules, teams, users, and the audit log; the actions are read, write, and delete, with a wildcard covering all three. The wildcard resource, which covers everything, is reserved for superadmins.

A data scope decides which configuration items a user can see. Each scope names a source and, optionally, a specific instance within it, so scopes range from a single named Kubernetes cluster up to the whole estate. Scoping is deny by default: a user with no scope through any team and none of their own sees no configuration items at all. Permissions and scopes are evaluated on each request, so a revoked grant takes effect on the next call.

Who may change what is fixed in the API:

Deactivating a user is a soft delete that preserves their history. It clears the active flag, revokes their sessions, and revokes every API token they own, in one operation. The account and its audit trail stay readable. A superadmin cannot deactivate their own account, which keeps a tenant from clearing its last administrator by accident.

API keys and tokens

Programmatic callers authenticate with the X-API-Key header. Keys are never accepted in a query string, so they stay out of proxy logs and browser history. The platform stores a SHA-256 hash of each key and holds no copy of the key itself; the plaintext is displayed once, at creation.

Two properties in that table deserve emphasis. Service and admin tier keys are tenant-wide readers, since data scopes do not confine them, which is why they belong to the platform's own components and to automation you control, and not to individual people. A readonly key holds no scope until one is granted, and a key with an empty scope set reads nothing.

A user token stays in lock-step with its owner's live grants. Change the owner's team membership and the token's reach changes with it on the next request. Each user may hold up to 10 tokens, each with an expiry the user chooses, capped at 365 days. A token can be marked read-only at creation regardless of what its owner may write.

One grant sits outside the tier model. Reading a stored source credential back out of the platform requires an explicit sources:reveal_credentials grant on the calling key, which admin or service tier alone does not confer, and each call writes an entry to the audit log. Data Handling and Retention covers that path in full. Per-key rate limits are described in Tenant Isolation Architecture.

Multi-factor authentication

A superadmin turns on Require two-factor authentication under Settings → Account → Security Policies. The setting is per tenant, and turning it on does two things: it arms your tenant's identity realm so that enrolment in a TOTP authenticator becomes a required action for users who are not yet enrolled, and it stamps the moment the policy took effect. That stamp is what dates existing sessions and keys.

The second factor is TOTP: a 6-digit code on a 30-second period, HMAC-SHA-256, with code reuse refused. TOTP is the only second factor the product supports, and there is no WebAuthn or passkey option today. If a hardware security key is a requirement for you, raise it at [email protected] before you buy.

Enforcement of the tenant policy happens at four layers, all reading the same policy record so that the setting shown in the UI and the setting that gates traffic cannot drift apart:

At the callback the check reaches past enrolment. Proving the second factor ran during this particular sign-in means asserting the OIDC amr claim, which lists the methods that completed, and that assertion runs in strict mode: a login whose token carries amr without an OTP method is refused. Tenant realms are provisioned from a template that emits the claim, so the assertion applies from a tenant's first sign-in.

The posture is fail closed. When enrolment status cannot be verified and the last good answer has aged past its stale window, affected sessions are denied. A session that could not be verified is left intact so that it recovers when verification does; a session confirmed to belong to an un-enrolled user is revoked outright.

The bounds on what enabling MFA reaches

Four limits are worth stating plainly, because a questionnaire answer of "MFA enforced" would paper over them.

A session that predates the policy survives briefly. Each API pod caches the policy snapshot for 30 seconds, so a pre-MFA session can serve requests for up to about 30 seconds after the toggle before the per-request gate stops it. Enrolment status can be up to 60 seconds stale in normal operation, and if the control plane is unreachable that widens by a further 15 minutes before the fail-closed denial takes over.

Enabling MFA does not revoke API keys. This is deliberate, and it is a founder decision on record: automation should not break as a side effect of a security toggle. Keys are dated against the policy stamp, and any key created before it carries a Pre-MFA badge on Settings → API Tokens, covering service, admin, readonly, and user tokens alike, since each of them authenticates without passing the login gate. Rotating a flagged key is the administrator's explicit action: mint the replacement, cut the consumer over, then revoke the old one. A tenant that enabled the policy before the stamp existed sees a Pre-MFA? badge for unknown vintage, because the available proxy timestamp dates the policy later than reality and would clear keys that deserve the flag.

The per-login check fails open when the claim is missing. Strict mode refuses a login whose token carries amr without an OTP method. A token carrying no amr claim at all is a different case: there is nothing to assert against, so the login proceeds on the enrolment proof, and the property enforced falls back to the one the other layers carry, that the account signing in is enrolled in TOTP.

Long-lived connections are gated per request. A streaming connection opened before the policy took effect is not cut mid-stream. The next request on that session is gated normally.

The policy governs interactive sign-in to your tenant. API keys authenticate without passing that gate, which is the reason the vintage badge on the token list exists.

Passwords, lockout, and session limits

Where users hold passwords in your realm, the policy requires at least 10 characters with an upper-case letter, a lower-case letter, and a digit, forbids the username as the password, and blocks reuse of the last three.

Repeated failures lock the account. The figures are realm settings applied to every tenant at provisioning:

Sessions carry their own ceilings. A session idles out after 30 minutes and ends after 10 hours whatever the activity on it. Access tokens expire after 5 minutes, and refresh tokens are single use, so each refresh rotates the token and a replayed one is rejected.

The audit log

Security events are written to a log in your own tenant database, readable and exportable at Settings → Audit Log. Access is restricted to superadmins, which holds even for a user carrying broad permissions elsewhere, because the log itself carries login patterns, IP addresses, and permission history.

Each record carries the timestamp, the event type, the acting identity as a user email and display name or as an API key with its name and tier, the source IP address, the user agent, the endpoint and HTTP method, the response status code, and a details object holding context specific to the event.

Filters narrow the view by event type, user, date range, and IP address, and Export CSV streams the filtered set as a file for a SIEM or your own archive. Take that copy if you need history beyond the platform's window: audit records are retained for 90 days and then pruned by the daily retention sweep. Data Handling and Retention sets that figure alongside the other retention windows.

Verify it yourself

Each of these runs in the product, on your own tenant.

• Scoping is observable end to end. Create a team scoped to one source, add a test user to it, and sign in as that user. The configuration item list shows that source and nothing else. Remove the scope and the list empties, which is the deny-by-default model doing its job.
• Key tiers are visible on the key. The prefix is part of the value, and Settings → API Tokens shows the prefix, the expiry date, and the last time each token was used. A Pre-MFA badge appears there when a token predates your MFA policy.
• The audit log records your own actions. Make a change (rename a team, create a token), then open Settings → Audit Log and find the event, with your email and your source IP on it. Export CSV downloads the same rows with the full field set.
• Lockout is testable on an account you own. Fail a login five times on a test account and the sixth attempt is refused for the lockout window, whether or not the password is correct by then. Waiting out the window restores access without administrator involvement.
• Session ceilings are testable by waiting. Leave a session idle past 30 minutes and it requires a fresh sign-in.
• Access-control controls with their own verify pointers are listed in the control matrix. Anything this page leaves open goes to [email protected].