Connecting Workbench to Your Identity Provider

By the end of this lesson, you will be able to:

  • Explain the benefits of centralizing authentication with an identity provider
  • Distinguish authentication from authorization in the context of Workbench
  • Explain why Workbench requires a Linux account for each user
  • Distinguish just-in-time provisioning from SCIM provisioning

1 Introduction

Up until now, Workbench has relied on Linux account credentials for authentication, using a local test user and PAM. In a production deployment, you will want to integrate Workbench with the authentication system your organization already uses. Users then authenticate with their existing credentials, and security policies such as multi-factor authentication apply everywhere, not just in Workbench.

Workbench can integrate with many enterprise authentication systems. In this training we use OpenID Connect (OIDC), a single sign-on protocol that centralizes user authentication across your organization’s applications. While OIDC extends the OAuth 2.0 protocol with identity information, in practice the terms OAuth and OIDC are often used interchangeably. If your infrastructure uses a different authentication system, refer to the Admin Guide for the exact steps you will need to take.

To integrate an identity provider (IdP) with Workbench, there are two things you need to configure, the authentication settings (they verify the identity of the user during the login flow) and the authorization settings (they determine the role and permission level the user has in Workbench).

NoteTimings for this chapter
  • Reading time: 15 minutes
  • Documentation reading time: 25-45 minutes
  • Hands-on exercise time: 15-30 minutes
TipRequired Reading

2 Why Workbench Requires System Accounts

Workbench is designed to provide an individualized computing environment to each user. Users own the processes they initiate and run from Workbench, which requires local or networked system accounts.

This is a real architectural difference from Posit Connect, which relies on a single service account to run most content and stores users in an internal database. Workbench instead relies heavily on the Linux Pluggable Authentication Module (PAM) to manage authentication. PAM can be used by itself for authentication, for example with local accounts, LDAP, or Kerberos, or to automatically provision local system accounts when using single sign-on or proxied authentication.

3 Configuring OIDC

To use the OIDC protocol, you need three values from your identity provider: the OpenID URL (the issuer), the client ID, and the client secret.

The client secret is sensitive, so it belongs in its own file, /etc/rstudio/openid-client-secret, owned by rstudio-server:rstudio-server with mode 600. The authentication itself is enabled in rserver.conf with auth-openid=1 and auth-openid-issuer pointing at your IdP. After a restart in the correct order, the Workbench login page redirects users to your identity provider.

Some values in your Workbench configuration files are sensitive. In production, encrypt the client secret with the encrypt-password utility that ships with Workbench, and use the encrypted value in your configuration file.

4 Creating User Accounts: JIT vs SCIM

Once authentication is external, Workbench still needs a local Linux account for each user, and there are two approaches to creating them:

  • Just-in-Time (JIT) provisioning: local Linux accounts are created when a user logs in for the first time. This requires enabling user provisioning in rserver.conf and configuring the pam_mkhomedir PAM module so home directories are created automatically.
  • SCIM (System for Cross-domain Identity Management): the IdP continuously synchronizes user and group information to the Workbench server.

Both approaches count users toward the license limit only at first login. Note that JIT provisioning does not create Linux groups. Groups your configuration depends on must already exist on the system. The lab exercises JIT provisioning, and the Admin Guide documents SCIM if it suits your environment better.

TipWhy is it relevant to me?

Centralizing authentication pays off well beyond the login page:

  • Security: policies such as multi-factor authentication and password rotation are enforced in one place.
  • User management: adding and removing users happens in your IdP, not separately in each application.
  • Compliance: many organizations require centralized authentication for audit trails and access control.

As you plan your own installation, identify where you will get the values needed to integrate your authentication system, decide between JIT and SCIM provisioning, and plan what happens if your IdP becomes unavailable.

In the accompanying lab, you will configure Workbench for OIDC authentication, enable just-in-time provisioning, and verify that users can log in with their identity provider credentials.