Skip to content
ArtificialFlow

IAM and roles

ArtificialFlow validates identities from your OIDC provider. It does not create users, clients, roles, or tokens there.

Turn integration on or off

The deploy builder has Integrate with IAM. True writes IAM_DEPLOYMENT_MODE: external in Compose and iam.mode: external in Helm, then fills the issuer and client fields. False writes IAM_DEPLOYMENT_MODE: disabled and iam.mode: disabled, and the stack does not require an OIDC login. The solution reads external and disabled for that setting.

Standard roles

RoleWho holds it
artificialflow adminHuman platform administrator. Deletes workflows and instances, reads incidents and metrics, retries jobs, and claims tasks as an administrator. Keep this role off a long-lived worker.
artificialflow modelerHuman process designer. Deploys and lists workflows and decisions. This role cannot start instances or search projected instances.
artificialflow clientSDK, worker, API, and automation identities. Starts instances, publishes messages and signals, operates jobs, reads the query API, and calls the inbox with acting-user headers.

Your OIDC administrator creates and maps these names. Assign a designer artificialflow modeler, and a service account artificialflow client only. An inbox backend uses the client role and passes the signed-in person separately. Combining client and admin on that machine identity is rejected. The supplied external configurations enforce audience. Tokens must contain the backend audience, normally workflow-backend.

External provider setup

  1. Create a backend API audience whose identifier matches AUTH_CLIENT_ID or iam.auth.clientId. The examples use workflow-backend.
  2. Create a public browser client, normally workflow-frontend, with Authorization Code and PKCE and no client secret.
  3. Register the ArtificialFlow origin as the login redirect, silent redirect, post-logout redirect, and allowed web origin. Local Compose uses http://localhost:9100. Kubernetes uses the public HTTPS origin.
  4. Create a confidential client-credentials client for SDK and worker access.
  5. Emit the roles on the claim named by AUTH_CLAIM_ROLES_PATH or iam.auth.claimRolesPath. The default path is roles,realm_access.roles,groups. ArtificialFlow checks those comma-separated paths in order, on both command and query.
  6. Include the backend audience in access tokens.

Use jwt for self-contained access tokens. For opaque tokens, use introspection and set the introspection URL, client ID, client secret, and basic or post authentication. AUTH_ISSUER_INTERNAL_URL is what the servers call. AUTH_ISSUER_PUBLIC_URL is the issuer browsers and tokens see. They are usually the same HTTPS URL. Set AUTH_ALLOW_INSECURE_ISSUER only when a local provider has different Docker and browser addresses.

Provider recipes cover Keycloak, Microsoft Entra ID, and Auth0. SDK token acquisition is in the SDKs guide. The route map is the HTTP API. Keep client secrets in a secret manager. See Deployment for how those values land in Compose and Helm.

curl -fsS \
  -H "Authorization: Bearer $ARTIFICIALFLOW_TOKEN" \
  http://localhost:9100/api/identity/me