Identity integration patterns

Who can PolicyArc identify, and where does each identity come from? It holds no passwords. People come from an identity provider you connect, agents and services are OAuth clients, and workloads can prove themselves with SPIFFE. A person can also connect other accounts that the managed gateway uses for them. This page names each pattern, what the server stores for it and the page that sets it up.

How it works

Pattern	Identity policy sees	What the server stores	Set it up
People sign in through your workforce identity provider	A subject, with the provider's sub, the provider key and the claims read at sign-in	The provider's registration, with its client secret encrypted. A row per person in subject and subject_userinfo.	Trust and identity, then a provider page such as Microsoft Entra ID
Agents and services are clients	A client, with its client ID and how it registered	A row in client, with a BCrypt hash of its secret if it has one	Agent identity
Workloads prove themselves with SPIFFE	A client the server creates for each SPIFFE ID the first time it sees one	A row in client. The trust bundle URL is a control data row.	Authenticate workloads with SPIFFE
One person connects other accounts	The same subject. The gateway uses the other account only for that person's calls.	The other provider's tokens, encrypted, one row per person and provider. Or a credential the person typed in, encrypted, one row per person and resource.	Connecting multiple accounts

Policy picks the provider for each sign-in, from the control data row pbac.operator.controls.idp_selection. You can connect several providers and route people by the resource they ask for or the assurance level they need.

Why it works this way

Every party is checked by a protocol the server already speaks, OpenID Connect for people, OAuth client authentication for software and JWT-SVIDs for workloads. So every identity reaches policy in the same shape, a subject, a client or both, and one rule can read them all. The cost is that identity is tied to the provider that vouched for it. A person who signs in through two providers is two subjects, and policy treats them as two people. Another account connected through the gateway does not have this cost, because it is stored under the subject the person signed in as.

What this means for you

• Pick one provider for each person's sign-in. If people must use two, write policy that names both subjects.
• Register each agent as its own client, so policy and the audit log can tell agents apart.
• Treat the identity provider's client secret and each person's upstream tokens as secrets. The server encrypts them with PBAC_CREDENTIAL_KEY, see Data handling.

We ran the integration tests for identity claims, reconnect links, typed-in credentials, forwarding a person's provider token and SPIFFE against a new test instance with one server replica on version 0.65.0, with a mock identity provider. All 30 passed in each of three runs. We did not connect a real workforce provider for this page.