Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
53 changes: 53 additions & 0 deletions docs/best-practices/security-controls.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,59 @@ When applicable, use [SCIM](/cloud/manage-access/scim) or the Temporal Cloud use

For non-human access (CI/CD pipelines, backend services), use [Temporal Cloud Service Accounts](/cloud/manage-access/service-accounts) instead of shared user logins. Service Accounts are machine identities that can be granted specific permissions without ties to an individual. Create separate Service Accounts with unique API keys for different applications or microservices, and apply least privilege to each (for example, a service account that only has access to one Namespace).

### Restrict Cloud UI session lifetimes

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Move session-mode operations into the Cloud access docs

Keep a brief best-practice recommendation here, but move the prerequisites, support-ticket procedure, scope, and timer behavior to a page under docs/cloud/manage-access/. The architecture guide assigns SAML and Cloud-specific operations to the Temporal Cloud section, while this 55-line addition adds four headings and takes the security-controls page from 16 to 20 headings, beyond the repository's target of fewer than 15 total.

AGENTS.md reference: AGENTS.md:L247-L253

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note the key reason for having this feature here is because the feature itself is for security control use cases and best practices rather than access management.
The target persona or market sector is governance sector, financial services that have stricter compliance and security policies and requirements to fulfill.


Strict UI Session Mode is an optional account-level setting for organizations that require shorter sessions for users
authenticated through [SAML single sign-on (SSO)](/cloud/manage-access/saml).

When enabled, Strict UI Session Mode:

- Signs users out after 15 minutes of inactivity, instead of 12 hours.
- Limits the maximum session duration to 12 hours, instead of 7 days, even if the user remains active.

When either limit is reached, the user must start a new Cloud UI session through the account's SAML identity provider.
Whether the identity provider prompts the user to enter credentials or complete MFA depends on the identity provider's
own session policy.

These predictable session limits can help organizations enforce internal security policies and complete security and
compliance reviews. Enabling Strict UI Session Mode does not by itself guarantee compliance with a particular standard
or regulation.

#### Prerequisites

Before enabling Strict UI Session Mode, [SAML SSO](/cloud/manage-access/saml) must be configured and active for the
account.

Strict UI Session Mode applies only to Cloud UI sessions authenticated through SAML. It does not affect other
authenticated interactions with Temporal, including:

- Users who sign in through Google, Microsoft, or email and password
- Workers or SDK clients
- API Keys or Service Accounts
- Temporal CLI sessions
- mTLS connections

#### Enable strict UI session mode

[Create a support ticket](/cloud/support#support-ticket) and provide your
[Temporal Cloud Account Id](/cloud/namespaces#temporal-cloud-account-id). Ask Dev Success to enable Strict UI Session
Mode for the account.

Strict UI Session Mode applies to the entire account. It cannot be configured for individual users, groups, or roles.
The 15-minute inactivity limit and 12-hour maximum session duration are fixed.

The setting applies when a user starts a new session. Users with an active session must sign out and start a new session
before the shorter limits take effect.

#### Understand how inactivity is measured

Only Cloud UI activity that sends a request to Temporal Cloud resets the inactivity timer (e.g. create a Namespace). Mouse movement, scrolling, or reading information that has already loaded does not reset the timer.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📝 [vale] <Std.Abbreviations.Latin> reported by reviewdog 🐶
Use 'for example' instead of 'e.g.'.

Suggested change
Only Cloud UI activity that sends a request to Temporal Cloud resets the inactivity timer (e.g. create a Namespace). Mouse movement, scrolling, or reading information that has already loaded does not reset the timer.
Only Cloud UI activity that sends a request to Temporal Cloud resets the inactivity timer (for example create a Namespace). Mouse movement, scrolling, or reading information that has already loaded does not reset the timer.


The Cloud UI does not display a warning or countdown before the session expires. The 12-hour maximum applies regardless of activity.

To disable Strict UI Session Mode, [create a support ticket](/cloud/support#support-ticket). Active sessions retain the
shorter limits until users sign out and start new sessions.

## Secure application authentication and API access

Clients interact with the Temporal Service to initiate and manage Workflows, while Workers execute the business logic defined in Workflows and Activities in your own environment.
Expand Down
12 changes: 8 additions & 4 deletions docs/cloud/manage-access/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,10 +17,14 @@ Access to Temporal Cloud is governed by role-based access control (RBAC). Within
as user, user group or service account, has one account-level role and optionally, one or more Namespace-level
permissions. Each principal can only perform actions that are allowed by their assigned roles and permissions.

Temporal Cloud supports Security Assertion Markup Language (SAML) and System for Cross-domain Identity Management (SCIM)
for integration with your organization's identity provider (IdP). SAML enables single sign-on (SSO) by allowing your
identity provider to authenticate users into Temporal Cloud. SCIM automatically creates, updates, and removes users and
groups in Temporal Cloud based on changes in your identity provider.
Temporal Cloud supports [Security Assertion Markup Language (SAML)](/cloud/manage-access/saml) and
[System for Cross-domain Identity Management (SCIM)](/cloud/manage-access/scim) for integration with your organization's
identity provider (IdP). SAML enables single sign-on (SSO) by allowing your identity provider to authenticate users into
Temporal Cloud. SCIM automatically creates, updates, and removes users and groups in Temporal Cloud based on changes in
your identity provider.

To enforce shorter sessions for SAML-authenticated Cloud UI users, see
[Restrict Cloud UI session lifetimes](/best-practices/security-controls#restrict-cloud-ui-session-lifetimes).

## Temporal Cloud accounts

Expand Down