Access Configuration and Policies

Use this section to configure the SRA authorization model, who can use Secure Remote Access (SRA) and from which Gateway or, for web application access, which Zero Trust Web Access (ZTWA) deployment, how usernames are resolved for target sessions, which redirect endpoints are trusted, and which session security controls are enforced.

These settings combine RBAC (SRA-specific permissions, separate from Secrets Management RBAC), Gateway runtime configuration, ZTWA deployment configuration, and authentication method restrictions.

Start Here by Objective

1. Understand the SRA RBAC model first: how SRA permissions are evaluated independently of Secrets Management RBAC, and how Approval Authority combines with Request Access: SRA RBAC Model
2. Map identity claims to runtime target usernames: Username Sub-Claim Mapping
3. Restrict redirect and callback endpoints to approved destinations: Redirect and SSH URL Hardening
4. Configure session lifetime and SSH/web security controls: Session TTL and Security Controls
5. Configure centralized desktop app defaults for cert issuer and web URLs: Desktop App Default Connection Settings

A Note on Terminology Across Components

SRA covers more than one deployment type - the Gateway (Unified SRA) and Zero Trust Web Access (ZTWA) and the field/variable that restricts which requester identities may use a given deployment is named differently between them. See Allowed Access IDs and SRA Entitlements for the authoritative name-per-deployment-type table (Gateway vs. ZTWA, Helm vs. Docker Compose).

This is also the mechanism behind the advanced setting some teams look for as "restrict who can get service from a specific Gateway" or "create an allow list for this deployment" - it is the same Allowed/Authorized Access ID configuration.

Related Pages

• SRA RBAC Model
• RBAC
• SSH Certificates
• SRA Requirements
• Kubernetes Advanced Configuration
• Docker Compose Advanced Configuration
• Zero Trust Web Access on K8s Advanced Configuration