Access control overview

Posit Connect has three layers of access control. Each layer answers a different question, and the answer at one layer shapes what is possible at the next.

Layer	Question	Configured by
User authentication	Can this person access Connect?	Server administrator
Content access	What content can they see?	Content owner or collaborator
Resource access	What external systems can the content reach?	Server administrator and content owner

Understanding how these layers interact helps administrators plan a secure deployment and helps publishers choose the right sharing and integration settings for their content.

User authentication

Before anyone can use Connect, Connect must know who they are. It authenticates users through a single identity provider (IdP), or its built-in password system, and maintains an internal user record for each authenticated user.

Connect supports a single authentication provider at a time, chosen from options that include SAML, OpenID Connect, LDAP, PAM, proxied authentication, and a built-in password system. See Authentication for the full list of providers and provider-specific configuration guides.

The authentication method determines how users prove their identity, and it controls which user attributes (username, email, group memberships) are available downstream. For example, group memberships synced from an LDAP provider or SAML assertion can later be used by content owners to quickly give whole teams or departments access to their content.

The diagrams below show how this identity flow works in general and an example of sharing content with a group from your IdP.

---
title: "Example 1 — Identity flow from your IdP into Connect"
---
flowchart LR
    A[User] -->|signs in| B[Identity provider<br/>SAML, OIDC, …]
    B -->|user attributes| C[Connect user record<br/>username, role, groups]
    C --> D[Admin, Publisher, or Viewer]
    C --> E[Groups available<br/>for content sharing]

---
title: "Example 2 — A group from your IdP becomes a group in Connect for sharing content"
---
flowchart LR
    A["'Analytics' group<br/>in identity provider"] -->|user signs in| B[Connect syncs<br/>group membership]
    B --> C["Content access:<br/>shared with 'Analytics' group"]
    C --> D["'Analytics' members<br/>get access"]

User roles

Each user has a role that determines their baseline capabilities on the server. Roles are assigned by an administrator and can be changed later. See User management for how roles are assigned and configured.

The available roles are:

• Administrator: Full server management. Administrators can see all content on the server and manage settings, but they do not have access to view the content itself. To view content they have not been added to, administrators must explicitly grant themselves access. This action is recorded in the audit trail.
• Publisher: Can deploy and manage their own content. Can be added as a collaborator to deploy and manage content owned by others.
• Viewer: Can view content shared with them. Cannot deploy or manage content.
• Anonymous: Unauthenticated visitors who can only view content marked as public.

Content access

Content owners decide who can see each item they deploy.

Every content item has a sharing setting that controls its visibility. These settings are arranged from most open to most restrictive:

Anyone - no login required. The content is accessible to anonymous visitors; no identity is needed. For interactive content (Shiny applications, FastAPI APIs, and similar), this option requires an Enhanced or Advancedlicense with the Public Access or Unrestricted entitlement. SeeEntitlements for details.

All users - login required. Any user who can sign in to Connect can view the content.

Specific users or groups. Only explicitly named users or members of specific groups can view the content. This is the default for newly published content. Only the publisher can see it until they share it.

Within each content item, owners can also grant collaborator access, which allows a user to deploy new versions, change settings, and manage who else can see the content. Collaborators must have publisher or administrator accounts.

Server administrators can restrict which sharing options publishers are allowed to use. See Limiting allowed viewership for the relevant configuration settings.

See User management and Group management for more on roles and groups.

Resource access

The first two layers control who can reach your content. The resource access layer controls what happens once the content is running, specifically how it authenticates to the external systems it depends on. Some examples are:

• Data platforms, such as Databricks or Snowflake
• Cloud platforms, such as AWS, Microsoft Azure, or Google Cloud
• Secrets and APIs, such as HashiCorp Vault, Salesforce, GitHub, an internal REST API behind OAuth, or the Connect Server API

