imkira / gcp-iap-auth Goto Github PK

The current release is not compatible with IAP because it's looking for the wrong header. This was fixed in 91f16a3.

Users of package managers that pull down a release will be pulling a broken version of this package until a new release is created.

The last release from this code base is from 2017, which does not match the latest code in the repo and therefore I needed to fork and create my own release here - https://github.com/RobertNorthard/gcp-iap-auth/releases

n proxy mode we can specify a header that will be filled with the validated email address from the JWT token. The value will only contain the email address, eg: [email protected]:

gcp-iap-auth --audiences=YOUR_AUDIENCE --backend=http://localhost:8080 --email-header=X-WEBAUTH-USER

Can we have another header just to provide username? eg: name from [email protected] using --name-header=X-WEBAUTH-NAME

When running in reverse proxy mode, how does gcp-iap-auth handle keepalive at downstream and upstream? Will it disconnect after every request or re-use the connection? If latter, what is the idle timeout and will it honor "Connection: close" or other keepalive related http headers?

I would like to use gcp-iap-auth as a proxy in front of other webapps: [iap] -> [gcp-iap-auth] -> [backend app]. Assuming this will work. I started working on a small utility to do this and realized I was importing so much of gcp-iap-auth that maybe it would make sense to implement proxy-mode as an option, perhaps a flag like -proxy http://localhost:8080.

I am happy to send a PR, time permitting, if you think this may be acceptable?

Hi,

my instance of gcp-iap-proxy stopped working. All authentications failed and log was full of Failed to authenticate "[email protected]" (No public key for "2nMJtw"). Restart solved the issue.

I guess that public keys are loaded once when process starts. If Google changes them, restart is necessary.

When running gcp-iap-auth in proxy mode, it would be great to let the traffic through, not giving 401, in case when the jwt can't be validated or doesn't exist. This will allow backend application to provide the guest content or secondary login option.

In such cases, the gcp-iap-auth should clear the bad jwt header, and also clear the email-header, etc. to prevent clients from spoofing the login. The backend can then trust the email-header to decide if it is authenticated request or anonymous request.

Hi there - can this be used to secure access to a private GCS bucket?

I want to host some private static content, and I'm hoping to be able to IAP -> G-LB/CDN -> {thing} -> GCS bucket.

As of #3, the examples no longer compile.