Skip to content

security: require trusted workflow principals - #272

Open
ralphhanna wants to merge 1 commit into
refactor/separate-admin-apifrom
security/trusted-principal
Open

security: require trusted workflow principals#272
ralphhanna wants to merge 1 commit into
refactor/separate-admin-apifrom
security/trusted-principal

Conversation

@ralphhanna

Copy link
Copy Markdown
Collaborator

Summary

Removes implicit or caller-controlled workflow identity from the engine boundary.

  • Requires a trusted principal for execution operations
  • Removes the runtime API default-user fallback
  • Rejects calls where the integration layer did not establish a principal
  • Documents the security change in CHANGELOG.md

Stack

Depends on refactor/separate-admin-api (#2). There is no server-side #3 change.

Validation

  • 3/3 server API boundary tests pass.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b796e5260e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/API/API.ts
Comment on lines 60 to +62
getUser(user) {
if (!user)
return this.api.defaultUser;
else
return user;

if (!user) throw new Error('A trusted authenticated principal is required');
return user;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Require a principal for workflow upgrades

When a runtime integration calls api.engine.upgrade(model, afterNodeIds), that method bypasses this new principal check entirely and invokes server.engine.upgrade without any user argument. The server implementation then replaces the stored source for every matching running instance, so an untrusted runtime client can still perform a cross-instance workflow mutation despite the new authenticated-principal boundary; route upgrade through this check or move it to the privileged API.

Useful? React with 👍 / 👎.

Comment thread src/API/API.ts
continue with the execution of a particular item that is in a wait state, typically a user task
*/
invoke(query, data: {}, user?: ISecureUser, options?:IEngineOptions): Promise<IExecution>;
invoke(query, data: {}, user: ISecureUser, options?:IEngineOptions): Promise<IExecution>;

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Require principals in the concrete APIEngine signatures

These interface changes do not affect the normal exported API type: BPMNAPI.engine is declared as the concrete APIEngine, whose start, invoke, assign, throwMessage, throwSignal, and startEvent implementations still declare user?. Consequently, a TypeScript consumer using new BPMNAPI(...).engine.invoke(query, data) compiles successfully and only fails at runtime, rather than receiving the intended compile-time requirement; update the concrete method signatures as well.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant