Skip to content

Security model

Talmi decides who may mint which downstream tokens, so its security properties are worth understanding. The two pages after this cover the config-source trust boundary and a checklist for public exposure.

Default deny

Anything the rules don't explicitly allow is denied, and the engine does not assume config vet ran. Each of these denies on its own:

  • no rule matches the principal;
  • a requested resource has no realm prefix, or an unknown realm;
  • a request has an empty action list;
  • a rule's condition is empty and allow_empty was not set;
  • a match expression errors or returns a non-boolean.

A request is authorized only if the union of matching allow grants covers every requested resource=action, and the grant never exceeds the realm's capability ceiling.

Anti-spoofing identity

The identity keys iss/sub/id/issuer in conditions always come from the verified principal, never from token attributes. A token claim named sub cannot override the verified subject.

Least privilege at mint time

When several provider instances can serve a resource, the resolver picks the one whose action ceiling most tightly fits the request. A read request is served by a read-only App even if a write App exists in the same realm.

Secrets

Credentials are never inline; they are secret.Refs resolved at load time and never logged. Error messages reference the scheme or variable name, not the value. Minted token values are never persisted - only a SHA-256 fingerprint (for tracing) and a hash of the revocation secret.

Server-generated identifiers

Lease IDs, artifact IDs, and audit IDs are generated by the server, never derived from client input (for example, the correlation header). This prevents a client from colliding or predicting them.

Transport

Talmi speaks plaintext HTTP and expects TLS termination at the ingress or load balancer. Request bodies are capped (1 MB). 5xx responses return a generic message plus a correlation id; internal error detail is logged, never returned.

Sessions

Admin session JWTs are signed with a pinned algorithm (keyfunc rejects a mismatched alg), so there is no algorithm-confusion or alg=none bypass. See Sessions and admin.