POST /api/v1/principals
Create a password, LDAP or group principal by name.
Creates a principal and verifies by reading it back by name.
Only three types are creatable here: password, ldap and group. The other two
are refused with an explanation rather than a bare rejection:
xauthis created atPOST /api/v1/principals/xauth, which is idempotent by exact id. Two creation paths for one identity type is how you get two principals with one identity and different ids;certificateis not created by name and never was. A transport identity needs TWO records -- a certificate object keyed on the exact digest AND a subject-resolved, enabled transport principal -- and a principal created by name alone has no certificate bound to it and could never authenticate. UsePOST /api/v1/certificates/enroll.
A group IS a principal, which is why it is created and listed here rather than under a
/api/v1/groups collection; only membership lives under /api/v1/groups.
WARNING: the new principal holds NO roles and therefore NO operations. It can
authenticate and do nothing. The key server CLEARS the role list on creation whatever is
sent, so roles are always a second call: PUT /api/v1/principals/{id}/roles. Granting
access to a KEY is a third, different thing -- a role carries operations, a key ACL
carries rights.
A name that is already taken by a principal of the same type is refused before the
write, as 409 PRINCIPAL_EXISTS. The store enforces one name per class; this
pre-check turns its generic refusal into an answer that names the reason.
WARNING: on a 409 NOT_SAVED, do not simply retry. The first write may have landed
under a stored name the read-back could not match, so a retry meets either a
409 PRINCIPAL_EXISTS for a row that did land, or creates a second principal beside it.
List by type first.
Authentication
Send the session id as Authorization: Bearer <session id>, and an RFC 9449 DPoP proof in the DPoP header if your session is bound to a key. The two are required together, not as alternatives — see Authenticating and Proving you hold your key.
There is no session cookie on any response and none is read on any request. Do not set credentials: "include" on a browser fetch.
Request
| Field | Type | Required | Description |
|---|---|---|---|
type | string (password, ldap, group) | yes | |
name | string | yes | |
password | string | no | Required for type: password, and rejected by the key server if it fails policy. |
Example
{
"type": "password",
"name": "...",
"password": "..."
}
Responses
200
Created, and read back by name.
| Field | Type | Required | Description |
|---|---|---|---|
created | true (constant) | yes | |
type | string | yes | |
saved | boolean | yes | |
principal | Principal | yes | A principal, carrying its id in BOTH spellings because different routes take different ones. id (16 hex digits) is what this API's {id}, {gid} and {pid} path segments take; principalId (a decimal string of the same eight bytes) together with systemId is what the ACL and export routes take. |
detail | string | no |
Principal
| Field | Type | Required | Description |
|---|---|---|---|
id | string | no | 16 hex digits. |
principalId | string or null | no | The same eight bytes as a decimal string. A string, so that an id above 2^53 survives. |
systemId | integer or null | no | Assigned by the key server at setup. READ IT FROM THE SERVER; a hardcoded value addresses a principal that does not exist and yields a misleading "unknown principal". |
className | string or null | no | The key server's own class name -- UserAndPasswordInfo, TransportPrincipalInfo, LdapPrincipalInfo, XAuthPrincipalInfo or GroupInfo. |
name | string or null | no | |
disabled | boolean or null | no | |
roleIds | array of string | no | |
groupIds | array of string | no |
Example
{
"created": true,
"type": "...",
"saved": true,
"principal": {
"id": "...",
"principalId": "...",
"systemId": 0,
"className": "...",
"name": "...",
"disabled": true,
"roleIds": [
"..."
],
"groupIds": [
"..."
]
},
"detail": "..."
}
400
BAD_REQUEST -- name empty, type not creatable (the detail says where the other two are created instead), password missing for a password principal, or the password rejected by policy. The policy case additionally carries field: password.
401
No live session, a DPoP proof that did not verify, or a certificate session whose certificate the key server now refuses.
SESSION_NOT_FOUND -- the credential names no session this Gateway holds.
SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential
rather than retrying.
PROOF_* -- the sender constraint refused. See the DPoP section of this document for the
full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the
rest are here.
SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use
does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen
handle produces.
CERTIFICATE_REVOKED -- on a session established by certificate login, the key server
re-checks the certificate that session was established with on its operations, and it
is now named by revocation evidence. detail is the key server's sentence. The
Gateway answers this once and then ENDS everything that service holds or minted here --
its sessions, the delegated sessions and the scoped credentials it minted -- so a later
operation on any of them is SESSION_NOT_FOUND. Log in with a different certificate.
SSO_SESSION_EXPIRED -- a single-sign-on session (POST /api/v1/session/oidc) reached
its lifetime, or was idle past its binding's idle bound; it has been ended. Sign in again.
SENDER_KEY_RETIRED -- the session's registered sender key was rotated out and its
overlap has passed (see "The registered service's credential lifecycle"); the session is
closed with this answer. SERVICE_REGISTRATION_ENDED -- the registration a service
credential was issued under was removed or narrowed on this Gateway; it has ended. Both
are final for that credential.
403
Authenticated, and refused. The codes differ in what they say about where the refusal
came from: ACCESS_DENIED (no role grants the operation), ACL_DENIED (the ACL of the
key the request named refuses the principal -- ask the key's owner, not an administrator),
PRINCIPAL_DISABLED and DELEGATOR_REFUSED are the key server's -- the last one on a DELEGATED session whose delegator has since been disabled,
lost its DELEGATION flag, been unenrolled or had its certificate revoked; its
detail is the key server's sentence naming the delegator, and no new login helps until
an administrator restores it. REVOCATION_STATUS_UNAVAILABLE and
REVOCATION_EVIDENCE_STALE are the key server's too, on a session established by
certificate login: the same re-check found no current revocation evidence for that
certificate's issuer under a policy that requires it -- the credential is not
what was refused, and an operator importing a current CRL for the issuer is what helps.
TRANSPORT_PRINCIPAL_REQUIRED (POST /api/v1/keys/get: the operation needs a session
established by a certificate the key server has enrolled) and PRINCIPAL_MISMATCH (the
request named a principal other than the session's) are the key server's too, and no role
changes either -- while
NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and
OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent.
409
PRINCIPAL_EXISTS -- a principal of this type already carries this name; nothing was sent to the key server. Carries field: name, name and type. Or NOT_SAVED -- the key server did not refuse and the principal was not present when read back by name. See the retry warning above.
500
NO_CONSTRUCTOR -- an internal fault: no builder is registered for a type that passed validation. Or the shared OP_FAILED.
503
A capacity ceiling or a missing deployment prerequisite. retryable says which.
A scope of session or process names the ceiling that was hit, and the response
carries Retry-After.
BUILD_NOT_ADMITTED (scope: process, retryable: true, Retry-After): the key server
does not admit this Gateway's client build. Every key-server connection the Gateway opens
attests the signed release it runs (TE_RELEASE_MANIFEST) right after it authenticates;
while that attestation is refused -- the release is not registered at the key server's
code-signing level, the level was raised under it, or the installed files no longer
match the signed manifest -- every route but GET /api/v1/health and GET /api/v1/ready
answers this, and detail names the cause. It is never a 401 or a 403: no credential
or role of the caller's is at fault. The Gateway re-attempts on a timer and recovers
without a restart once the key server admits it; GET /api/v1/ready says when.
CAPACITY_UNAVAILABLE (scope: process, retryable: true, Retry-After): this Gateway
is serving its maximum number of requests at once, or cannot track another allowance, or
(on a certificate login) is recording its maximum of live certificate sessions -- in which
case the session the login created has been closed. Nothing else was sent to the key
server. See "Rate and capacity limits" above.
413
PAYLOAD_TOO_LARGE (retryable: false) -- the request body is larger than this
deployment accepts. It was refused before it was parsed, and the connection is closed.
Nothing was sent to the key server.
429
RATE_LIMITED (retryable: true, Retry-After) -- the allowance this request is charged
to is spent: the login allowance of its network source (before authentication), or the
allowance, the concurrency ceiling or the live-session ceiling of the identity it was
verified as -- shared by every session that identity holds, including every delegated
and scoped credential a service minted. It carries no scope. Nothing was sent to the
key server; on a login refused after authentication, the session it created has been
closed. See "Rate and capacity limits" above.
Error handling
Every failure answers JSON carrying at least code and detail. Match on code — detail is written for a human debugging the call and its wording is not part of the contract. See the error model.
| Status | Meaning |
|---|---|
400 | BAD_REQUEST -- name empty, type not creatable (the detail says where the other two are created instead), password missing for a password principal, or the password rejected by policy. The policy case additionally carries field: password. |
401 | No live session, a DPoP proof that did not verify, or a certificate session whose certificate the key server now refuses. SESSION_NOT_FOUND -- the credential names no session this Gateway holds. SESSION_EXPIRED -- it aged out. Both carry reauth: true; obtain a new credential rather than retrying. PROOF_* -- the sender constraint refused. See the DPoP section of this document for the full table; PROOF_MALFORMED is a 400 and PROOF_REPLAY_CACHE_FULL a 503, and the rest are here. SCOPED_CREDENTIAL_EXPIRED -- a scoped browser credential passed its fixed lifetime. Use does not extend it: an idle timeout would be refreshed by exactly the traffic a stolen handle produces. CERTIFICATE_REVOKED -- on a session established by certificate login, the key server re-checks the certificate that session was established with on its operations, and it is now named by revocation evidence. detail is the key server's sentence. The Gateway answers this once and then ENDS everything that service holds or minted here -- its sessions, the delegated sessions and the scoped credentials it minted -- so a later operation on any of them is SESSION_NOT_FOUND. Log in with a different certificate. SSO_SESSION_EXPIRED -- a single-sign-on session (POST /api/v1/session/oidc) reached its lifetime, or was idle past its binding's idle bound; it has been ended. Sign in again. SENDER_KEY_RETIRED -- the session's registered sender key was rotated out and its overlap has passed (see "The registered service's credential lifecycle"); the session is closed with this answer. SERVICE_REGISTRATION_ENDED -- the registration a service credential was issued under was removed or narrowed on this Gateway; it has ended. Both are final for that credential. |
403 | Authenticated, and refused. The codes differ in what they say about where the refusal came from: ACCESS_DENIED (no role grants the operation), ACL_DENIED (the ACL of the key the request named refuses the principal -- ask the key's owner, not an administrator), PRINCIPAL_DISABLED and DELEGATOR_REFUSED are the key server's -- the last one on a DELEGATED session whose delegator has since been disabled, lost its DELEGATION flag, been unenrolled or had its certificate revoked; its detail is the key server's sentence naming the delegator, and no new login helps until an administrator restores it. REVOCATION_STATUS_UNAVAILABLE and REVOCATION_EVIDENCE_STALE are the key server's too, on a session established by certificate login: the same re-check found no current revocation evidence for that certificate's issuer under a policy that requires it -- the credential is not what was refused, and an operator importing a current CRL for the issuer is what helps. TRANSPORT_PRINCIPAL_REQUIRED (POST /api/v1/keys/get: the operation needs a session established by a certificate the key server has enrolled) and PRINCIPAL_MISMATCH (the request named a principal other than the session's) are the key server's too, and no role changes either -- while NOT_WRITABLE, BUILT_IN_PRINCIPAL, OWN_ACCOUNT and OBJECT_NOT_IN_CREDENTIAL_SCOPE are decided by the Gateway before anything is sent. |
409 | PRINCIPAL_EXISTS -- a principal of this type already carries this name; nothing was sent to the key server. Carries field: name, name and type. Or NOT_SAVED -- the key server did not refuse and the principal was not present when read back by name. See the retry warning above. |
500 | NO_CONSTRUCTOR -- an internal fault: no builder is registered for a type that passed validation. Or the shared OP_FAILED. |
503 | A capacity ceiling or a missing deployment prerequisite. retryable says which. A scope of session or process names the ceiling that was hit, and the response carries Retry-After. BUILD_NOT_ADMITTED (scope: process, retryable: true, Retry-After): the key server does not admit this Gateway's client build. Every key-server connection the Gateway opens attests the signed release it runs (TE_RELEASE_MANIFEST) right after it authenticates; while that attestation is refused -- the release is not registered at the key server's code-signing level, the level was raised under it, or the installed files no longer match the signed manifest -- every route but GET /api/v1/health and GET /api/v1/ready answers this, and detail names the cause. It is never a 401 or a 403: no credential or role of the caller's is at fault. The Gateway re-attempts on a timer and recovers without a restart once the key server admits it; GET /api/v1/ready says when. CAPACITY_UNAVAILABLE (scope: process, retryable: true, Retry-After): this Gateway is serving its maximum number of requests at once, or cannot track another allowance, or (on a certificate login) is recording its maximum of live certificate sessions -- in which case the session the login created has been closed. Nothing else was sent to the key server. See "Rate and capacity limits" above. |
413 | PAYLOAD_TOO_LARGE (retryable: false) -- the request body is larger than this deployment accepts. It was refused before it was parsed, and the connection is closed. Nothing was sent to the key server. |
429 | RATE_LIMITED (retryable: true, Retry-After) -- the allowance this request is charged to is spent: the login allowance of its network source (before authentication), or the allowance, the concurrency ceiling or the live-session ceiling of the identity it was verified as -- shared by every session that identity holds, including every delegated and scoped credential a service minted. It carries no scope. Nothing was sent to the key server; on a login refused after authentication, the session it created has been closed. See "Rate and capacity limits" above. |