Caller identity

A Pulse run uses two distinct identities, and keeping them separate is what makes the model both safe and useful.

Why two identities #

Topologies are system-wide, and the applications their connectors call are installed once under the system user. If a run executed under each caller's own id, the worker's credential lookup would fail. So execution always borrows the shared system identity.

But many processes still need to know who is asking. An employee filing a vacation request, for example, must not be able to file it for someone else. The identity header carries the authenticated caller's email so the topology can use it, without giving the caller access to the underlying credentials.

Reading it in a worker #

The identity header is available on the incoming message in any node. In the Node.js SDK:

import ACommonNode from '@orchesty/nodejs-sdk/dist/lib/Commons/ACommonNode';
import ProcessDto from '@orchesty/nodejs-sdk/dist/lib/Utils/ProcessDto';

export default class IdentityEchoNode extends ACommonNode {
    public getName(): string {
        return 'identity-echo';
    }

    public processAction(dto: ProcessDto): ProcessDto {
        const identity = dto.getHeader('identity', '');
        return dto.setData(`Your email is: ${identity}`);
    }
}

It cannot be tampered with #

identity is a protected header: it is set by Pulse when the run starts and no worker can overwrite it. It survives every hop, all the way to the response node, so a process can rely on it as the source of truth for who triggered the run.

Where to go next #

• For your team: user identity and groups
• Async and the response node