Authentication
Posit Connect authenticates users through a single external provider, or its own built-in password system. When a user signs in for the first time, Connect automatically creates an internal user record. You do not need to create system accounts or provision users in advance.
Posit Connect supports only one authentication provider at a time. Changing providers requires migrating users and content. It is sometimes easier to create a new installation than to migrate an existing one. See Changing authentication provider before you begin.
How authentication works in Connect
Connect delegates sign-in to an external identity provider (IdP) and maintains its own database of user records and group memberships:
- User signs in: Connect redirects to your IdP, or checks credentials locally for PAM, LDAP, or password authentication.
- Connect creates or matches a user record: on first sign-in, Connect provisions an internal account using attributes from the IdP (username, email, name). On subsequent sign-ins, it matches the returning user.
- Groups are synced or managed locally: depending on your provider, group memberships can be pulled automatically from the IdP or managed within Connect’s dashboard.
Unlike Posit Workbench, Connect does not require Linux system accounts for each user. By default, Connect runs all content under a single service account. See Current user execution for configurations that run content as the logged-in user.
Choosing an authentication method
| Your situation | Recommended method |
|---|---|
| Organization uses Microsoft Entra ID, Okta, Google, or another SSO provider | SAML or OpenID Connect |
| Organization uses Active Directory or LDAP on-premises | LDAP / Active Directory |
| Linux server already authenticates users via PAM (e.g., SSSD) | PAM |
| On-premises environment with Kerberos | Kerberos |
| Authentication handled by a reverse proxy (e.g., Shibboleth, custom SSO) | Proxied authentication |
| Small team, evaluation, or proof of concept | Built-in password |
If your IdP supports both SAML and OpenID Connect (OIDC), use OIDC. OIDC is generally simpler to configure, while SAML offers broader group-mapping options.
Single sign-on (SSO)
SAML
OpenID Connect
LDAP and Active Directory
- Active Directory:
- Recommended: With service credentials
- Without service credentials
- Other LDAP:
- Recommended: With service credentials
- Without service credentials
PAM and Kerberos
Other options
- Built-in password authentication: Connect manages its own credentials. Suitable for evaluation and small teams; not recommended for production.
- Proxied authentication: Delegates authentication to a reverse proxy. Use when your SSO system is not directly supported.
- Identity federation: Maps external OIDC tokens to existing Connect users (e.g., publishing from Workbench without separate credentials).