I’ve successfully provisioned apache web server using mod_auth_openidc to protect our internal dashboards, using Auth0 and Google App Oauth, described in this documentation:
– https://github.com/zmartzone/mod_auth_openidc#openid-connect-sso-with-google-sign-in
– https://auth0.com/docs/quickstart/webapp/apache/01-login (without using auth0 rule pipeline)
My question is how to pass the user’s claim to the upstream layer (our internal tools/dashboards) as http header? Is it possible?
Regards,
Agung
UPDATED
I’ve tried with the suggestion here,
here’s the snippet of my /etc/apache2/sites-available/000-default.conf
<VirtualHost *:443>
ServerName my-host-name
UseCanonicalName on
ProxyPreserveHost on
DocumentRoot /var/www/html
# Pass the user's claim as http headers
OIDCPassClaimsAs "headers"
OIDCPassUserInfoAs "claims"
OIDCPassRefreshToken "On"
<Location />
AuthType openid-connect
<RequireAll>
Require claim email~^(.*)@domain.com$
Require claim email_verified:true
</RequireAll>
ProxyPass http://echo-server.default.svc.cluster.local:8080/
ProxyPassReverse http://echo-server.default.svc.cluster.local:8080/
LogLevel debug
</Location>
</VirtualHost>
I am using echoserver (gcr.io/google_containers/echoserver:1.0) as the backend of http://echo-server.default.svc.cluster.local:8080, and it doesn’t print any user’s claim as http headers. Is there any misconfiguration on my part? How to debug this problem?
2
Answers
That’s what the module does by default: it will pass the user’s claims in both environment variables and headers, which can be configured with
OIDCPassClaimsAs
as documented in:https://github.com/zmartzone/mod_auth_openidc/blob/v2.3.8/auth_openidc.conf#L668
Note that those headers are added to the backend HTTP request that is propagated to the application so you won’t see them in a browser.
I’m using docker image httpd:2.4-buster, installing libapache2-mod-auth-openidc at version 2.3.10 from the Debian package repo, and proxying requests for a sub-location (not /). I turned on debug by adding
LogLevel auth_openidc:debug
tohttpd.conf
and then I saw traces of the set-header and set-env calls for claims. But using the setup above, I could not observe any OIDC-set headers arriving at the proxied Python Flask WSGI app.My workaround was converting environment variables into headers. I added the following config lines inside the
<Location>
block for the REST API path, that’s within a<VirtualHost>
block of Apache HTTPD config:Then the app gets both the user name and fully qualified [email protected] as request headers.
Update: Got further help from @hans-z via a discussion @ https://github.com/zmartzone/mod_auth_openidc/discussions/705
That discussion taught me that the WSGI http server silently drops all headers that contain an underscore in the name! An alternate solution (instead of converting environment variables to headers) is to change the mod-auth-openidc prefix string like this in a httpd.conf file:
Then all the headers set by mod-auth-openidc survive the trip into the proxed Flask + WSGI app.