Temporal SSO and authorization guide

How to secure Temporal SSO and authorization before go-live

Sign-in alone does not limit what a user can do on a self-hosted Temporal cluster, so single sign-on and authorization must be designed together before go-live. Out of the box, Temporal falls back to the default noopAuthorizer when no Authorizer is configured, and that default allows every API request with no authentication or access control. For a cluster that holds workflow data for several teams, this means anyone who can reach the frontend can start, query or terminate workflows in any namespace. Your first task is to replace that default with a deliberate access model, and to confirm which authorization settings your server version exposes for doing so.

The Web UI can sign users in through OIDC single sign-on, but that step only establishes identity. The ClaimMapper reads claims from JWTs or certificates and maps them to namespace roles, and the Authorizer uses those roles to decide what each request may do in each namespace. Four things must agree for this to work: the identity provider must issue the claims you expect, the claim names and values must match what the ClaimMapper reads, namespace boundaries must match how your teams are organized, and the Web UI session must not carry more access than the roles grant. A mismatch in any one of these can silently widen access or lock out operators. Decide the namespace-to-team mapping first, then design the claims to express it.

Network exposure is the fourth dependency. Claims and roles only mean something if callers cannot reach the frontend by a path that skips the identity check. Temporal's deployment guidance says services should run on hosts that are not reachable from the public internet, with access limited to trusted internal networks. Confirm which clients connect to the frontend directly, such as workers, automation and internal tooling, and whether each one authenticates in a form the ClaimMapper understands. Workers and scheduled jobs usually run under service identities rather than people, so plan separate claims for them and test that each service identity receives only the namespace roles it needs.

Temporal Cloud handles this differently. According to the Temporal pricing page, it supports SAML SSO on pay-as-you-go plans, and SCIM provisioning is included on the Enterprise and Mission Critical support tiers. The design work therefore shifts away from writing ClaimMapper rules and operating your own Authorizer, and toward mapping identity provider groups to Cloud roles and namespaces and automating user lifecycle. Confirm with Temporal which SSO and provisioning features your plan includes before you commit to a design. Whichever model you choose, document who owns each identity source, who approves role grants, and how access is removed when someone changes teams or leaves. Those decisions determine whether go-live is secure, and they matter more than the sign-in screen.

Which Temporal components control sign-in and access

Access to a self-hosted Temporal Service is decided by several separate components: the frontend API, the Web UI, the claim and authorization plugins, and the transport encryption between services. Temporal Cloud covers similar ground with its own SAML SSO and SCIM features, so the team must decide which controls apply to its deployment and who maintains each one.

Frontend API authentication path

The frontend service is the entry point for SDK clients, workers, tooling and the Web UI. Every request reaching it passes through the configured authentication path before any authorization check runs. Confirm which claim and certificate inputs the frontend accepts for your server version, and confirm that the frontend is not reachable from the public internet, as the deployment docs advise. The team owns the network placement, the certificate and token issuance, and the testing of each client type against the frontend.

Web UI OIDC sign-in

Self-hosted Temporal supports OIDC single sign-on for the Web UI, so operators sign in through your identity provider instead of an unauthenticated browser session. This setting governs only human access to the UI, not SDK or worker traffic. Confirm the exact provider configuration keys against the current self-hosted security documentation for your server version. The team owns the identity provider application, redirect URLs, group or claim design, and the decision about who may reach the UI.

ClaimMapper for JWT and certificate claims

The ClaimMapper reads claims from a JWT or a client certificate and converts them into Temporal system and namespace roles. It is where identity provider groups become Temporal permissions, so mistakes here grant or remove access silently. Confirm the claim names, the role mapping syntax and the supported token types for your server version in the self-hosted security documentation. The team owns the mapping table, its review process and tests that prove a sample identity receives only the intended namespace roles.

Authorizer plugin decisions

The Authorizer plugin decides, for each API request, whether the caller may perform the action on the target namespace. If no Authorizer is configured, the default noopAuthorizer allows every request without authentication or access control, so this component is required for any shared cluster. Confirm the plugin's build and configuration steps for your server version. The team owns the authorization policy, the plugin's lifecycle through server upgrades, and logging of denied requests.

