Find a file
Sipke Schoorstra 3921715060
docs: authorization model design (spec 013) (#7978)
* docs: add authorization model design (spec 013)

Replaces Elsa's ad-hoc permission vocabulary with a structured two-axis
model. Design only -- no code changes.

A census of all 150 permission-declaring endpoints found the current
vocabulary has no model behind it: "read:*" is a literal claim value
rather than a pattern, so it authorizes 12 of roughly 40 read endpoints;
57 permission strings appear as inline literals across 174 call sites in
three competing naming schemes; omitting a declaration fails open; and
four parallel enforcement mechanisms leave no single place to audit.

A permission becomes {resource}:{verb}, with both axes open and
string-keyed and contributed by modules through descriptors. A trailing
wildcard matches the named node and all descendants, so workflows/*:view
is a single grant covering definitions, instances, executions and every
descriptor endpoint, including ones registered in later releases.
Wildcards are the only construct with forward reach; there are no
aggregates and no verb implies another. Coherence without closure comes
from a recommended core verb set as convention, per Principle III.

A closed verb enumeration was drafted and rejected: fitting the census to
seven verbs forced six mappings, invented three sub-resources, and every
open question it produced was an artefact of the closure.

Contents:
- spec.md: 41 functional requirements, 9 user stories, 7 success criteria
- plan.md: 5 milestones, constitution check, project structure
- research.md: grounded assessment and decision record D1-D23
- contracts/permissions.md: resource tree plus the full migration mapping,
  verified complete against all 57 literal permissions in the codebase
- contracts/rest-api.md: catalog, reach report, and introspection
- tasks.md: 63 tasks across 5 phases, tagged by user story

Breaking changes are documented in the spec and tracked in the issue:
legacy permission strings stop authorizing; the migration expands rather
than renames, because several sub-resources are granularity increases;
read:* and exec:* become materially more powerful; and the C#/Python
expression permissions are removed rather than translated, which is a
deliberate reduction in control.

Refs #7974, #7972, #7975

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: scope the evaluator consolidation to permission checks

FR-016 and FR-017 swept in the mid-handler AuthorizeAsync calls, which in
the workflow API are the NotReadOnlyPolicy checks. Those enforce
deployment read-only mode -- whether the instance accepts mutations at
all -- which is orthogonal to whether a principal holds a permission. A
workflow author with full grants is still refused while the deployment is
read-only, and correctly so. Folding them into the permission evaluator
would conflate two independent axes and make read-only mode expressible
as a grant, which it must not be.

The consolidation still covers four parallel mechanisms, but not the same
four: FastEndpoints permissions, named ASP.NET policies (3 sites),
hand-rolled claim inspections (15 files), and SignalR hub checks (4 hubs).

- FR-016 scoped to permission decisions, with the separate axis named
- FR-017 states the NotReadOnlyPolicy exclusion and why
- FR-018 said "scope value"; corrected to "verb" after D13 opened the
  verb axis
- SC-003, the plan's constitution row, scale figures and milestone 3
  updated to match
- D5 and D6 marked where they still reference the withdrawn mask
- D24 records the correction rather than rewriting the assessment
- Permission string count corrected from 56 to the verified 57

Refs #7974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: apply module-owner review outcomes to the authorization model

Resolves the five open vocabulary questions and the two model gaps they
surfaced.

- External Authentication descriptors get their own resource,
  external-authentication/descriptors:view, as a single node. One legacy
  permission governs all six endpoints, which is the same principle that
  gives workflows/descriptors nine separate resources -- those were
  separately permissioned already. The tree reflects the API in both cases.
- /user-options stays on identity-links:view. It is a user search backing
  the link picker and the linking UI cannot function without it. Recorded
  consequence: identity-link rights confer tenant-wide user enumeration in
  a reduced projection, without identity/users:view.
- The roles:assign descriptor is corrected to describe what it guards.
  Setting defaultRoleIds is guarded by the ordinary subset rule, so no
  escalation was possible either way.
- The two Broker/Logout.cs endpoints declare differently: Logout is
  authenticated-only because it reads the session claim from the
  principal, ContinueLogout is anonymous because the route handle carries
  the authority. ContinueLogout inheriting the authenticated default today
  is a probable live bug -- the identity provider redirects the browser
  there during upstream logout, possibly after the Elsa session is gone.
  The fail-closed gate surfaced it; this work did not introduce it.
- T028 splits four ways along resource-group seams (31/20/15/12 files)
  rather than landing as one 78-file pull request.

Two model gaps followed, one closed and one recorded:

- FR-019 now accepts a third declaration state, authenticated-only.
  Logout needs an identity but no grant, which the two-state rule could
  not express without either a fabricated permission or a gate exemption,
  and an exemption list is a hole in a fail-closed guarantee.
- Conjunctive requirements remain unexpressible. An endpoint declares one
  resource and one verb, so "needs link rights and user read" cannot be
  stated declaratively. Recorded so the next case is not solved ad hoc.

Refs #7974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: link the authorization review follow-ups

Refs #7976, #7977

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: mark T062 complete

The five module-owner questions are resolved and folded into the
vocabulary, so Phase 2 is unblocked.

Refs #7974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: address review findings on the authorization model

Automated review on #7978 surfaced several genuine gaps. Two changed the
model rather than the prose.

A bare `*` now parses as `*:*`. FR-021 forbids a superuser sentinel while
D2 requires a stored `*` to keep authorizing so no instance locks itself
out, and the seed default is ["*"]. These are reconciled at the parse
layer rather than the evaluation layer: a string with no colon consisting
solely of `*` normalizes to resource `*`, verb `*`. The evaluator never
sees a sentinel, so FR-021 holds.

Wildcards are validated structurally, not against the catalog.
`workflows/*` matches no single descriptor and `*` is deliberately absent
from supported verbs, so naive descriptor validation would have rejected
the grants US1 is built on. Concrete resources and verbs validate against
the registry; wildcard segments are accepted when syntactically well
formed, including when they match nothing today, since installing a
module later is what gives such a grant meaning. Adds FR-012a and
T022a/T022b, which also close a real gap: the role write paths persist
request.Permissions after only the caller-subset check, and no task had
wired registry validation into them.

Also:
- Counts corrected to 47 resources and 23 verbs; the PR said 45/21 and
  the tracking issue 44/21, having drifted as resources were added
- Post-design constitution re-check performed and recorded, with the 17
  module-specific verbs called out as a Principle VII note
- T025 scoped to descriptor consistency; it asserted endpoint resolution
  during Phase 2, when endpoints still declare legacy strings
- T047a carries the security stamp's provider migrations, so Phase 4 no
  longer depends on Phase 5 to be shippable
- T038a covers wildcard containment in RoleAuthorizationService
- Staleness guidance corrected: the catalog and reach report are registry
  snapshots, not token projections
- Abbreviated migration rows (`:write`, `:delete`, `:update`) spelled out
  so the table is mechanically checkable
- rest-api.md now lists all three endpoints and their differing access
- American English throughout, per the constitution

Refs #7974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* docs: publish the migration guide alongside the contract

The vocabulary contract named docs/migrations/authorization-model.md as
the authoritative source for converting stored permissions, but the file
lived only on the implementation branch. A design change that
intentionally stops legacy grants authorizing must not point operators at
an upgrade guide it does not ship: following a dangling reference is how
roles get silently narrowed, or non-admin roles locked out, during an
upgrade.

Publishes the guide and ADR 0012 here, and marks T057-T061 complete. The
contract's reference is now a working relative link.

Refs #7974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 16:19:22 +02:00
.agents/skills feat: introduce HTTP webhooks module 2026-08-03 02:08:15 +02:00
.claude/skills Updated AGENTS.md 2026-07-15 00:08:42 +02:00
.config Fix Race Condition Causing Duplicate Trigger Registration in Multi-Engine Environments + Add Concurrency Tests to Prevent Regression (#7131) 2025-12-05 09:17:14 +01:00
.github fix: quote API key secrets in dotnet nuget push to prevent argument parsing failure (#7951) 2026-08-17 23:46:25 +02:00
.nuke Upgrade to NUKE 9.0.4 and fix automatic workflow generation 2025-01-26 19:29:19 +02:00
.specify Merge release/3.8.0 into main 2026-08-14 11:59:35 +02:00
.vscode docs: ratify constitution v1.0.0 (7 principles from codebase analysis) 2026-03-08 15:49:20 +01:00
announcements Skills 2026-06-25 15:19:31 +02:00
build build: bump NuGet.Packaging to 7.9.0 to unbreak the NUKE build on SDK 10.0.400 2026-08-11 23:25:33 +02:00
design chore: apply safe dependency upgrades (#7896) 2026-07-26 21:42:27 +02:00
doc fix(features): support features introduced during Module.Apply() (#7966) 2026-08-20 23:53:07 +02:00
docker [codex] Fix console log metadata and type resolution (#7542) 2026-05-30 22:52:01 +02:00
docs docs: authorization model design (spec 013) (#7978) 2026-08-24 16:19:22 +02:00
gen Update DSL and sample 2022-03-28 13:25:45 +02:00
scripts [codex] Fix console log metadata and type resolution (#7542) 2026-05-30 22:52:01 +02:00
specs docs: authorization model design (spec 013) (#7978) 2026-08-24 16:19:22 +02:00
src fix(external-auth): make the upstream logout continuation reachable (#7979) 2026-08-23 23:53:40 +02:00
test fix(external-auth): make the upstream logout continuation reachable (#7979) 2026-08-23 23:53:40 +02:00
.editorconfig Refactor to use target-typed object creation 2025-01-09 10:27:55 +01:00
.gitignore chore: anchor the Release/ ignore pattern to the repository root 2026-08-22 23:06:17 +02:00
AGENTS.md Updated AGENTS.md 2026-07-15 00:08:42 +02:00
build.cmd Upgrade to NUKE 8.1 (#5952) 2024-09-12 09:56:06 -07:00
build.ps1 Upgrade to NUKE 8.1 (#5952) 2024-09-12 09:56:06 -07:00
build.sh Upgrade to NUKE 8.1 (#5952) 2024-09-12 09:56:06 -07:00
CLAUDE.md chore: make agent instructions feature-neutral 2026-07-14 23:03:03 +02:00
CONTEXT.md Add output converter support at binding boundaries 2026-07-31 04:10:48 +02:00
CONTRIBUTING.md Enhance CONTRIBUTING.md with feature request guidelines 2026-04-14 11:37:12 +02:00
Directory.Build.props Addresses warnings and enforces null safety (#7050) 2025-11-12 15:53:23 +01:00
Directory.Build.targets Add shell middleware, call‑stack tracking, and workflow reference graph APIs (#7333) 2026-02-28 21:16:04 +01:00
Directory.Packages.props feat(bpmn): adopt Bpmn.* 0.2.0, and start shipping the two BPMN modules (#7970) 2026-08-21 01:44:07 +02:00
dotnet-install.sh Add ActivityCompleted notification for workflow activity completion (#6675) 2025-05-24 23:01:41 +02:00
Elsa.sln fix(features): support features introduced during Module.Apply() (#7966) 2026-08-20 23:53:07 +02:00
Elsa.sln.DotSettings feat: extend shells integration and modular server support (#7399) 2026-04-18 14:33:34 +02:00
icon.png Debug 2022-12-20 12:47:41 +01:00
jordi-delay-bookmark-reply.md Skills 2026-06-25 15:19:31 +02:00
LICENSE
NuGet.Config feat(bpmn): adopt Bpmn.* 0.2.0, and start shipping the two BPMN modules (#7970) 2026-08-21 01:44:07 +02:00
pau-delay-dispatch-response.md Skills 2026-06-25 15:19:31 +02:00
README.md [codex] Fail fast on default JWT signing keys (#7496) 2026-05-20 22:30:49 +02:00
ROADMAP.md docs: refresh roadmap 2026-08-19 00:06:14 +02:00
run-dsl-tests.sh Add Elsa Script DSL (#7076) 2025-11-25 19:57:50 +01:00
test-flowchart.txt Add Elsa Script DSL (#7076) 2025-11-25 19:57:50 +01:00
test-simple-flowchart.elsa Add Elsa Script DSL (#7076) 2025-11-25 19:57:50 +01:00

Elsa Workflows

Elsa Workflows

Elsa 3 Prerelease Nuget (with prereleases) Feedz Docker Image Version (latest semver) Discord Stack Overflow questions Gurubase DeepWiki

For Elsa 2, Click Here

Introduction

Elsa is a powerful workflow library that enables workflow execution within any .NET application. Elsa allows you to define workflows in various ways, including:

  • Writing C# code
  • Using a visual designer
  • Specifying workflows in JSON

Elsa ships with a powerful visual designer

Try with Docker

To give the Elsa Studio + Elsa Server a quick spin, you can run the following command to start the Elsa Docker container:

docker pull elsaworkflows/elsa-server-and-studio-v3:latest
docker run -t -i -e ASPNETCORE_ENVIRONMENT='Development' -e HTTP_PORTS=8080 -e HTTP__BASEURL=http://localhost:13000 -p 13000:8080 elsaworkflows/elsa-server-and-studio-v3:latest

This Docker image is based on a reference ASP.NET application that hosts both the workflow server and designer and is not intended for production use.

For any non-development deployment, inject a secure random JWT signing key through environment variables or a secrets manager instead of using committed appsettings values. For code-first hosts such as Elsa.Server.Web, set Identity__Tokens__SigningKey. For shell-based hosts, set the shell feature key, for example CShells__Shells__Default__Features__Identity__SigningKey.

By default, you can access http://localhost:13000 and log in with:

  Username: admin
  Password: password

TLS and custom certificate authorities

All Elsa Docker images now ship with the operating system's certificate authority bundle baked in at build time. This means you can call public HTTPS endpoints such as https://example.com without any additional configuration.

If you need to trust a private or corporate CA, mount the certificate bundle into the container and reference it via EXTRA_CA_CERT:

docker run \
  -v /path/to/company-ca.crt:/certs/company-ca.crt:ro \
  -e EXTRA_CA_CERT=/certs/company-ca.crt \
  elsaworkflows/elsa-server-and-studio-v3:latest

On startup, the container copies the certificate into /usr/local/share/ca-certificates and runs update-ca-certificates, making the trust available to .NET, OpenSSL, curl, and other system components. Multiple certificates can be provided by pointing EXTRA_CA_CERT at a directory containing .crt or .pem files.

In highly restricted environments where you cannot modify the system trust store, you can instead rely on the standard SSL_CERT_FILE or SSL_CERT_DIR environment variables:

docker run \
  -v /path/to/company-ca-bundle.pem:/certs/custom.pem:ro \
  -e SSL_CERT_FILE=/certs/custom.pem \
  elsaworkflows/elsa-server-and-studio-v3:latest

ℹ️ Installing the CA bundle adds roughly 300KB to the Debian-based images. No package managers run at container startup; all trust updates happen immutably at build time or via the mounted certificates shown above.

Table of Contents

Documentation

Elsa Documentation Website.

Known Issues and Limitations

Elsa is continually evolving, and while it offers powerful capabilities, there are some known limitations and ongoing work:

  • Documentation is still a work in progress.
  • Input/Output is not yet implemented in the Workflow Instance Viewer.
  • Starting workflows from the designer is currently supported only for workflows that do not require input and do not start with a trigger; this is planned for a future release.
  • The designer currently only supports Flowchart activities. Support for Sequence and StateMachine activities is planned for a future release.
  • UI input validation is not yet implemented.

Features

Elsa offers a wide range of features for building and executing workflows, including:

  • Execution of workflows in any .NET application with support for .NET 6 and beyond.
  • Support for both short-running and long-running workflows.
  • A programming model loosely inspired by Windows Workflow Foundation.
  • A web-based drag & drop designer with support for custom activities.
  • Native support for activity composition, including activities like Sequence, Flowchart, and ForEach.
  • Parallel execution of activities.
  • Built-in activities for common scenarios, such as sending emails, making HTTP calls, scheduling tasks, sending and receiving messages, and more.
  • Workflow versioning and migration via API.
  • Easy integration with external applications via HTTP, message queues, and more.
  • Actor model for increased workflow throughput.
  • Dynamic expressions with support for C#, JavaScript, Python, and Liquid.
  • Persistence agnostic, with support for Entity Framework Core, MongoDB, and Dapper out of the box.
  • Elsa Studio: a modular Blazor dashboard app for managing and designing workflows.

Roadmap

See ROADMAP.md for the current roadmap and #3232 for historical roadmap discussion.

Use Cases

Elsa can be used in a variety of scenarios, including:

  • Long-running workflows such as order fulfillment and product approval.
  • Short-running workflows such as sending emails and generating PDFs.
  • Scheduled workflows such as sending daily reports.
  • Event-driven workflows such as sending welcome emails when a user signs up.

Coding Workflows

Elsa allows you to define workflows in code using C#. The following example shows how to receive HTTP requests and send an email in response:

public class SendEmailWorkflow : WorkflowBase
{
    protected override void Build(IWorkflowBuilder builder)
    {
        builder.Root = new Sequence
        {
            Activities =
            {
                new HttpEndpoint
                {
                    Path = new("/send-email"),
                    SupportedMethods = new(new[] { HttpMethods.Post }),
                    CanStartWorkflow = true
                },
                new SendEmail
                {
                    From = new("alic@acme.com"),
                    To = new(new[]{ "bob@acme.com" }),
                    Subject = new("Your workflow has been triggered!"),
                    Body = new("Hello!")
                }
            }
        };
    }
}

Designing Workflows

Elsa allows you to define workflows using a visual designer. The following example shows how to receive HTTP requests and send an email in response:

Elsa ships with a powerful visual designer

Contributing

We welcome contributions from the community and are pleased that you are interested in helping to improve the Elsa Workflow project! Here are the steps to contribute to our project:

1. Fork and Clone the Repo

To get started, you'll need to fork the repository to your own GitHub account. You can do this by navigating to the Elsa Workflow GitHub repository and clicking the "Fork" button in the top-right corner of the page. Once you have forked the repo, you can clone it to your local machine using the following command:

git clone https://github.com/YOUR_USERNAME/elsa-core.git

Replace YOUR_USERNAME with your GitHub username. For more information on forking a repo, check out the GitHub documentation here.

Incorporating the details about the "apps" folder and its projects into the second point about opening the Elsa.sln using your favorite IDE, we can expand the instructions to guide developers on where to start and what projects they might want to explore first. Here's an updated version of that section with the additional information:

2. Open Elsa.sln Using Your Favorite IDE

After cloning the repository, navigate to the cloned directory and open the Elsa.sln solution file with your preferred IDE that supports .NET development, such as Visual Studio, JetBrains Rider, or Visual Studio Code with the appropriate extensions.

Within the solution, you will find an "apps" folder containing three projects designed to help you get started and explore the capabilities of Elsa Workflow:

  • Elsa.Server.Web: This project is a reference ASP.NET Core application that acts as a workflow server. It's a great starting point if you want to understand how Elsa functions as a server-side workflow engine.

  • Elsa.ServerAndStudio.Web: This project serves a dual purpose. Like Elsa.Server.Web, it acts as a workflow server. Additionally, it hosts the Elsa Studio Blazor WebAssembly app. This is the perfect project to run if you want to see the full capabilities of Elsa, including both the server aspects and the client-side studio experience in one application.

  • Elsa.Studio.Web: This project is a reference Blazor WebAssembly application that solely hosts the Elsa Studio Blazor WebAssembly app. It requires a running Elsa server application to connect to. Use this project if you're interested in focusing on the Elsa Studio UI and its interactions with an Elsa workflow server.

3. Submit a PR with Your Changes

Once you have made your changes, commit them and push them back to your fork. Then, navigate to the original Elsa Workflow repository and create a new Pull Request. Ensure your PR description clearly describes the changes and any relevant information that will help the reviewers understand your contributions. For a detailed guide on creating a pull request, visit Creating a pull request from a fork.

4. Open an Issue First

Before you start working on your changes or submit a pull request, please open an issue to discuss what you would like to do. This step is crucial as it ensures you don't spend time working on something that might not align with the project's goals or might already be under development by someone else. You can open an issue here.

This approach helps us streamline contributions and ensures that your efforts are aligned with the project's needs and priorities. We look forward to your contributions and are here to support you throughout the process. Thank you for contributing to the Elsa Workflow project!

Support

There are various ways to get support for Elsa Workflows, ranging from community-driven channels to enterprise-level services.

Community Support

Elsa has an active and helpful community where you can find support through multiple channels:

  • GitHub Issues for bug reports and feature requests.
  • GitHub Discussions for open-ended conversations, questions, and community-driven support.
  • Discord for real-time support and interaction with the Elsa community.
  • StackOverflow for searching or asking technical questions.

Professional Support

For organizations requiring professional support and long-term commitment, check out Elsa+, a growing ecosystem of premium services, tooling, and extensions around Elsa Workflows.