Multi-App Workflows

[JoshVanL]

No description provided.

[olitomlinson]

+1 for this proposal...

...as long as security boundaries are not broken. If they are broken, then a viable permission model is accompanied to allow a developer to specify which external Apps are allowed to call management operations on the Host Workflow Application*, which defaults to secure-by-design / zero trust)

Host Workflow Application is the application where the Workflow is registered.

[WhitWaldo]

My only note here would be that if the specified app ID cannot be found, or the type cannot be found on the app ID or just generally something happens that is unexpected (e.g. security boundary violation), it'd be nice to have some context in the error returned by the runtime to the SDK so it can be handled and addressed programmatically and clearly instead of requiring an Easter egg hunt by the developer after the fact to figure out why it broke (e.g. today it just returns a 500 for either of the first two scenarios) - recent request for this on Discord.

[cicoyle]

+1 binding although Ik based on the PRs I currently have open that the protos might differ slightly but overall the logic is sound. Protos can be updated afterwards 👍🏻

[olitomlinson]

@cicoyle curious how your implementation so far (and implementations to come) will challenge/change the existing security boundaries as I have outlined in my feedback above :)

[JoshVanL]

+1 binding

[yaron2]

+1 binding

[olitomlinson]

It saddens me to see this proposal merged without receiving any feedback to what I believe are valid questions around how this impacts the existing workflows security model.

[yaron2]

It saddens me to see this proposal merged without receiving any feedback to what I believe are valid questions around how this impacts the existing workflows security model.

Forgot to update here @olitomlinson. We took this into consideration, the implementation supporting this proposal keeps the existing security posture as-is: apps that participate in a workflow cannot use the management API to alter the workflow. Only the app that registered it can do that

[olitomlinson]

I forgot to remind about this security consideration here @cicoyle - has this being catered for in the implementation?

dapr/dapr#8578 (comment)

Potential areas of concern - Discoverability of Activities across App-boundaries

• Apps are the security boundary of workflows and their registered Activities.
• Allowing Activities to be used from outside of the App boundary would create a security hole.
  • Therefore we must have a way to mark each Activity as discoverable, so that it can be discovered and used by one or more other Apps in the mesh. Dapr already has an ACL concept for Service Invoke, can we extend the ACL with Workflows in the same/similar manner?