With the new OIDC functionality released this week, we're interested in exploring a few more "pass through authentication" ideas.
In particular one problem scenario we're looking at is::
• We provide in in-house package which provides functions to call a web service. That service needs to know the end user, in order to carry out some sensitive operation or return sensitive data.
• Various data scientists write "apps" using this package - basically these shiny apps (and some markdown documents) can be written and published by anyone.
• We're trying to find a way to prevent the app/markdown author injecting usernames into the app code, and fooling the service into carrying out the sensitive operations. This isn't a high risk - but it's something we need to say we've covered.
Some solutions/ideas we're toying with:
• (If we could pass a claim from the oidc token to the app, then we can also prevent tampering with the username. But I think the requests could still be replayed trivially, so I don’t think that will work)
• If the session object had a specific method to sign the username then we could distribute certificates and have a chain of trust. The signature would also need to include when it was generated, and some sort of nonce to prevent replays.
• If we could configure rsconnect to add a function (say from an R package provided by the administrator, or even just a wrapper around a shell script on the filesystem) to the session object whenever an app is started up, then we could make some signing plumbing ourselves using that generic hook. Looking in the shiny code we couldn't see any way to do this.
We're 100% fine to trust rsconnect itself (just not our published apps) - so if there is another method we can use to verify that the user identity arriving at the service hasn’t been tampered with as it passed through the app code, then that would also work. We know there are some rstudio pages about using Kubernetes for some pass through scenarios - but we've not had good experiences with getting Kubernetes to work within other systems/products in the past so we're not keen on that direction.
Sorry if this is a little more involved that typical community posts... but if anyone has any ideas in this area we'd be interested to hear them,
Aside: With these ideas, we are initially thinking mainly about Shiny apps... we'd also obviously need to find solutions for markdown docs and plumber apis - but we don't have many plumber apis yet, and we recognise that there are other issues with markdown (e.g. when it's already rendered)
