OpenID Connect Authentication

Workbench

You can configure Posit Workbench to authenticate users via OpenID Connect (OIDC). This enables users to log in with their existing Single Sign-On (SSO) credentials and be automatically authenticated to Workbench whenever they are logged into their OpenID Provider (OP) account.

Prerequisites

To get started with OpenID Connect for Workbench, you need:

  • Information about your OIDC Identity Provider
  • The URL where users access Workbench
  • Local system accounts
Important

OpenID Connect authentication requires that users have a corresponding local system account. There are a few ways to achieve this:

  • Workbench can create these accounts automatically. Refer to Just-in-Time Provisioning.
  • You can use PAM Sessions and sssd to automatically create local system accounts from an LDAP provider.
  • Local system accounts can be created manually. However, we do not recommend this in production deployments.

Supported Features

  • Service Provider (SP)-initiated Single-Sign-On (SSO)
  • Just-in-Time (JIT) Provisioning
  • SCIM User Provisioning

Enabling OpenID Connect

To enable authentication with OpenID you add the auth-openid option to the Workbench configuration file:

/etc/rstudio/rserver.conf
auth-openid=1
Important

Once you enable authentication with OpenID, that becomes the exclusive means of authentication (you can’t concurrently use both PAM and OpenID authentication).

Configuring your OpenID provider

In order to use OpenID with Workbench you need to register your server on your OpenID Provider (OP) first.

Note

Workbench supports the OAuth2 “Authorization Code” flow with OpenID.

OpenID URLs

Workbench expects an OAuth2 callback in order to complete the OpenID authentication. The endpoint responsible for handling this callback from the OP is located at /openid/callback. For example, if your Workbench server is hosted at https://rstudio.example.com/ the callback URL will be https://rstudio.example.com/openid/callback. While registering Workbench on your OpenID Provider, this URL will be requested. Your server URL may also be requested as part of that setup.

Client credentials

As part of the Workbench registration on your OP, a “client ID” and a “client secret” may be presented to you. You need to add a configuration file (/etc/rstudio/openid-client-secret) containing the client-id and client-secret. For example, the configuration file might look like this:

/etc/rstudio/openid-client-secret
client-id=lllllllllllll-xxxxxxxxxxxxxxxxxxxxxx
client-secret=BhCC6rK7Sj2ZtPH0ord7lO1w

The /etc/rstudio/openid-client-secret file should have user read/write file permissions (i.e., 0600) to protect its contents from other users. You can ensure this as follows:

$ sudo chmod 0600 /etc/rstudio/openid-client-secret
Important

The above client-id and client-secret aren’t the actual values you’ll use. Rather, you should substitute the values that you obtained from your OP when registering your site for OAuth 2.0 authentication.

Client secret encryption

An unencrypted value in the client-secret option of the /etc/rstudio/openid-client-secret file must only be used temporarily for testing purposes. A warning will be present in Workbench log output when an unencrypted secret is being used.

We strongly recommend encrypting the client secret using the command rstudio-server encrypt-password. This way, if you have to backup your configuration, save it to a repository or share it with Workbench Support, your OpenID client secret will be protected.

Use the following steps to encrypt the OpenID client secret:

  • Run the command sudo rstudio-server encrypt-password and enter the client secret.
  • Copy the resulting encrypted secret printed in the terminal.
  • Add or replace the client-secret option in the openid-client-secret file using the encrypted secret copied above.
  • Restart Workbench. Confirm it operates normally. You should no longer see a warning about unencrypted secret in Workbench logs.
Note

Alternatively, you can also “pipe” your secret to the rstudio-server encrypt-password command to skip the prompt. Useful when the secret is already stored elsewhere. For example:

cat secretfile | sudo rstudio-server encrypt-password

OpenID issuer and well-known configuration

Workbench also needs to be configured to be able to authenticate the authorization codes returned by the OP. In order to do that, Workbench needs to know the location of the OP with its “issuer” URL. This can be done by adding the option auth-openid-issuer. This must be an HTTPS URL and the location of the /.well-known/openid-configuration metadata discovery. For example, if your OpenID issuer is https://op.example.com/ the discovery endpoint should be https://op.example.com/.well-known/openid-configuration.

/etc/rstudio/rserver.conf
auth-openid-issuer=https://op.example.com

OpenID claims

Important

