Skip to content

Operation Not Available While Impersonating

URI: https://docs.ankatech.co/errors/impersonation-operation-forbidden
HTTP Status: 403 Forbidden

When you see this

The caller is acting under a support-access impersonation session and took a route that is withheld from such a session by design. For the durable-access set the refusal is deployment-scoped: it is raised on SaaS deployments only, because a customer-operated operator is the deployment's own owner and the refusal has no third party to protect there. The operations on the caller's own account, the two platform key-custody operations and the log fingerprint computation are the exception and are refused on every deployment type (see below). This is not an authorization failure: the operator holds the scope and is inside the tenant boundary. The refusal is raised as the handler's first statement, so nothing downstream runs and no state changes.

Common Causes

  • A key-plane route that moves key material in or destroys it: import-key, import-keystore, import-keystore/analyze, mark-for-destruction and cancel-destruction. Key creation and rotation stay permitted.
  • A tenant-plane route that establishes access outliving the consent window — the durable-access set, which spans the user, actor, credential, role, identity-provider, email-domain, authentication-posture, member authentication-path, support-access, notification-provider, observability-backend and administrative-workload controllers, among others.
  • Together with the key-plane routes above that is 52 operations in eleven groups, across nineteen controllers, pinned by DeniedOperationManifest in admin-api and published as a table in Consent and Support Access*.
  • An operation whose authorization is ownership of the token's own subject: the auth-api account password change and the security self-service operations (authenticators, recovery codes, password removal). Under impersonation that subject is not a person who may act on these accounts (the operator, who is no member of the tenant), so these are refused on every deployment type, customer-operated included, whatever role the session was mirrored to, before any call to admin-api.
  • A platform-plane route that moves the platform's user-token signing keys: POST /api/v3/admin/platform/token-signing-keys/actions/rotate and POST /api/v3/admin/platform/token-signing-keys/{kid}/actions/revoke. The key signs every user token the deployment issues, and a support session is not its custodian on any deployment type, so these two are refused on every deployment type, customer-operated included. They are outside DeniedOperationManifest. Listing the keys stays permitted.
  • The platform log fingerprint computation, POST /api/v3/admin/platform/log-fingerprints. It confirms a guessed identifier against every technical log of the deployment, so it is answered only to a person acting as themselves, and is refused on every deployment type, customer-operated included. It is outside DeniedOperationManifest.
  • The impersonation claim could not be read at all: the check is fail-closed, so an unreadable claim is treated as impersonation.

Response Example

{
  "type": "https://docs.ankatech.co/errors/impersonation-operation-forbidden",
  "title": "Operation Not Available While Impersonating",
  "status": 403,
  "detail": "This operation is not available while acting on behalf of a tenant.",
  "instance": "/api/v3/admin/tenants/7c9e6679-7425-40de-944b-e07fc1f90ae7/keys/import-key",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

Branch on type, not on the status: the generic forbidden type reads as a missing scope and would send an operator to widen a role, which cannot help here. Every refusal body is identical apart from instance, and names no key, tenant, operator or window. Both denied sets bind on SaaS deployments only — on a customer-operated deployment the operator is the deployment's own owner, and the routes remain permitted there. The account-ownership operations, the two token-signing-key operations and the log fingerprint computation above are the exception: they bind everywhere.

How to Resolve

  1. Ask the tenant to perform the operation under their own credentials — the remedy belongs to whoever owns the tenant, not to the support session.
  2. For a key import or destruction, the tenant's own administrator must issue it; support impersonation can still create and rotate keys.
  3. For a token-signing-key rotation or revocation, a platform super administrator signs in under their own credentials, outside any impersonation session, and issues it from the platform tenant.
  4. If the operation is genuinely part of support, reconsider whether it belongs inside a bounded consent window at all — a durable change outlives the window by definition, which is why it is refused rather than audited after the fact.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.

* restricted content — see higher-tier documentation