elsa-workflows / elsa-workflows/elsa-foundation
RBAC: Project scoped external-provider session grants
- Dominant language
- C#
- Stars
- 5
- Forks
- 1
- Avg merge
- 3h 52m
- Merged PRs (30d)
- 212
Description
## Parent
- #806
## What to build
Normalize trusted external-provider mappings into scoped session authority that participates in the same effective-permission decision without becoming a hidden durable local grant. Server reports the provider source, target scope, freshness mode, and expiry; Studio presents that authority and its refresh boundary accurately.
Local account, membership, and authorization-scope constraints remain mandatory, and tenant-A provider mappings cannot authorize tenant B.
Covers PRD user stories 26-27, 31, 33-38, 75-80, 95, and 98.
## Acceptance criteria
- [ ] A validated provider mapping can grant scoped session roles or permissions without creating a durable local direct grant.
- [ ] Provider grants are resolved for exactly one authorization scope and never cross tenants through claims, caches, sessions, or Studio state.
- [ ] Active account, tenant membership, token validity, and scope constraints can veto provider authority.
- [ ] The session and effective-access contracts identify the provider grant source, freshness mode, issued/expiry information, and whether reauthentication or introspection is required.
- [ ] Studio distinguishes externally sourced session authority from local role assignments and does not describe it as immediately revocable when the provider contract cannot guarantee that.
- [ ] Tenant switching discards the prior provider-derived tenant permission state.
- [ ] Explanation and audit disclosure follows self, scope-admin, support, and redacted non-enumerating boundaries.
- [ ] Server identity-provider, session, HTTP, and Studio tests prove scoped mapping, expiry/refresh behavior, local constraints, tenant isolation, and honest presentation.
## Blocked by
- #829
Contributor guide
No contributing guide indexed for this repository
Research direction
Review blocked issue #829 and parent #806 first, then trace the server identity-provider, session, HTTP, and Studio areas named in the acceptance criteria. The work is done when scoped provider authority, expiry and refresh behavior, local constraints, tenant isolation, disclosure boundaries, and honest Studio presentation are covered by the required server and Studio tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api, authorization, frontend, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100