Authorization, Untrusted workflow creation and namespace authentication

Community Support
1

Hello all,

I have a question on the authorization around Temporal that’s existent at this point.

  1. Can we contribute to anything ASAP and/or use anything existent that would prevent tenants from seeing/accessing/subscribing to each other’s namespaces?

At the moment there’s nothing that prevents people from doing the above (as far as I saw). We don’t really want to have different namespaces (workflows, workers, etc.) have access to each other, see their workflows’ data, etc.

In addition (correct me if I am wrong please), I saw that there is no mechanism to authenticate the registration to a task queue/task list.

Thank you,

Marius

1 Like
3

Hey, sorry it took a while to get back to you. The direct answer is that neither Cadence or Temporal support any form of fine grained access control or authentication out of the box. Temporal does support mutual TLS over GRPC which actually does provide a means to achieve secure namespace isolation. I honestly am not educated enough to explain how this will work at the lowest level, but the gist is that you use custom TLS certs for different users/namespaces.

I’ll let Max chime in if there is anything that you can contribute.

4

Hi @ryland or @maxim, I’m wondering if there is any update on namespace level access control? Seems this is an important piece missing.

5

We’ve supported both authentication and authorization for a few months now!

Let me know if you have any other questions.

1 Like
6

Thanks @ryland ! After reading the page, I’m still a little confused as how this works. How do I set up who has access to a namespace and how to use the temporal sdk to provide the credential? It would be great if you have any java examples.

1 Like
7

@SergeyBykov

8

We have a Go sample - customization-samples/extensibility/authorizer at master · temporalio/customization-samples · GitHub of how one can implement authorization logic. Temporal server by itself does not impose any authorization. It is the job of the pluggable Authorizer and ClaimMapper components. ClaimMapper is responsible for translating identity information of the caller, from the TLS cert and/or JWT token, into a set of role claims that Authorizer uses as input for authorization decisions.

2 Likes
9

Hi,
I would like to understand about how the same can be achieved using Java SDK. It would be really helpful to see some java sample on that, as the same is not clear through documentation.

10

Created Issue Add Authorizer+Claims Mapper sample · Issue #234 · temporalio/samples-java · GitHub

11

Thanks a lot for the help @tihomir. Will be waiting for the java sample.

12

@tihomir Is there any update on this? May I know the timelines for the same…if any…

13

@poojabhutada i am planning to add sample this week

14

Thanks @tihomir for the update…!

15

@poojabhutada was looking at this and not sure if it fits in our java samples repo, probably is better suited for a small demo app which would indeed be nice to have.
Reason is that we already as shown here have a server sample that shows how to set up claims mapper and authorizer, and we also have this docs page that shows how to provide auth tokens via java sdk.
I think with this you would just need to generate your JWT tokens for example and start using it.

16

@tihomir Do you mean that we need to write custom authorizer and claimmapper in Golang in order to manage the incoming calls through JWT token and then deploy the custom Temporal server image on our own?

17

You don’t have to write a custom one, you can use the defaults based on JWT. You can configure it, in case you are using docker compose yml:

global:
  authorization:
    jwtKeyProvider:
      keySourceURIs:
      - <source url>
      refreshInterval: 1m
    authorizer: default
    claimMapper: default

or if docker image, via env vars, for example:

TEMPORAL_JWT_KEY_SOURCE1=<source url>
TEMPORAL_AUTH_AUTHORIZER=default
TEMPORAL_AUTH_CLAIM_MAPPER=default

Where <source url> is an HTTP endpoint that hosts your public keys used to sign tokens (JWK format).
Your tokens permissions claim is used to determine what client can do.

You can provide token supplier via WorkflowServiceStubsOptions as shown in link.

18

Ok @tihomir . Thanks a lot for the clarification, will check further on this.

19

Hi @tihomir

follow up query on this point, can a function be passed as a AuthorizationTokenSupplier , for eg:

AuthorizationTokenSupplier tokenSupplier = () -> return restTemplate.get("http-endpoint-which-returns-jwt-tokens");

also, in one scenario, i’ll be getting the token from the caller of workflow, is it possible to provide that token in the above supplier?

21

How should the token permissions look like? plz share sample

22

Please document this in Temporal Cluster deployment guide | Temporal Documentation
And also: Temporal Cluster configuration reference | Temporal Documentation

I can’t find any docs mentioned this, now I reviewed the config template under /docker/config_template.yaml . This is really unfriendly for bare-metal users.

I just searched a lot… and finally found here after several hours…

1 Like