Frontend and internode mTLS settings

Self-hosted Temporal exposes mutual TLS with separate settings for frontend traffic from clients and for internode traffic between Temporal services. The two settings protect different paths, so enabling one does not secure the other. Confirm the exact setting names, certificate chain requirements and rotation behavior in the current self-hosted security documentation. The team owns certificate issuance, rotation schedules, the trust store for each service and the procedure for handling expired certificates.

Temporal Cloud SAML SSO and SCIM

Temporal Cloud provides SAML SSO for user sign-in, and SCIM is included on the Enterprise and Mission Critical support tiers according to the pricing page. These features replace self-hosted OIDC and ClaimMapper for Cloud users, but they do not configure self-hosted clusters. Confirm which features apply to your plan before design begins. The team owns the identity provider connection, the user provisioning and deprovisioning process, and the mapping of Cloud namespace access to groups.

Which identity and authorization model fits your Temporal deployment

This table compares the main identity and authorization choices for Temporal, from OIDC sign-in for the Web UI to a custom Authorizer and Temporal Cloud SAML SSO with SCIM. Read each row for when the option fits and what it asks your team to run and maintain. The main takeaway is that the more control you build into your own cluster, the more claim governance, custom code and identity-provider dependency you own.

Decision	Fits when	Operational cost	Watch for
OIDC sign-in for the Web UI	Engineers and operators need individual accounts in the Temporal Web UI on a self-hosted cluster	Configure an OIDC client with your identity provider and keep redirect settings current	Web UI sign-in does not by itself restrict API calls from workers or clients
Separate access path for workers and clients	Services and workers authenticate with their own tokens or certificates rather than a person's browser session	Issue, rotate and revoke credentials for each service identity	Shared or long-lived credentials make access hard to attribute during an incident
JWT claims in the ClaimMapper	Your identity provider already issues tokens with group or role claims you can map to namespaces	Ongoing claim governance: someone must own claim names, group membership and token lifetimes	Token expiry and identity-provider outages can block access during an incident
Certificate claims in the ClaimMapper	Workloads run in a platform that issues short-lived certificates per service identity	Maintain the certificate authority, issuance workflow and mapping from certificate subjects to roles	Certificate revocation and rotation must be tested before they are needed
Coarse role per namespace	Access needs are mostly team-level, with one namespace per team or application	Low: few mappings to review and a small set of roles to explain to auditors	Teams sharing a namespace cannot be separated by role alone
Finer rules in a custom Authorizer	Access depends on workflow type, operation, namespace or caller attributes that a role cannot express	Custom Go code to write, test, version and upgrade alongside each Temporal server upgrade	Authorizer bugs can block all traffic or allow requests the rules did not intend
Self-hosted cluster enforcing its own identity	Data residency, air-gapped networks or existing internal identity systems require the cluster to stay under your control	You operate the identity integration, the Authorizer and the evidence that access controls work	Assessors will expect documented access reviews for the cluster you run
Temporal Cloud with SAML SSO and SCIM	Your organization wants identity provider sign-in and user lifecycle managed centrally for a managed service	Recurring service fees; SCIM is listed on the Enterprise and Mission Critical support tiers, so confirm tier needs with Temporal	Confirm with Temporal which identity features apply to your plan and how sign-in depends on your identity provider during an outage

Temporal SSO and authorization build sequence

This sequence moves a self-hosted Temporal Service from an open starting state to one where every API request and Web UI session is tied to an identity and a namespace role. Each step closes with a check that the platform owner, security lead or test team can record as evidence. The order matters because the Authorizer and ClaimMapper depend on settled identities, and role tests only mean something once the earlier controls are in place.

Inventory namespaces, teams and service identities
The platform owner and security lead list every namespace, the teams and services that start workflows or run workers in each, and the roles each one needs, such as read-only operators or workers that poll task queues. They record which identity provider groups or service accounts map to each team. This step closes when the inventory is signed off and every namespace has a named owner and at least one approved role. Without this list, the later role decisions have nothing to be checked against.
Confirm server version and security settings
The platform engineer records the Temporal Server version, patch level and configuration in use, then compares them with the GitHub releases and the upgrade documentation. Where the installed version is behind, the team upgrades one minor version at a time to the latest patch of the current minor, running schema upgrades first when the release notes call for them. The team also confirms which Authorizer is configured, because without one the server falls back to a no-op Authorizer that allows every request. The check is a written baseline showing version, patch level, config source and Authorizer status.
Isolate the network and enforce mTLS
The platform engineer restricts access to the frontend, history, matching and worker-facing endpoints to trusted internal networks so no route exists from the public internet. The team then enables mTLS, configuring internode and frontend traffic separately and issuing certificates from an internal certificate authority with a rotation process. The security team runs an external port scan and a connection attempt without a client certificate from an allowed network. The step closes when the scan finds no Temporal endpoints exposed and the certificate-less connection is refused.
Map identity provider claims with ClaimMapper
The identity engineer configures the ClaimMapper to read the issuer, audience and group claims from the identity provider's access tokens, then maps those claims to namespace roles such as admin, writer, reader and worker. Claim names differ between identity providers, so the team confirms them from a real token issued by the provider's test tenant. For example, a token that carries a group claim for the payments team but no matching audience should yield no roles at all (illustrative). The check is a set of decoded test tokens whose mapped roles match the inventory, including a token with no claims that maps to nothing.
Set the Authorizer and default to deny
The security engineer chooses an Authorizer plugin, either one that is available for the Temporal Server or one built in-house, and implements decisions scoped to namespace and role. The default decision is set so that a request is refused unless an explicit rule allows it. The team confirms that the no-op Authorizer is no longer in place. The step closes when a request carrying a token without claims is denied, a reader token is allowed to read but refused on write operations, and the server logs record each decision.
Wire OIDC sign-in for the Web UI
The identity engineer registers the Temporal Web UI as an OIDC client with the identity provider, setting redirect URIs, scopes and the group claim that the ClaimMapper reads. The team then confirms how the Web UI passes the user's token to the server in the version being deployed, since that behavior should be checked against the current documentation rather than assumed. The step closes when an unauthenticated browser is redirected to the identity provider, a user with no mapped role sees no namespace data, and logout and session expiry end access as intended.
Plan payload encryption with a codec server
The security lead and data owners classify which workflow inputs, results and signals carry personal or regulated data, then decide which of those payloads need encryption. The platform team selects a custom codec, deploys a codec server, and agrees with the security team how its keys will be stored and rotated, using the organization's key management service where one exists. The codec server is placed behind the same authentication as the rest of the service. The step closes when a sample sensitive payload appears encrypted in workflow history and the codec server only decodes for users whose roles allow it.
Test role boundaries in each namespace
The test lead builds a matrix of namespaces against roles and the operations each role should perform, such as starting a workflow, sending a signal, running a query, terminating an execution, listing workflows and polling a task queue. The matrix is run in a staging environment and then repeated after any change to the identity provider, ClaimMapper or Authorizer. The step closes when every cell in the matrix matches the expected result and any unexpected allow is treated as a blocker for sign-off. The results are kept as evidence for the access review.

How the ClaimMapper turns JWT claims into Temporal namespace roles

The ClaimMapper decides what an authenticated caller may do. It reads claims from a JWT or a client certificate, applies the rules you define, and produces the identity that the Authorizer evaluates for each request. The unit of access in this model is the namespace role: a caller holds a role within a namespace, and the Authorizer checks that grant before a request reaches that namespace's workflows. Authentication establishes who the caller is, while the mapping establishes what that caller can do in each namespace. An identity provider can confirm that a user exists without deciding which Temporal namespaces that user should reach, so this mapping is a separate design task. The Authorizer is a plugin. If none is configured, self-hosted Temporal uses a default authorizer that allows every API request, so the mapping work cannot be skipped.

