Rstudio Workbench OpenID Authentication

R Admins
,
#1

I'm trying to configure authentication of my Rstudio Workbench instance with auth0 / OpenID.

What confuses me is that I'm getting the below error in the rserver.log.

Configured username claim is not present in the OpenID response

I have deployed the below action in Auth0 dashboard and I confirm that it is being triggerd once a user logs in.

exports.onExecutePostLogin = async (event, api) => {
  
  if (event.authorization) {
    api.idToken.setCustomClaim("preferred_username", "username")
  }

};

What needs to be configured in order for the OpenID response to return the claim with the username?

1 Like
#2

Welcome to RStudio community @agelosnm! This is a fantastic question!

If you set the following logging.conf, then you should see what claims RStudio is picking up, which can help with the debugging process:

[*]
log-level=info
[rserver-openid]
log-level=debug

The default username claim that Workbench uses is preferred_username. But you can change that to be whatever you want!

https://docs.rstudio.com/ide/server-pro/authenticating_users/openid_connect_authentication.html#openid-claims

#3

Hello!

Thanks for your below!

I've tried it and I can see the below useful info the log:

scopes_supported:["openid","profile","offline_access","name","given_name","family_name","nickname","email","email_verified","picture","created_at","identities","phone","address"]

I suppose that the needed value is the "name" one although I've tried the "nickname" and the "given_name" ones but nothing changed.

For example,

exports.onExecutePostLogin = async (event, api) => {
  
  if (event.authorization) {
    api.idToken.setCustomClaim("name", "user")
  }

};

Note: I have not set up anything at PAM level in case this is related. I expect to overcome this kind of issues in order to have it invovled too.

#4

any comments about the above?

#5

Oops! Apologies for missing this! :sweat_smile:

Are you checking the logs on the Auth0 side? You should not need to do anything with PAM on the RStudio Connect side.

I would have expected a log message more like this from RStudio Connect:

time="2022-07-16T09:08:38.365Z" level=debug msg="UserInfo claims: map[email:xxx@rstudio.com email_verified:true family_name:Arendt given_name:Cole groups:[...] locale:US middle_name:Eugene name:Cole Arendt nickname:Cole preferred_username:cole sub:xxxx updated_at:1.642526199e+09 zoneinfo:America/Los_Angeles]" region=oauth2

And then rather than modify on the Auth0 side, I would confirm that the claims on the Connect side are configured to use the claims that are coming through. Does that help? It can be tricky to get these services talking to each other!

#6

Oh also - I never said this but feel free to reach out to our support team at support@rstudio.com here, too!! That may be a more direct path to resolution with faster response times :smile:

#7

@cole Thank you for your comments! We did manage to overcome issues with OpenID and now can authenticate with the system. I'm now trying to configure PAM as when a user tries to log in and there is no local account matching his email an "Unauthorized" status return.

When I manually create one using useradd, the user can log in but the goal is to manage to automate this.

Thus, my question is how is that possible using PAM? Documentation mentions that sssd must be configured but this requires a directory server (LDAP, AD, etc) which does not apply in our case.

We just want users being able to log in using Auth0 and the local system accounts to be configured inside Rstudio server without any additional resource. Is that possible?

#8

So unfortunately this is not possible out of the box today :frowning_face:

This is something we are definitely working towards though! Our current plan is to move towards SCIM, which unfortunately does not look to have a great answer on Auth0. There may be some other options for "Just-in-Time" provisioning that we could do too, though!

The current workarounds that I would say are most common:

  • stand up a little openLDAP server that can synchronize its users from the real identity source (i.e. Auth0). I'm not familiar with whether Auth0 has any help for this type of architecture or not
  • a little service that runs on a cron, etc. and fetches data from Auth0 and provisions users via useradd. Just be sure if you are in a HA environment (or an environment that disappears on occasion like ephemeral machine images, containers, etc.) that userIDs are persistent / consistent. Ideally maintained in the source of identity (Auth0).
  • an authoritative text file of usernames / uids that can be manually or pseudo-manually updated, and a service / script / etc. that creates users from that text file in an idempotent fashion.
  • manually creating users :grimacing: (most often used for environments that do not change often)

The closest we currently have to an example (a bit hacky, not completely idempotent, and just a "one shot" runs once then sleep forever):

All gross workarounds, and it pains me to write them. We have a good bit of work to do, but we would love to have a better story by the end of the year or early next year :see_no_evil:

Do you have any ideas which approach seems most feasible to you in the short term?