Without a configured Authorizer, Temporal defaults to noopAuthorizer, which permits all API requests without authentication or access restrictions. This means any client with network access to your Temporal Server can execute any operation, including critical administrative tasks. Such an open configuration is unsuitable for production environments or systems exposed to untrusted networks.

The authorizer plugin enables fine-grained access control based on user roles, groups, and claims from your identity provider. It supports namespace-aware and operation-specific permissions, which allows you to enforce restrictions on UI access, workflow visibility, and API operations.

We developed this image following the documentation for the Temporal Authorizer plugin and examples from the samples-server/extensibility/authorizer.

Integrating with your OIDC Provider

The authorizer evaluates claims issued by your identity provider. Configure your provider to issue claims that map to Temporal namespaces and permissions. How you structure those claims (roles, groups, attributes) is up to you.

Example: Keycloak client roles

Create client-scoped roles that mirror the permissions you plan to grant. For example:

default:admin
default:read
default:worker
default:write
temporal-system:admin
temporal-system:read
temporal-system:write

In the client's scope, add a mapper of type User Client Role that collects those roles into a claim (we use permissions).

Verify the generated access/ID tokens expose the permissions claim:

{
  "permissions": [
    "temporal-system:admin"
  ]
}

The Temporal authorizer configuration maps these claim values (like temporal-system:admin) to specific permissions. Providers like Authentik, Okta, or Auth0 can produce similar claims through group mappings, custom scopes, or policy rules.

Tagging Convention

We tag images based on the version of the Temporal server package and a revision number for changes to the image itself.

The tag format is X.Y.Z-R, where:

X.Y.Z is the version of Temporal server (e.g., 1.29.0).
R is a revision number for changes to the image (e.g., 1, 2, etc.).

Increment the revision number R if the Temporal server version X.Y.Z remains the same. If the Temporal server version changes, reset R to 1.

We set the image tag and Temporal version as environment variables before building the image:

export GO_VERSION=A.B
export TEMPORAL_VERSION=X.Y.Z
export TAG=${TEMPORAL_VERSION}-R

Development

Building the container image

Build the container image for your local platform to test before publishing:

docker buildx build \
  --file Containerfile \
  --no-cache \
  --build-arg GO_VERSION=$GO_VERSION \
  --build-arg TEMPORAL_IMAGE=temporalio/auto-setup:$TEMPORAL_VERSION \
  --build-arg SOURCE_COMMIT=$(git rev-parse HEAD) \
  --build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ') \
  -t git.coopcloud.tech/wiki-cafe/temporal:latest \
  -t git.coopcloud.tech/wiki-cafe/temporal:$TAG \
  --load .

Publishing the container image

After building and verifying the container image locally, push it to the registry.

Note: Due to registry timeout issues with direct --push during build, we push each tag separately rather than using --push with buildx.

docker push git.coopcloud.tech/wiki-cafe/temporal:$TAG
docker push git.coopcloud.tech/wiki-cafe/temporal:latest

Deployment

The custom server binary expects configuration to be mounted at runtime. Set the following environment variables when running the container:

TEMPORAL_CONFIG_DIR: Path to the directory containing Temporal configuration files (must include authorization settings)
TEMPORAL_CONFIG_ENV: Environment name for config loading (defaults to development)

Example authorization configuration should be included in your mounted config to enable claim mapping and role-based access control.