Start the design work with the identity team before anyone edits Temporal configuration. Agree on the claim that carries group or role membership, the exact claim names, the value format each identity provider emits, and how the claim appears for service accounts as well as people. Then decide who owns the mapping. In many organizations the platform team maintains the mapping file or code while the identity team owns the claim source, so changes need a path that involves both. Users who belong to several groups need explicit rules: whether roles combine, which level wins when two groups grant different access to the same namespace, and what happens when a user leaves a group. Write these rules down before the first token is tested, because every later check depends on them.

Avoid a single administrative role that spans all namespaces. It is convenient during setup, and it tends to outlive setup, so every person who holds it can read or change workflows in every team's namespace. Map roles per namespace instead, so that a team's group grants access only to the namespaces that team runs. Keep the grants for people who operate the cluster separate from those for people who deploy workers or start workflows, and give automation identities their own narrow grants. Confirm with the server documentation which role names exist for your version and what each one permits. A role with an administrative-sounding name may carry fewer rights than you expect, and a role with a narrow-sounding name may carry more.

Test each mapping with sample tokens before any team depends on it. Build one token per team, plus tokens for the edge cases most likely to fail: a user in two groups, a user in no group, a service account, and a user whose group was removed. For each token, write down the namespace roles you expect it to receive and the outcome of a small set of calls, such as starting a workflow, reading its history and listing namespaces. Run these checks against a non-production cluster, and repeat them after any change to the mapping, the identity provider or the server version. For audit, record the mapping version, the test claim sets with secret values removed, the expected and actual results, the reviewer and the date. Confirm the exact claim fields and role names in the self-hosted security documentation for the server version you run.

How Temporal SSO differs on a single node, in HA and on Kubernetes

On a single node, the Frontend, History, Matching and Worker services run together on one host, typically from Docker Compose or Go binaries. There is one place to configure OIDC for the Web UI, the ClaimMapper and the Authorizer, which makes this model useful for learning and for testing claim mapping. It is not a model for shared environments, and SQLite is meant only for development and testing.

Identity provider: The host reaches the identity provider directly, often through a test tenant. Confirm that the issuer URL resolves and is reachable from both the Web UI and the frontend process.
ClaimMapper and Authorizer: Both are set in the server configuration that the frontend loads. The default noopAuthorizer allows every request, so replace it before any shared use.
Secrets: Client secrets and certificates are usually files on the host or environment variables. Keep them out of version control and restrict file permissions.
Web UI: The OIDC client ID, issuer and redirect URL must match the host name that users type in the browser.

Before reusing these settings elsewhere, check that the redirect URLs, claim names and namespace role mappings were written for the single host and not for the production identity provider.

What drives Temporal SSO and authorization effort and cost

This table lists the drivers that change how much work Temporal SSO and authorization takes, with one practical way to keep each one down. Read each row as a question to answer before scoping, because the answers set how many claim mappings, namespace roles and certificates the project must build and operate. The main takeaway is that a shared claim schema and a small set of namespace roles usually control effort more than any single tool choice.

Driver	Why it raises effort	How to keep it down
Teams and namespaces	Each namespace needs role bindings, so effort grows with every team that gets its own namespace.	Group teams into a few namespace roles, such as reader, writer and admin, and reuse them across namespaces.
Identity providers and claim sources	Each provider or claim source adds its own issuer, audience and claim names to map and test.	Agree one claim schema for roles and namespaces, then map each provider to it once.
Custom Authorizer code	Without a configured Authorizer, the default allows every request, so any custom logic must be written, tested and maintained.	Start with role-based checks from the claim mapper, and add code only for rules those checks cannot express.
mTLS certificate management	Issuing, rotating and trusting certificates for internode and frontend traffic recurs for the life of the cluster.	Automate issuance and rotation through your existing certificate authority, and document the renewal runbook.
Web UI users and groups	Each group that signs in through OIDC needs a mapped role and an owner who approves access changes.	Map a short list of identity provider groups to namespace roles, and review membership on a regular schedule.
Environments	Development, staging and production each need their own providers, claims, certificates and role mappings.	Keep one configuration template and vary only issuers, secrets and namespace names per environment.
Compliance evidence needs	Assessors may ask for access policy, role assignments, change history and proof of certificate rotation.	Keep role mappings and configuration in version control so evidence comes from the same source as the running setup.
SCIM provisioning in Temporal Cloud	Temporal's pricing page lists SCIM with Enterprise and Mission Critical support, so the support tier affects scope.	Confirm SCIM availability and tier with Temporal before scoping, then decide whether manual user management is acceptable.

