Workload Identity Federation
What this screen is for
A workload — a job, a service, a pipeline — authenticates to this platform with a token its own identity provider already issues it, instead of a secret you created here and have to rotate. This screen, reached from Access & Identity → Workload Identity Federation, is where you declare which external issuers this deployment is willing to verify tokens from.
It holds no settings. Nothing on it is a configuration value with a default; it is a registry of trust decisions with its own lifecycle, and the screen states the consequence plainly: no credential is created, stored or rotated here.
Read the split before you use it. Declaring an issuer grants nothing — it says this deployment is willing to believe tokens that party signs. What actually lets a workload in is the binding from one (issuer, subject) pair to one cryptographic actor, and that is a statement about the actor, so it is made on the actor's own screen. Nothing here creates a binding, and nothing there declares an issuer.
What must exist first
- The platform context, and the permission to read workload-identity trust. Without either read permission the screen says so instead of showing you an empty registry.
- The permission to write it, for declaring, editing, enabling, disabling and deleting; and the permission to test it, for the two probing actions. They are separate on purpose: testing reaches out to your issuer, reading does not.
- A deployment you operate yourself. The deployment-wide registry exists only on a private-cloud or on-premise install — a deployment-wide statement of trust is a statement about your own workloads there. It is not offered on an ANKA-operated install, and the platform refuses every verb on that plane, reads included.
- An issuer that publishes an OpenID Connect discovery document and a key set over HTTPS.
Decisions you make here
Declaring an issuer
Deployment trusted issuers lists what this deployment trusts, inherited by every tenant on it. A declaration names the provider — Auth0, Microsoft Entra ID, Okta, Keycloak, Amazon Cognito or any other OpenID Connect provider — the Issuer URL, an optional Label of up to 200 characters, and a Maximum token lifetime.
The issuer URL is stored in one canonical form and matched afterwards by exact string equality: never by host, never by prefix, never by suffix. Two spellings of one issuer therefore collide rather than coexisting, and one issuer URL may be declared once on this plane. Delete one and the same URL can be declared again.
The Signature algorithms are the provider's own set; the screen shows the effective set and does not ask you to narrow it. A maximum lifetime above the platform's ceiling is bounded rather than refused, and the row says so — tokens from that issuer living longer than the ceiling are rejected at authentication while every other issuer keeps working.
Giving your provider the audience
The registry shows a Derived audience that this server computes. Set it as the API identifier — the audience — of the machine-to-machine application in your identity provider, exactly as shown. Do not compose it yourself: a token whose audience is chosen by its own presenter is a claim validated against itself.
Enabling, and what enabled means
A newly declared issuer is inert. It reads Not in the trust set until you add it, which is deliberate: a declaration nobody finished cannot widen what the platform trusts on its own. Once it is In the trust set, a token that issuer signs authenticates the actor a binding names — and only that actor. Remove it from the trust set to stop that, immediately and for every binding on it.
Validating and testing
Two different questions, and the screen keeps them apart. The pre-flight validation asks the platform whether a candidate declaration would be admitted at all, and answers without writing anything and without contacting the issuer — so you learn which rule refuses a URL while the form is still open, rather than after a failed save.
The test reaches the issuer. You may hand it a sample token; the platform evaluates it and discards it, and never stores, logs, audits or returns it. Without one, some checks are reported as not exercised rather than as passed.
What the status column is, and is not
Token verified means a workload has authenticated with a token this issuer signed and the platform verified that signature against the issuer's key set. No token verified yet means that has not happened — it says nothing about whether the issuer answers, which is what the test is for. Verification failed means the issuer was reached and refused, or its key set could not be used. None of the three is a verdict on the last test.
One tenant's own issuers
The Per tenant tab administers one tenant's registry: its own issuers, additional to everything this deployment declares. A presented token names exactly one issuer, so these are a set — there is no first, no next and nothing to reorder. Choose the tenant there; you write on its behalf, without entering it and without reading its data. On a deployment you operate, every tenant is entitled to this; the Edition gate that applies to it is a commercial fact of ANKA-operated deployments only.
How it relates to other screens
The binding that actually admits a workload is made on the actor, from its federated-identities view, and that view links back here when a token names an issuer no declaration matches:
Human sign-in is the other federation subsystem and shares nothing with this one — a different screen, different tables, different permissions:
The surrounding sign-in configuration, and the map of every external system this deployment is wired to: