Skip to content

Federated Role Is Service-To-Service Only

URI: https://docs.ankatech.co/errors/federated-role-s2s-only
HTTP Status: 422 Unprocessable Entity

When you see this

A federated login was refused because an admission rule or group-to-role mapping names a role that exists and resolves, but is marked service-to-service only. Such a role is held by a workload, never by a human user, so no federated sign-in can be admitted under it.

Common Causes

  • An admission rule or mapping names an internal service-to-service role instead of a human-assignable one.
  • A role was marked service-to-service only after the rule that names it was declared.

Response Example

{
  "type": "https://docs.ankatech.co/errors/federated-role-s2s-only",
  "title": "Federated Role Is Service-To-Service Only",
  "status": 422,
  "detail": "Role 'S2S_AUDIT_WRITER' is for service-to-service use only and cannot be assigned to a HUMAN user",
  "instance": "/api/v3/admin/s2s/auth/idp/provision",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

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

This cause carries its own type because a service-to-service role can be perfectly admissible under the role-and-tenant-type rules: reporting it as an assignability problem would send an operator to change the tenant or the category, neither of which is the repair. The detail names only the submitted role name and carries no tenant or rule identifier. At declaration time the same role is refused with a 400 invalid-input instead; only the login path carries this type.

How to Resolve

  1. Replace the role in the admission rule or mapping with a human-assignable one.
  2. If a workload genuinely needs that role, provision it as an actor with its own credential rather than through federated sign-in.

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