Authorization

Pentr accepts two credentials, one for the console and one for the partner API. Each resolves to one organization, and access is scoped to that organization. Share links are a third, narrower credential, described at the end of this page.

Console sessions¶

The console and the UI API it calls are authenticated by an Ory Kratos session. The session token is sent as a Bearer token in the Authorization header or as the ory_kratos_session cookie. The server checks it against Kratos's whoami endpoint on each request, and answers 401 when the token is missing or Kratos does not accept it.

A valid session resolves to one user, and the user belongs to one organization.

Partner API keys¶

The partner API, under /api/v1, is authenticated by an API key. The key is sent in one of three forms: Authorization: Bearer <key>, Authorization: ApiKey <key>, or an X-API-Key header. Pentr stores a bcrypt hash of each key, not the key itself, and accepts only keys marked active. A request without a key that matches an active key is refused.

An API key resolves to one organization, not to a person. Authentication covers the mechanics for an integrator.

Organization scoping¶

The routes that read or change engagements, findings, reports, lockers, share links, assets, schedules, signing keys and webhooks act only on resources that belong to the caller's organization. A request naming another organization's resource gets 404, the same response as for an id that does not exist, so a response does not reveal whether an id is in use by another organization.

Every artifact a run records is bound to that run's engagement.

Roles¶

Organizations are single-user. Signing in with a new identity creates a new organization, with that user as its owner, and no route adds a second user to an organization. Organizations describes this from the account side.

The one role check is on asset attestation, which only an organization owner may make. The partner API has no attestation endpoint, because an API key identifies an organization rather than a person to attribute the claim to.

Share links¶

A share link grants read access to the sealed evidence of one run, without an account. Its token is a bearer credential: the database stores a SHA-256 digest of it, lookups are rate-limited, and each link expires and can be revoked. The rate limiter lets requests through when its store is unreachable. Share links describes the link in full.

Internal interfaces¶

Identity administration and monitoring interfaces are not reachable from the internet.