Can we use our own oAuth while hosting a plumber api on a SAML configured Connect Server?

Posit Professional & Hosted Products Posit Connect
1

We've been experimenting with using the sealr and jose packages in order to deploy our own oAuth authentication for plumber APIs on Connect.

This is working well - essentially all we need to do for a global auth filter is to add a filter like:

#* Check the request is authorised
#* @filter jwt_auth
function(req, res){

  message("PATH_INFO", req$PATH_INFO)
  
  # don't authenticate the docs
  if (
    req$PATH_INFO == "/" ||
    stringr::str_starts(req$PATH_INFO, "/__docs__/") ||
    stringr::str_ends(req$PATH_INFO,  "/openapi.json")) {
    plumber::forward()
    return()
  }

  # get the public key  
  cert <- get_certificate_cached()
  
  # simply call the strategy and forward the request and response
  sealr::authenticate(req = req, res = res, is_authed_fun = sealr::is_authed_jwt,
                      token_location = "header", pubkey = cert)

}

plus we have options to customise the auth at individual endpoint levels too.

This works fine when hosted locally. However, if we deploy it to Connect, then it seems like Connect intercepts and handles the oauth header - even though our Connect is set to SAML authentication, and even when we set the plumber API to "Anyone - no login required"

Is there any way to configure this Plumber API on Connect so that Connect passes through the oauth token headers to the plumber application in this case?

My motivation here is I'd like to use Connect to host our R APIs - we've got a good monitoring and deployment environment for that - but to secure those APIs using the same authentication and authorisation as our other REST APIs (written in C#, JavaScript, Python, ... and deployed across a mixture of server environments).

1 Like
2

I believe I investigated the issue before.
https://docs.posit.co/connect/admin/security/#custom-headers

You would need an admin to configure the server to let you do that, if possible at all.

A user would not be able to achieve it by himself, I think, as the headers would be stripped before hitting your API.

1 Like
3

Thanks - I took a look at those, and I'm not sure they help me. They seem to be a way of adding additional headers during server processing.

What I think I need is a way to disable auth processing for these specific pieces of Plumber Content - for the Authorization Bearer token to be passed through to the R layer instead.

I was hoping "no login required" would give me this - but this intercepts the Authorization and attempts a login with it with our SAML configuration:
image

5

Thanks - that might be a problem if I get past the first step.

Currently the headers are being intercepted and Connect is trying to process the auth token - so this causes Connect to block the request well before the Shiny app gets a chance to do any processing.

6

@slodge
Here is an idea, pass a custom header ("X-AUTHORIZATION") to the API. Connect will forward it. In your filter, set the value of req$HTTP_AUTHORIZATION to the custom header req$HTTP_X_AUTHORIZATION before calling sealr::authenticate?

7

Thanks - that's one of the routes I suggested in my reply on Is it possible to use Plumber API with custom oAuth on Posit Connect · Issue #919 · rstudio/plumber · GitHub

But I think we're actually going to head in the route of deploying these APIs in containers without Connect :+1:

Closing this now. Thanks :+1:

1 Like