This message was deleted.

Dear @Daniel - thank you very much for your interesting talk on context-aware-proxies. I think the concept of these proxies for web-based applications that are access via a full-blown browser is quite straight forward. I tried to wrap my head around the idea of using them in order to access e.g. API-only services. I think a good example for this would be the access to a protect git repository server that should be protected behind a context-aware-proxy. In the case of git we would use in my example HTTPS as the transport protocol. And typically authenticated git repo servers expect users to provide HTTP-Basic Authentication credentials. I think this scenario however can be transferred to many API-only service where the API expects some "low level" authentication mechanism (like Basic-Auth or a Token) in order to security the access. To carry on with my example from above I don't see an easy way to "teach" my git CLI client to perform a modern authentication mechanism like OAuth + Webauthn in order to pass through a context-aware-proxy that might be in front of my target system. Do you have any experience with protecting systems as described above as "API-only" using e.g. a context-aware-proxy?

Hi @Daniel H. I’m super glad you enjoyed the talk 🙂 It was my first time presenting in a conference. I understand the issue. Using the native git client maybe tricky, as it doesn’t support this. It happens something similar when you try to implement the same with

ssh

to connect to a host (it is not a limitation to http protocol). From what I see from vendors (like Pomerium or Teleport and others), they just work around it, they use their own clients which does that part of authentification before hand and then send to the native client something that they understand. Didn’t really test too much but maybe something but the concept is something like this: I can think for example for your case: you can wrap in a shell script this: https://github.com/cloudentity/oauth2c So with oauth2c you use Oauth2 to authentificate and get a token from your Git Server (you will need to have something at the server listening for those Oauth2 requests and be able to communicate with Git Server to issue a token) and the output token obtained from

oauth2c

passed to the native

git

. pseudo-code script:

#/bin/sh

$GIT_ACTION="$1"

$GIT_ACCESS_TOKEN = $(oauth2c <https://issuer_url> \
  --client-id xxxxx \
  ... options)


$REPO_URL=// translate somehow that <https://gitserver.test.com/username/repo.git> to <https://user>:$GIT_ACCESS_TOKEN@test.com/username/repo.git


git $GIT_ACTION $REPO_URL

Later something like:

alias git my_script.sh

should do the job. There is a glitch the native git client will cache the credentials (so when you do the other actions, like commit, pull), still the previous token will be cache. Ps. Regarding webauthn (if you want to validate also the device which is being use, it is an authorised one), I’ve been tried that how does it work from the console. So far I know with a modern browser works out of the box, as demonstrated in the demo, but IDK how to read a fido key from the console, so you can pass it to a script for example.

@Daniel - thanks for your quick and detailed answer. Yeah, introducing custom or wrapper clients is something that I came across too. Some commercial solutions also introduce lightweight agents on the client systems that tunnel specific traffic in an authenticated wrapper package (which shares some similarities with the VPN approach we are all used to, although technically this approach might have some benefits over a classic VPN). However the oauth2c project looks quite and I will definitely give it a shot.

I agree, also something else I saw it is they open a local socket. E.g.: Git Server is behind private VPC, you cannot connect from the outside, and the wrapper what it does, it is contact the edge auth server which it is also kind of a bastion, and create a socket, so the native client connect with the local socket created by the wrapper if connection is successful, but with this, you are not checking every requests (so, there is no really

context awareness

) as you said. The example also may be context-aware as long you have very short live tokens, which for the case of Git maybe fine but for another type of connection no