Account security

Versión en español: Seguridad de la cuenta.

Dialer Digital provides API capabilities to enforce tenant-level access constraints and audit platform support access. These features ensure that an account's attack surface can be strictly bound and that any impersonation by support staff leaves an immutable trail.

Login policy (IP and schedule)

Available since core v0.95.0: the /v1/tenant/login-policy endpoints.

A tenant can publish a login policy to restrict dashboard logins (ddu_ sessions) to specific IP addresses (CIDR ranges) and allowed calling windows, configurable per role (member or account_admin).

When a policy is set to enforce, the platform evaluates it after the credential proves right. A sign-in from an address outside the allowed ranges or at an hour outside the allowed schedule is rejected with 403 and the code login_policy_denied. The specific reason (address or hour) is not disclosed to the caller, but is written to the tenant's sign-in trail (GET /v1/auth/sign-in-events).

Configuration endpoints

• GET /v1/tenant/login-policy: Returns the standing login policy.
• PUT /v1/tenant/login-policy: Publishes a new version of the login policy. Takes a mode (off, observe or enforce; default observe), ip_allow, windows per role and timezone.
• GET /v1/tenant/login-policy/history: Lists every published version of the policy (append-only).

Reading (GET, history) takes a dd_ key or an account_admin login; writing (PUT) takes an account_admin dashboard login — a dd_ key is 403 role_forbidden.

Fail-closed limits

• ip_allow takes up to 64 CIDR blocks or bare addresses, IPv4 and IPv6; a malformed entry or a /0 is 422.
• observe mode logs the failures in the sign-in trail but never denies the login.
• A policy that would lock out the person writing it is refused with 422 would_lock_out_caller; nothing is stored.

Audited support access

Platform support access allows a tenant to grant read-only access to a Dialer Digital operator for troubleshooting.

By default, platform support access is disabled. A support operator cannot impersonate a user without an active, time-bound grant.

Granting access

An account_admin can grant access via:

• POST /v1/support-access/grants with a reason (1–500 characters) and an optional duration_minutes (15–480, default 60); the expiry is fixed at creation. A second live grant is 409 grant_already_live.

This creates a single live grant per tenant. The access is strictly read-only (dds_ lane) and can be revoked at any time:

• DELETE /v1/support-access/grants/{id}

The audit trail

Every grant, revocation, support session and request made under it leaves an append-only event in the tenant's trail:

• GET /v1/support-access/events: Returns the trail of platform-support access events, newest first.
• GET /v1/support-access/active: whether a support session is open right now (active, expires_at, operator_name) — readable by any dashboard login of the tenant, member included.

Granting, revoking and reading the trail take an account_admin dashboard login; a dd_ key is 403.

Single session per person

To prevent shared credentials and orphaned sessions, a tenant can enforce a single session per person.

This is governed by the single_session_enforced platform flag. When this flag is enabled by the platform:

• A new login (password, mfa, sso, etc.) will mint a new session and immediately revoke all other live sessions for that same person in the tenant.
• The next request made by an expelled session will receive a 401 with the code session_superseded. This specific code allows the UI to explicitly explain why the user was signed out, rather than a generic expiration.

This feature does not require API configuration by the tenant—it operates silently in the background once enabled.