Skip to content

Authentication Posture Not Admissible

URI: https://docs.ankatech.co/errors/authentication-posture-not-admissible
HTTP Status: 422 Unprocessable Content

When you see this

An administrator wrote an authentication posture no member could satisfy, or one this deployment does not allow. Nothing was written: the previous value stays in force. The answer comes from one of four writes:

  • a tenant's posture (PUT /api/v3/admin/tenants/{tenantId}/authentication-posture, replaceTenantAuthenticationPosture);
  • one member's authentication path (PUT /api/v3/admin/tenants/{tenantId}/users/{userId}/authentication-path, replaceTenantUserAuthenticationPath);
  • the deployment authentication allowance (PUT /api/v3/admin/platform/authentication-allowance, replaceDeploymentAuthenticationAllowance);
  • the platform authentication posture (PUT /api/v3/admin/platform/authentication-posture, replacePlatformAuthenticationPosture).

A tenant's posture can only restrict what the deployment allows. extensions.field names the request member at fault: allowedMechanisms, requiredProperties, mode or authenticationPath.

Common Causes

  • allowedMechanisms names a mechanism the deployment allowance forbids (for example PASSWORD_TOTP on a deployment that admits passkeys only).
  • allowedMechanisms is empty: a posture or an allowance admitting no mechanism would lock every member out.
  • requiredProperties names a passkey property while PASSKEY is not admitted. Only a passkey can hold a property, so the requirement could never be met.
  • mode is FEDERATED_ONLY for a tenant whose effective authority (its own providers, or the deployment provider it inherits) holds no active OIDC or SAML provider. An LDAP directory verifies a password and federates nobody.
  • mode is MIXED or FEDERATED_ONLY on the platform posture while no active deployment OIDC or SAML provider is approved for platform sign-in.
  • authenticationPath is FEDERATED_ONLY for a member of a LOCAL_ONLY tenant, or for a member holding no link to an active OIDC or SAML provider of the tenant.

Response Example

{
  "type": "https://docs.ankatech.co/errors/authentication-posture-not-admissible",
  "title": "Authentication Posture Not Admissible",
  "status": 422,
  "detail": "The deployment allowance does not admit PASSWORD_TOTP. Nothing was changed.",
  "instance": "/api/v3/admin/tenants/3f6c1a2e-8b4d-4e1f-9a7c-2d5e8f0b1c34/authentication-posture",
  "timestamp": 1730000000,
  "extensions": {
    "field": "allowedMechanisms",
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. This is an Admin API body, so the correlation identifier is extensions.requestId; see Error Index & Overview.

How to Resolve

  1. Read what is in effect: getTenantAuthenticationPosture, getDeploymentAuthenticationAllowance or getPlatformAuthenticationPosture. Each answer shows the effective posture, its authority and what the deployment allows.
  2. Correct the member extensions.field names: admit only mechanisms the deployment allows, admit at least one, require passkey properties only while PASSKEY is admitted, declare and enable an OIDC or SAML provider before choosing FEDERATED_ONLY, approve a deployment provider for platform sign-in before a federated platform mode, and link a member to the tenant's provider before restricting it to federation.
  3. Send the write again.

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