How to pass user's claim to upstream layer using mod_auth_openidc?

Question

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?

Answer 1

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

# Define the way in which the claims and tokens are passed to the application environment:
# "none": no claims/tokens are passed
# "environment": claims/tokens are passed as environment variables
# "headers": claims/tokens are passed in headers (also useful in reverse proxy scenario's)
# "both": claims/tokens are passed as both headers as well as environment variables (default)
# When not defined the default is "both"
# The access token is passed in OIDC_access_token; the access token expiry is passed in OIDC_access_token_expires.
# The refresh token is only passed in OIDC_refresh_token if enabled for that specific directory/location (see: OIDCPassRefreshToken)
#OIDCPassClaimsAs [none|headers|environment|both]

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.

Answer 2

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 to httpd.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:

    # module sets REMOTE_USER as env var
    RequestHeader set X-Forwarded-User-Email %{REMOTE_USER}s

    # module sets OIDC_CLAIM_sub as env var
    PassEnv OIDC_CLAIM_sub
    RequestHeader set X-Forwarded-User %{OIDC_CLAIM_sub}e

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:

OIDCClaimPrefix Oidc-Claim-

Then all the headers set by mod-auth-openidc survive the trip into the proxed Flask + WSGI app.