How to harden Temporal access control and secrets handling

Self-hosted Temporal allows every API request unless an Authorizer is configured, so SSO alone does not secure the cluster. The cards below cover the controls that close that gap: authorization, transport, network exposure, change control, secret storage, rotation and audit logging.

Replace the default noopAuthorizer

If no Authorizer is configured, self-hosted Temporal falls back to the default noopAuthorizer, which allows every API request with no authentication or access control. Configure a real Authorizer alongside the ClaimMapper before any namespace holds production workflows. Confirm in staging that a token without the required namespace role is rejected for both the frontend API and the Web UI.

Enforce mTLS on frontend and internode traffic

Temporal supports mTLS with separate settings for internode traffic between cluster services and frontend traffic from clients and workers. Enable both, so that a service or client without a valid certificate cannot join the cluster or call the API. Ask your team to confirm that certificate authorities, subject names and renewal procedures are documented for each traffic type.

Keep services off the public internet

The Temporal deployment documentation says services should run on hosts that are not reachable from the public internet, with network access limited to trusted internal networks. Place frontend, history, matching and worker-facing endpoints in private subnets, and expose the Web UI only through your SSO-protected access path. Review load balancer and ingress rules during each infrastructure change.

Restrict who changes ClaimMapper and Authorizer

The ClaimMapper and Authorizer decide who can do what, so changes to them are changes to the security boundary. Limit write access to the configuration repository and deployment pipeline to a named group, require review of each role mapping, and record who approved each change. Test role changes in a non-production cluster before promotion.

Store certificates and OIDC secrets in a managed store

Keep TLS private keys, certificate authority material and the OIDC client secret in a managed secret store rather than in Helm values, environment files or container images. Grant read access only to the Temporal service identities that need it. Confirm how secrets reach pods at runtime and how they are excluded from logs and support bundles.

Rotate certificates and client credentials

Set a rotation schedule for mTLS certificates, the OIDC client secret and any service tokens, and test the procedure before the first expiry. Plan overlap windows so that services can trust old and new material during the switch. Confirm that the identity provider supports rotating the client secret without downtime for the Web UI.

Log authorization decisions

Record allow and deny decisions from the Authorizer, along with the caller identity, namespace and requested operation, and forward them to your central log platform. Review denials for patterns that suggest misconfigured roles or attempted misuse. Confirm the retention period with your compliance owner and check that logs do not contain tokens or secret values.

What Temporal Cloud SAML SSO and SCIM add, and what they cost

In Temporal Cloud, the identity provider is connected through SAML single sign-on, a capability the Temporal pay-as-you-go pricing page lists. Human access to the Cloud console can then follow your identity provider's sign-in and multi-factor policies. API access by workers, clients and automation still depends on credentials issued inside the Cloud account, so SSO alone does not cover every caller. Before go-live, list each login path and each credential type in your account and confirm with Temporal which of them sit inside the SAML flow and which do not.

SCIM, the protocol that lets an identity provider create, update and deactivate accounts automatically, is included in the Enterprise and Mission Critical support tiers, according to the Temporal pricing page. The same page says Business support starts at 500 US dollars per month with a 2-hour P0 response in business hours. Confirm in writing whether Business includes SCIM. Enterprise and Mission Critical are quoted by sales, so the cost depends on the agreed terms. Ask for the exact SSO and SCIM terms in the quote, including provisioning scope, supported identity providers and any limits on users or groups.

