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).
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:
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.
@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?