Connect provides integrations that let published content obtain credentials at runtime instead of embedding long-lived secrets in code or environment files. There are several authentication types, each suited to different scenarios:

Viewer authentication. The content accesses the external system as the person viewing it. This is only available with interactive content since it requires knowing which viewer is interacting with the content. The content receives a token scoped to that viewer’s identity, so each viewer reaches only what they are authorized to in the external system. See Viewer consent below for more details.

Service account authentication. The content accesses the external system using a shared service account identity managed by Connect. Every viewer gets the same data. This is useful for dashboards backed by a curated dataset or when the external system does not support per-user access.

Workload identity authentication. Similar to service account, but avoids storing long-lived secrets in Connect. The details vary by vendor.

Environment variables. Not an integration, but an alternative to integrations. A publisher sets a static secret (such as an API key) directly on their content, and Connect injects it into the content’s environment at runtime.

The diagram below walks through how to pick among the different integration types, or fall back to environment variables.

---
title: "Choosing an integration type"
---
flowchart TD
    A{Per-viewer access<br/>needed?} -->|Yes| B[Viewer authentication]
    A -->|No| C{OAuth integration<br/>available?}
    C -->|No| D[Environment variable]
    C -->|Yes| E{Vendor supports<br/>workload identity?}
    E -->|Yes| F[Workload identity]
    E -->|No| G[Service account]

Integration access control lists

By default, all publishers can attach any configured integration to their content. Administrators can restrict this by configuring an access control list (ACL) on an integration. When an ACL is set, only publishers explicitly granted access can associate that integration with their content.

---
title: "Integration ACLs in action"
---
flowchart TD
    A[Publisher tries to attach<br/>integration to content] --> B{ACL configured<br/>on integration?}
    B -->|No, default| C[Attach allowed]
    B -->|Yes| D{Publisher granted<br/>access in ACL?}
    D -->|Yes| C
    D -->|No| E[Attach blocked]

Viewer consent

When content uses a viewer authentication integration, Connect redirects each viewer to a consent screen on their first visit. The viewer must explicitly authorize Connect to access the external system on their behalf. After consenting, subsequent visits reuse the established credentials without prompting again until the token expires. Connect uses a refresh token from the external system to renew access silently. When the token expires is governed by the external system’s policy.