Enabling SCIM does not finish the identity work. Your team still owns user lifecycle: who receives an account, how access changes when someone moves teams, and how a departure reaches every credential the person could use. Group-to-role mapping is the second decision. Map each identity provider group to the Temporal Cloud roles and namespace permissions it needs, and keep the mapping in a table that a reviewer can read. Illustrative example: a payments operations group might receive write access to one production namespace and read-only access to nothing else.

The third task is an audit of who can reach each namespace. Export role assignments on a fixed schedule, compare them with the identity provider groups, and investigate any account that holds access without a matching group. Ask Temporal which audit records and role reports the account provides, how long they are kept and how they can be exported. Assign a named owner and a review cadence. If the tier you select does not include SCIM, this review and the provisioning work become manual, and those ongoing staff hours belong in the cost comparison.

What to monitor, rotate and document after Temporal SSO goes live

Single sign-on and namespace authorization are only as trustworthy as the controls that keep them current. The items below cover the signals you watch, the credentials you rotate, the access you review, the configuration you record, and the emergency path you keep under control.

Authentication and authorization failure monitoring

Track failed sign-ins to the Web UI and rejected API calls denied by the Authorizer, and alert on sudden changes in either. Rejected calls can point to a broken ClaimMapper rule, a changed identity provider claim, or a worker using the wrong credential. Also watch for identity provider availability, because an outage there blocks human access and may push teams toward shared accounts.

Certificate and client secret rotation

Put every mTLS certificate and OIDC client secret on a written rotation schedule with an owner and a tested replacement procedure. Confirm which services hold each credential, including workers and the Web UI, so a rotation does not strand a component. Record expiry dates in your inventory and rehearse one rotation in a non-production cluster before it is due in production.

Namespace role membership reviews

Review who holds each namespace role on a regular cadence, comparing group membership in the identity provider against the claims the ClaimMapper maps to Temporal roles. Remove departed users and service identities that no longer need access. Because the Authorizer decides access from these mappings, a stale group membership grants access until someone removes it.

Authorizer retest after each upgrade

Re-run your authorization test cases after every server upgrade, since Temporal upgrades move one minor version at a time and each step can change behavior. Confirm that each role still gets only the operations it should, and that denied operations are still denied. Treat a failing test as a blocker for the next minor step rather than a cosmetic item.

Configuration record for security settings

Keep a versioned record of the ClaimMapper rules, Authorizer configuration, mTLS settings for internode and frontend traffic, and sign-in settings. Each change should name the reviewer and the reason. Auditors and incident responders will ask what was in force at a given date, and a written record answers that faster than reconstructing it from running servers.

Break-glass access runbook

Document the emergency path for administrative access when the identity provider or the normal role mapping fails. The runbook should define who may invoke it, how the credential is stored and checked out, and how each use is logged and reviewed afterward. Test the procedure on a schedule so the emergency path works when it is needed and does not quietly become a permanent bypass.

Questions buyers ask before hiring help with Temporal SSO

How much effort does Temporal SSO and authorization take?

Effort depends mainly on how many access paths you must secure and how much your identity provider already handles. A single OIDC login for the Web UI with one group-to-role mapping is a small piece of work. Effort rises with the number of namespaces that need separate roles, the claim model in your identity provider, whether workers and command-line clients need their own identities, whether mTLS is in scope, and how many environments must match. A custom ClaimMapper and Authorizer are code you must write, test and maintain. No effort figure applies to every organization, so ask for a written breakdown by component before you compare proposals.

How long does a Temporal SSO project take to deliver?

Duration depends on drivers such as identity provider readiness, decisions about the access model, the number of clusters and environments, and security review and change windows. Delays usually come from waiting on group definitions, app registrations and sign-off on role design, not from the Temporal configuration itself. Ask any provider to list each dependency on your side and who owns it. In a fixed-scope engagement, the timeline is agreed in writing before work starts, and DeployOpen gives a quote only after the scope is written. Ask for the milestones, what each one depends on, and what happens if an approval arrives late.

Can our own team set up Temporal SSO without outside help?

