I want to ensure worker authorization upon execution, signal, or query. For example, is this worker authorized to execute a given query against the given workflow execution. Another example: provide broad access to query a workflow execution and limit access to signal a workflow execution.
I see the execution intercepter and do not see signal or query interceptors - which if these exist I believe they’d fulfill my need.
I’m unclear if Temporal’s authorization API can operate at this granularity. If it can operate at that granularity, I’d like to be able to use Temporal’s hosted solution and I’m unclear if I’d have access to add my own authorizer.
The isolation provided by namespaces is too blunt a tool for the desired granularity.
What options do I have to check signal and query authorization?
Please help me understand a couple of things about your scenario in order to answer your question intelligently.
Are you looking for a way to perform authorization decision on the server side (via the authorization API)? I assume so because presumably you can’t trust the worker. If that’s the case, then why do you need execution interceptors on the worker side? All API calls from the worker would go through the server-side authorizer where you can allow or reject individual calls based on the API (like signal and query), namespace, arguments, TLS certificate if any, and additional information that can be passed with an optional bearer token.
When you say “Temporal hosted solution”, do you mean Temporal Cloud that we are building or something else? The above description assumes you are running Temporal open source Server, and have full control over the authorization logic. Temporal Cloud is a different case altogether, obviously.
I’ll chime in here and mention that this is also similar to something we’d like to do. We’d like to be able to authorize not just by bearer token. API name, and target namespace, but only permit certain clients to execute particular workflows or activities. Is authorizing based on “arguments” something the current authorizer/claimsmapper interface allows for?
“Temporal hosted solution” is indeed what we’re thinking of as the Temporal Cloud, where we want to pay you guys to get the extra magic bits that you’re going to provide. For now we’re doing a research spike and have not deployed Temporal into production.
Thank you for the clarification, @metapete. Questions related to Temporal Cloud we should take to a private channel, as it is not a generally available product yet. Will be more than happy to dive into details there.
I want to separate authorization code from the business logic. It’s not that I don’t trust the worker its that I don’t want to trust business logic developers to get authorization correct. Each workflow will have different authorization logic associated with it. Having this logic live in the server rather than the worker is an architectural complication I’d like to avoid and I’d prefer a solution that allows for the use of Temporal Cloud.
Certainly this could be solved by a layer of indirection. Such an indirection would enforced either by error-prone discipline or by an abstraction of the Temporal SDK. Such an abstraction wouldn’t come close to the feature set and design of the Temporal SDK. Signal and query interceptors on the worker would allow business logic developers and security focussed developers to directly use the well designed Temporal SDK while maintaining separation of concerns.
Happy to provide concrete example and/or move discussion to a private channel.
I’ll try to restate the general scenario and ask here. Please correct me if I got it wrong.
There’s a need to execute additional code on a per-operation basis to either block some operations or to enrich their context in such a way that the business logic of workflows is oblivious to that happening. This is not a security feature, more like guardrails and helpers for business logic developers.
Interceptors are a typical approach for such cross-cutting concerns, and in this case it makes sense to have them do the job on the client (SDK) side. The blocking issue is that interceptor APIs are incomplete to cover all key SDK use cases.