Authentication in Posit Professional Products
Configuring authentication is an important part of configuring your Posit professional products. This page is designed to help you choose which authentication option is the right choice for your situation.
For details on how to configure a particular setup, please see the Administration Guides for Workbench and Connect.
Workbench
Workbench requires that users and groups exist on the Linux server where the product is running.
Configuring authentication in Workbench has 2 steps:
- Creating local user accounts and home directories manually or via SSSD.
- Configuring authentication via PAM or directly with the authentication provider for SSO.
User provisioning
Regardless of the authentication method chosen, local users with home directories are required for Workbench. Most administrators use SSSD with Active Directory or LDAP to create these Linux users.
It is also possible to manually create users on the Linux server.
Note: If multiple Workbench nodes are in a load-balanced configuration, users must exist on all servers with matching UIDs.
Authentication
Here are the options to authenticate in Workbench.
| Method | Details | Product Configuration |
|---|---|---|
| Linux Accounts (default) | PAM authenticates with local accounts. | PAM |
| Kerberos (not SSO) | PAM authenticates with Kerberos. | PAM + Kerberos |
| LDAP/AD | PAM authenticates with LDAP/AD. | PAM + LDAP |
| SAML 1 | Authenticate with SAML IdP. Separate local account provisioning required. | SAML |
| OAuth2/OIDC 2 | Authenticate with OAuth2/OIDC IdP. Separate local account provisioning required. | OAuth2/OIDC |
| A different system | Proxy server authenticates and passes to Workbench. Recommended only for advanced use cases. | Proxied Auth |
For most Workbench installations, authenticating against LDAP/AD is the simplest configuration, since it is “free” if LDAP/AD are being used to provision users. If a seamless SSO experience is desired, SAML or OIDC are common choices, but users still must be provisioned.
Please see this page if you wish to use Kerberos tickets as part of your authentication scheme.
Connect
Connect users and groups exist in the product and usually are not required on the underlying server.
Authentication Options
Here are the authentication options in Connect:
| Method | Details | Product Configuration |
|---|---|---|
| Built-in (default) | In-product authentication. | Password |
| Local accounts | PAM authenticates with local accounts. | PAM |
| Kerberos (not SSO) | PAM authenticates with Kerberos. | PAM + Kerberos |
| LDAP | Authenticate directly with LDAP/AD. | LDAP |
| SAML | With SAML IdP. | SAML |
| OIDC/OAuth2 | With OIDC IdP. | OIDC/OAuth2 |
| A different system | Proxy server authenticates and passes to Connect. Recommended only for advanced use cases. | Proxied |
Note: The Applications.RunAsCurrentUser setting, often desirable to use Kerberos to access a data source, requires the use of PAM authentication.
Package Manager
Package Manager does not have in-product authentication for end-users. Anyone who has network access to your Package Manager instance will be able to install packages using the install.packages command from R.
Administrators require command-line access to the Linux server where Package Manager is installed as well as membership in the rstudio-pm group to be able to use the command-line Interface to administer the package repositories.
Please see the relevant section of the Package Manager Admin Guide for more details.