Your OP must return at least one claim matching the user’s valid Linux account username. See PAM basics for details on username handling.

By default, Workbench looks for a claim called preferred_username (case-sensitive). If you wish to use a different claim, add the option auth-openid-username-claim with the appropriate value.

/etc/rstudio/rserver.conf
auth-openid-username-claim=other

The OP returns OpenID claim data, so configuring custom claims and scopes to suit your use cases must be completed externally to Workbench. Not all OPs provide this functionality.

When Just-in-Time provisioning is enabled, Workbench can also provision users purely on the basis of their OpenID claims. See the OpenID Connect Authentication section of the Just-in-Time provisioning guide for more information.

Note that, because the username claim must match a Linux account username, the username claim is subject to the same restrictions as those applied by the operating system to account usernames. See the CAVEATS section on the useradd man-page for more information about username restrictions. To summarize: portable usernames are limited to 32 characters in length, and must only contain alphanumeric characters, underscores, and dashes. Optionally, they can end with a ‘$’ dollar sign character.

These restrictions my vary depending on the flavor of Linux, but the 32 character limit is common to most. Taking advantage of operating-system-specific naming conventions may reduce the portability of usernames.

Also, be aware that Workbench currently does not support custom post-processing (or mapping) of claims.

SP-initiated SSO

After configuring your OpenID Provider and Workbench, the sign-in process can be initiated from the Workbench login page.

  1. Navigate to the Workbench login page.
  2. Click the Sign in with OpenID button. You will be redirected to your OpenID Provider’s login page.
  3. Enter your credentials and sign in. You will be redirected back to Workbench and automatically logged in.

Advanced options

Depending on your choice for the username claim your OpenID Provider may require the initial request to contain a certain “scope”. Workbench automatically includes the scopes openid, email and profiles as part of the authentication. If you wish to include additional scopes, use the option auth-openid-scopes with a space-separated list of values.

/etc/rstudio/rserver.conf
auth-openid-scopes=scope1 scope2
Important

Quotation marks are not accepted around the scope values.

Proxy considerations

If you are running Workbench behind a proxy, you will need to configure your proxy in a way that Workbench can tell the OP to redirect back to the correct location. There are number of options to choose from as described in Running with a Proxy.

The use of the X-RStudio-Request header in your proxy is recommended and the only method which works behind a path-rewriting proxy. In this case, the proxy must set the X-RStudio-Request header to the exact complete URL as requested by the browser. For example if your proxy was set up to serve Workbench requests at https://testdomain.com/rstudio/ and an incoming request for /home came in, your proxy should set X-RStudio-Request: https://testdomain.com/rstudio/home which would allow Workbench to know about the added path prefix /rstudio.

If your proxy does not add path prefixes, Workbench is also compatible with two options using commonly available HTTP proxy headers:

  • The headers X-Forwarded-Host, X-Forwarded-Proto, and X-Forwarded-Port.
  • Or the header Forwarded with host, and proto values.

When using path-rewriting proxies, it’s also recommended to use either the header X-RStudio-Root-Path or the option www-root-path to indicate the path defined for Workbench by the proxy. For example, if your URL to Workbench is www.example.com/rstudio your proxy should send the header X-RStudio-Root-Path: /rstudio or you should use:

/etc/rstudio/rserver.conf
www-root-path=/rstudio

If none of the headers above are set by the proxy, Workbench will attempt to redirect back to the address present in the Host header and it will determine the protocol (http or https) based on its current configuration.

If you are running behind a proxy but cannot set headers for whatever reason, and www-root-path is not the right choice, you can use the auth-openid-base-uri option in the Workbench configuration file to accomplish the same purpose:

/etc/rstudio/rserver.conf
auth-openid-base-uri=http://testdomain.com/rstudio/

Outgoing proxies

Some OpenID authentication features require Workbench to call an external service over HTTP or HTTPS, such as retrieving the provider’s OpenID configuration from a known endpoint. If your environment requires an HTTP or HTTPS proxy for outbound requests, the appropriate proxy environment variables must be set for Workbench’s server process so that it uses the proxy when making the request. See the Outgoing Proxies section for more information on configuring these variables.

Troubleshooting

Additional information about the OpenID flow and the received claims may be written to the logs. Be sure to configure rserver logs to output debug level messages in /etc/rstudio/logging.conf to see these entries.

Back to top