---
title: "Viewer consent lifecycle"
---
flowchart TD
    A[Viewer visits content] --> B{Refresh token<br/>stored for this viewer?}
    B -- No, first visit --> C[Consent screen]
    B -- Yes --> D{Refresh token<br/>still valid?}
    D -- Yes --> E[Silent refresh]
    D -- No, revoked or expired --> C
    C --> F[Tokens stored]
    F --> G[Content runs<br/>with viewer's token]
    E --> G

See OAuth integrations for vendor-specific setup guides and the full security model.

How the layers interact

The three layers are not independent. Choices at one layer constrain what is possible at the next.

Example: a publisher shares a link

Imagine a publisher shares a link to a Shiny application with a colleague. The application queries Databricks using a viewer OAuth integration. When the colleague clicks the link, Connect evaluates each layer in turn:

1. User authentication (Layer 1). If the colleague is not already signed in, Connect redirects them to the sign-in page for the configured provider (for example, Okta). After they authenticate, Connect returns them to the original link. If the colleague does not have a Connect account at all, they cannot proceed past this step.
2. Content access (Layer 2). Connect checks whether the colleague has viewer access to this application. If the content is set to “Specific users or groups” and the colleague was not granted access, they see a Request access page where they can ask the content owner to share it. If the content is set to “All users - login required,” the check passes automatically once the colleague is signed in.
3. Resource access (Layer 3). The application starts. Because it uses a viewer integration, Connect redirects the colleague to a Databricks consent screen on their first visit. After they grant consent, the application queries Databricks as the colleague, and Databricks enforces its own row-level and table-level permissions on what comes back.

A failure at any layer stops the request. A change at one layer can also open or close possibilities at the next. For example, removing the colleague from the Connect group that grants them viewer access will block them at Layer 2, regardless of any consent they previously granted at Layer 3.

Request flow

The following diagram generalizes the same flow for any request:

flowchart TD
    A[User opens content] --> B{Requires login?}
    B -- No --> F{Integration attached?}
    B -- Yes --> C{Authenticated?}
    C -- No --> D[Sign in to Connect]
    D --> E{Has content access?}
    C -- Yes --> E
    E -- No --> G[Request access page]
    E -- Yes --> F
    F -- No --> H[Content runs]
    F -- Service account or workload identity --> H
    F -- Viewer authentication --> I{Has user consented?}
    I -- No --> J[Consent screen]
    J --> H
    I -- Yes --> H

Things to watch for

These are some common interactions between layers to keep in mind:

Viewer OAuth integrations require an authenticated user and interactive content. Viewer authentication passes the viewer’s identity to the external system, so it only works when Connect knows who the viewer is and a live viewer session is present to drive the consent flow. Content that uses a viewer integration cannot be set to “Anyone - no login required”. Viewer integrations also do not work with rendered or scheduled content (such as a scheduled Quarto report), because no viewer is present when the content executes. If you need anonymous access or scheduled rendering for content that queries an external system, use a service account, workload identity, or environment variable integration instead.

Content sharing settings do not control what the content can reach. Setting a content item to “Specific users or groups” controls who can open the content in Connect. It does not limit what those users can do once the content is running. If the content uses a service account or workload identity integration, every authorized visitor reaches the external system with the same identity. If the content uses a viewer integration, each visitor’s access to the external system is governed by that system’s own permissions, not by Connect’s sharing settings.

Group memberships flow from authentication. Groups synced from your identity provider at authentication time (Layer 1) can be used in content sharing settings (Layer 2). This means changes to group membership in your IdP automatically update who can see content in Connect, without the content owner needing to make manual changes.

Common scenarios

Per-user data access with Snowflake or Databricks

An analyst publishes a Shiny application that queries Snowflake. They want each viewer to see only the data they are authorized for in Snowflake.

• Layer 1: Users authenticate to Connect via Okta (OIDC).
• Layer 2: The content (Shiny application) is shared with a specific group, the analytics team, managed from Okta.
• Layer 3: A viewer OAuth integration for Snowflake passes each visitor’s identity to Snowflake, where row-level security policies control what they see.

Internal dashboard with a shared data source

A team publishes a dashboard showing company-wide metrics. Any employee should be able to view it, and the underlying data comes from Databricks.

• Layer 1: Users authenticate to Connect via the organization’s IdP.
• Layer 2: The content (internal dashboard) is set to “All users - login required,” so any authenticated employee can open it.
• Layer 3: A service account integration for Databricks provides a single identity with read-only access to the metrics dataset. All visitors to the dashoard see the same data.

API that writes to cloud storage

A developer publishes a Python API that uploads processed files to an AWS S3 bucket. The organization does not want long-lived AWS keys stored in Connect.

• Layer 1: Users authenticate via SAML.
• Layer 2: The API is shared with the “Data engineering” group managed from the SAML provider.
• Layer 3: A workload identity integration for AWS exchanges Connect’s identity for short-lived credentials at request time. The S3 bucket policy on AWS determines which prefixes the API can read or write.

Internal report with no external systems

A data scientist publishes a rendered Quarto report that uses a bundled dataset. Only leadership should see it.

• Layer 1: Users authenticate via SAML.
• Layer 2: The report is shared with the “Leadership” group managed from SAML.
• Layer 3: No integration needed. The data is embedded in the report.

Related documentation

Topic	Link
Configuring an authentication provider	Authentication
User roles and account management	User management
Group-based access	Group management
Content sharing settings	Content management
OAuth integrations for external services	OAuth integrations
Public access for anonymous viewers	Public access
Auditing administrative actions	Auditing