Identity integration
A workflow needs to say who should approve something. It should not need to know how your company stores people. This section is about the gap between those two.
The chain is short: your identity system authenticates someone, that becomes an account; a provider translates the account into one or more principals; the workflow addresses a principal. The workflow never interprets the strings — it passes them back where they came from.
Throughout the workshop the provider is called siam. Everything runs on
prepared data. Connecting a live provider is a separate, optional exercise,
described on its own page.
Gate G10 — required implementation. The boundary is documented and works. Packaging it for customers, and verifying that packaging, still has to be built.
Someone logs in. The origin they logged in through decides which provider is responsible. That provider turns the verified account into principal references it owns. Only then does a workflow pick a recipient.
The provider ID travels with every principal, and the engine compares both.
user:alex from provider A and user:alex from provider B are two different
people, full stop. This sounds pedantic until you merge two directories, or run
a test provider next to a real one, and the string collision would have silently
granted someone access. A pending step keeps the provider ID next to its
recipient for the same reason.
Five words that are easy to mix up:
- Account — the identity that logged in and was verified.
- Principal — a person or membership, as your provider names it.
- Actor — an account plus the principals it currently has, at the moment it tries to do something. “Currently” is doing real work in that sentence.
- Assignee — the recipient recorded on a pending step.
- Assignee Source — a pointer to a group owned elsewhere, which can be refreshed by a signed change event.
The engine checks the provider matches before it considers visibility, ordering, paging, or letting a command through.
Next: Hooks and origin routing to register a provider, Fixtures and visibility to see the boundary reject someone, Assignee Sources when membership lives elsewhere, or the optional live Role Engine adapter.