Yes, many teams can, provided they have engineers who already run Temporal and an identity provider administrator who can register OIDC applications. The configuration itself is not the hard part. The harder parts are designing the role model, writing and testing the ClaimMapper and Authorizer, and checking the result against the rest of the platform. The default noopAuthorizer allows every API request until you configure an Authorizer, so the gap is easy to miss if no one owns the design. Consider outside help if nobody has designed authorization before, if a security review needs independent testing, or if the same team must also run the upgrade and worker work.

What does the work need from our identity and security teams?

Identity team: registering the OIDC client, setting redirect URIs, defining the group or claim that carries roles, setting token lifetimes, and naming an owner for group membership.

Security team: approving the role model, which groups get which roles on which namespaces, reviewing mTLS settings for internode and frontend traffic, signing off on the Authorizer logic, and deciding how authorization decisions are logged and retained.

Platform team: confirming that Temporal services run on hosts not reachable from the public internet, with network access limited to trusted internal networks, and scheduling changes to the running cluster.

Write these owners and approvals into the scope before work starts so that no step waits on an unnamed person.

Does Temporal Cloud remove the need for an Authorizer?

Do not assume it does. The Authorizer, ClaimMapper and noopAuthorizer behavior described in the supplied documentation apply to self-hosted Temporal, and Temporal Cloud has its own access model. Confirm with Temporal which access controls Cloud provides for your users, service accounts and namespaces, and how SAML SSO and SCIM map identities to roles. If you run a self-hosted cluster alongside Cloud, you will need a role model for each platform and a way to keep them consistent. Ask for the answer in writing, because it affects whether the custom authorization work in your scope still applies.

What do SAML SSO and SCIM cost in Temporal Cloud?

According to the Temporal pricing page, pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, and the page lists SAML SSO with that tier. SCIM is listed with the Enterprise and Mission Critical support add-ons, which Temporal quotes through its sales team, and Business support starts at 500 US dollars per month with a 2-hour P0 response in business hours. Because prices change, check the current terms on the pricing page and ask Temporal to confirm which tier includes each feature. DeployOpen does not set or estimate these prices.

How is a fixed-scope Temporal SSO engagement agreed?

Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work starts. For this topic, the written scope should name the clusters and environments in play, the identity provider and its configuration, the claim-to-role model, the ClaimMapper and Authorizer deliverables, the test evidence you will receive, and the handover. Changes after signing go through a written change request, which can alter cost and timing. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, and a quote follows from the written scope.

What should we test before turning on Temporal authorization?

Test in a non-production cluster first, with the same identity provider configuration you plan to use in production. Check that an OIDC login to the Web UI succeeds and that the claims map to the expected role in each namespace. Confirm that each role can do what it should and is denied what it should not, including namespace-level actions. Verify that workers and command-line clients still authenticate, because a change that works for people can break service identities. Confirm that calls without credentials are rejected, since the default allows every request. Finally, test token expiry and keep a documented rollback path before you change production.

How DeployOpen works on this

DeployOpen treats Temporal SSO and authorization as a security build inside your own infrastructure, not a login screen added at the end. We scope the identity provider, claim mapping and namespace roles first, then build and test them against your self-hosted Temporal Service or your Temporal Cloud account, and hand over the configuration with documentation your team can run.

How we scope

Written scope lists the identity provider, OIDC settings and Web UI access that will be configured
The scope maps which JWT claims or certificate attributes will drive namespace roles
Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts

How we build

Configure the ClaimMapper and Authorizer so requests are denied by default instead of the noopAuthorizer behavior
Test role outcomes for each namespace with real user, service and worker identities before go-live
Keep Temporal services on hosts not reachable from the public internet, with access limited to trusted networks

How we hand over

Deliver the claim mapping, role matrix and Authorizer configuration as versioned, reviewable artifacts
Document the access tests, expected denials and evidence your auditors or security reviewers will ask for
Walk your platform and security teams through how to add a namespace, a role or a new identity provider client

How we support

Ongoing support and upgrades are available as a retainer, covering identity changes after go-live
Re-test role mappings when Temporal Server versions change, following your own upgrade plan
Confirm with your identity team and Temporal's current documentation which SSO features your plan includes