OIDCUnAuthAction pass not transmitting headers since version 2.4.11

Question

OIDCUnAuthAction pass not transmitting headers since version 2.4.11

cm0s opened this issue 2 years ago · comments

Hello,

First and foremost, thank you very much for all the incredible work done on this terrific module!

Is there any known issue with the option OIDCUnAuthAction pass and the new release 2.4.11?

I've been using OIDCUnAuthAction in order to make a web application public/not authenticated but at the same time give the possibility to users to have an authentication URL to get access to the application as an authenticated user.

is configured with OIDCUnAuthAction pass this way all can be access as not authenticated or authenticated.
Inside a <Location /main/login>, I set the option OIDCUnAuthAction auth. This way user can access myapp.com/main/login, get authenticated and then get access to all other as an authenticated user. The application behind can then retrieve HTTP headers to display specific things for authenticated users.

Until version 2.4.10, this was working perfectly, but with the last 2.4.11 version, after authentication, when accessing using the OIDCUnAuthAction pass, claims are not transmitted anymore. A session cookie is correctly created and transmitted from the client side.

Above is the configuration I'm using. When upgrading to version 2.4.11, I just had to set the OIDCXForwardedHeaders, as explain in the changelog.

If I remove the OIDCUnAuthAction pass option, application s requires authentication and the claims are correctly transmitted.

If it can help, I can send debug logs.

<VirtualHost *:80>

  ServerName https://myapp.com

  <LocationMatch "^/?$">
    Require all denied
  </LocationMatch>

  <Location "/oidc-callback">
    AuthType openid-connect
    Require claim "upn~^[\\w-]*@\\w+\\.com$"
  </Location>

  <Location "/main">
    Allow from all
    RewriteEngine On
    ProxyPreserveHost On

    RewriteRule ^/var/www/html/main(.*)$ http://myapp-web-main-mynamespace.svc.cluster.local/$1 [L,P]
    ProxyPassReverse http://myapp-web-main-mynamespace.svc.cluster.local/

    AuthType openid-connect
    Require claim aud:${OIDC_CLIENT_ID}
  </Location>

  <Location "/main/api">
    RewriteEngine On
    ProxyPreserveHost On

    RequestHeader set X-Forwarded-Prefix "/main/api"
    RewriteRule ^/var/www/html/main/api/(.*)$ http://my-app-backend-main.mynamespace.svc.cluster.local:8080/$1 [L,P]
    ProxyPassReverse http://my-app-backend-main.mynamespace..svc.cluster.local:8080/

    AuthType auth-openidc

    Require claim aud:${OIDC_CLIENT_ID}
    Require claim appid:${OIDC_CLIENT_ID}
  </Location>

  <Location "/main/login">
     AuthType openid-connect

     Require claim aud:${OIDC_CLIENT_ID}

     OIDCUnAuthAction auth
     RewriteEngine On
     ProxyPreserveHost On

     RewriteRule ^/var/www/html/main/login(.*)$ https://myapp.com/main/$1 [L,R]
  </Location>

  OIDCUnAuthAction pass

  # In order to avoid calling userinfo_endpoint the OIDCProviderUserInfoEndpoint must not be set
  # For this reason, it's not possible to use the OIDCProviderMetadataURL option, every OIDCProvider
  # URL must be set manually to ensure the userinfo_endpoint is not set.
  # For more information see discussion : https://groups.google.com/g/mod_auth_openidc/c/Fw9dGXPXrNY/m/_YOn3fF-AQAJ

  OIDCProviderIssuer https://adfs.mycompany.com/adfs
  OIDCProviderAuthorizationEndpoint https://aadfs.mycompany.com/adfs/oauth2/authorize/
  OIDCProviderJwksUri https://adfs.mycompany.com/adfs/discovery/keys
  OIDCProviderTokenEndpoint https://adfs.mycompany.com/adfs/oauth2/token/
  OIDCProviderEndSessionEndpoint https://adfs.mycompany.com/adfs/oauth2/logout

  OIDCSessionInactivityTimeout 3600
  OIDCSessionMaxDuration 28800
  OIDCCryptoPassphrase ${OIDC_CRYPTO_PASSPHRASE}
  OIDCClientID ${OIDC_CLIENT_ID}
  OIDCClientSecret ${OIDC_CLIENT_SECRET}

  OIDCRedirectURI https://myapp.com/oidc-callback

  OIDCScope "openid allatclaims"
  OIDCRefreshAccessTokenBeforeExpiry 60
  OIDCPassClaimsAs headers
  OIDCRemoteUserClaim upn
  OIDCXForwardedHeaders X-Forwarded-Host X-Forwarded-Port X-Forwarded-Proto

  OIDCCacheType memcache
  OIDCMemCacheServers myapp-memcached-main.mynamespace.svc.cluster.local:11211

  LogLevel warn

  #Option to allow url with encoded slashes in the query params such as ?date=2020%2F2021
  AllowEncodedSlashes NoDecode

</VirtualHost>

Hans Zandbelt · Answer 1 · Fri Feb 11 2022 17:40:18 GMT+0800 (China Standard Time)

unfortunately that looks like a bug indeed, can you send the full server debug logs?

Nicolas Forney · Answer 2 · Fri Feb 11 2022 17:45:33 GMT+0800 (China Standard Time)

Of course, do you have an email or another means of communication I can use to send it to you privately ?

Hans Zandbelt · Answer 3 · Fri Feb 11 2022 17:46:42 GMT+0800 (China Standard Time)

in this case you can send it to: support@zmartzone.eu

Nicolas Forney · Answer 4 · Fri Feb 11 2022 18:00:49 GMT+0800 (China Standard Time)

Thank you, I sent the email.

Nicolas Forney · Answer 5 · Fri Feb 11 2022 23:26:15 GMT+0800 (China Standard Time)

I created a simpler version of my config here, removing memcached and other config (by the way, it uses port 80 in the virtual host because SSL connection is handled earlier by a Traefik proxy).

As mention by @zandbelt (in a private message), this problem might be related to my config which worked by accident before and is not working now for good reason.

To ensure it's really a bug, I'll have to reproduce it in a simpler environment, not on my complex company environment. I just have to find the time to create this test environment. By the time if someone encounters the same issue, don't hesitate to comment on this issue.

<VirtualHost *:80>
  ServerName https://myapp.com

  <Location "/">
    Allow from all
    RewriteEngine On
    ProxyPreserveHost On

    RewriteRule ^[/]*var/www/html/(.*)$ http://myapp-web.mynamespace.svc.cluster.local/$1 [L,P]
    ProxyPassReverse http://myapp-web.mynamespace.svc.cluster.local/
    
    AuthType openid-connect
    Require claim aud:${OIDC_CLIENT_ID}
  </Location>

  <Location "/api">
    RewriteEngine On
    ProxyPreserveHost On
    OIDCUnAuthAction pass
    RewriteRule ^/var/www/html/api/(.*)$ http://myapp-backend.mynamespace.svc.cluster.local:8080/$1 [L,P]
    ProxyPassReverse http://myapp-backend.mynamespace.svc.cluster.local:8080/

    AuthType auth-openidc

    Require claim aud:${OIDC_CLIENT_ID}
    Require claim appid:${OIDC_CLIENT_ID}
  </Location>

  <Location "/oidc-callback">
    AuthType openid-connect
    OIDCUnAuthAction auth
    Require claim "upn~^[\\w-]*@\\w+\\.ch$"
  </Location>

  <Location "/login">
     AuthType openid-connect
     Require claim aud:${OIDC_CLIENT_ID}
     OIDCUnAuthAction auth
  </Location>

  # In order to avoid calling userinfo_endpoint the OIDCProviderUserInfoEndpoint must not be set
  # For this reason, it's not possible to use the OIDCProviderMetadataURL option, every OIDCProvider
  # URL must be set manually to ensure the userinfo_endpoint is not set.
  # For more information see discussion : https://groups.google.com/g/mod_auth_openidc/c/Fw9dGXPXrNY/m/_YOn3fF-AQAJ
  OIDCProviderIssuer https://adfs.mycompany.com/adfs
  OIDCProviderAuthorizationEndpoint https://adfs.mycompany.com/adfs/oauth2/authorize/
  OIDCProviderJwksUri https://adfs.mycompany.com/adfs/discovery/keys
  OIDCProviderTokenEndpoint https://adfs.mycompany.com/adfs/oauth2/token/
  OIDCProviderEndSessionEndpoint https://adfs.mycompany.com/adfs/oauth2/logout

  OIDCCryptoPassphrase ${OIDC_CRYPTO_PASSPHRASE}
  OIDCClientID ${OIDC_CLIENT_ID}
  OIDCClientSecret ${OIDC_CLIENT_SECRET}
  OIDCRedirectURI https://myapp.com/oidc-callback
  OIDCScope "openid allatclaims"
  OIDCPassClaimsAs headers
  OIDCRemoteUserClaim upn
  OIDCXForwardedHeaders X-Forwarded-Port
  OIDCUnAuthAction pass

  LogLevel debug
</VirtualHost>

Hans Zandbelt · Answer 6 · Thu Feb 17 2022 00:01:17 GMT+0800 (China Standard Time)

for the record: at first inspection it seems that for some locations there is no AuthType set, but there is a Require claim directive applied to them (not sure why it would work before then though)

Nicolas Forney · Answer 7 · Thu Feb 17 2022 04:04:45 GMT+0800 (China Standard Time)

Thank you for looking, but it seems every location has an AuthType, or perhaps I'm cross-eyed ;). The problem is probably somewhere else. I'm going to reproduce it outside of my environment, in a reproducible way, so we can really see if it's a bug or just me not knowing how to properly use your module ;). I should find time to do it in a few days.

Hans Zandbelt · Answer 8 · Mon Mar 14 2022 09:58:55 GMT+0800 (China Standard Time)

any luck with that?

Nicolas Forney · Answer 9 · Wed Mar 16 2022 18:40:33 GMT+0800 (China Standard Time)

I just finished refactoring my Apache configs (was using RewriteRule inside which is not supported). Will retry now with the last mod_auth_openidc version and keep you informed.

Nicolas Forney · Answer 10 · Fri Mar 18 2022 22:00:06 GMT+0800 (China Standard Time)

I tried with my new Apache config and the issue is still occurring. For now, I will stay on version 2.4.10, but sooner or later I will have to upgrade to a newer version of your module and will have to solve this problem. When the time's gonna come, I will try to reproduce the problem in a new environment with minimum configuration (I cannot find the time to do it now). In the meantime, you can close my issue. I will reopen it or create a new one later.

Hans Zandbelt · Answer 11 · Fri Mar 18 2022 22:05:07 GMT+0800 (China Standard Time)

let's leave it open, I may find time to re-create the issue myself

Hans Zandbelt · Answer 12 · Mon Mar 21 2022 15:29:19 GMT+0800 (China Standard Time)

let's leave it open, I may find time to re-create the issue myself

@cm0s can you send the latest and simplest config that exposes this behaviour?

Hans Zandbelt · Answer 13 · Tue Mar 22 2022 02:37:11 GMT+0800 (China Standard Time)

I was able to reproduce and fix; @cm0s please test 3f082c1 and confirm

Nicolas Forney · Answer 14 · Wed Mar 23 2022 23:07:49 GMT+0800 (China Standard Time)

Great, thanks a lot @zandbelt! I'm going to build the rc5 version and test it. Will keep you informed.

Nicolas Forney · Answer 15 · Tue Mar 29 2022 21:32:18 GMT+0800 (China Standard Time)

I've been able to build the rc5 and test the fix. Claims are now correctly passed when I use OIDCUnAuthAction pass.

Thanks a lot for the work!

Maximilian Weber · Answer 16 · Tue Jan 10 2023 18:45:47 GMT+0800 (China Standard Time)

...after trying for some days, it seems like we have the same issue with (not only) the latest release 2.4.12.2:

    OIDCProviderMetadataURL (...)
    OIDCClientID (...)
    OIDCClientSecret (...)
    OIDCRedirectURI /redir

    OIDCRemoteUserClaim preferred_username

    #OIDCCookieDomain (...)

    <Location "/redir">
        AuthType openid-connect
        Require valid-user
    </Location>

    OIDCUnAuthAction pass

What could be the reason for not getting any "lazy session" headers?

(We are implementing SSO and just want to indicate existing auth)

Hans Zandbelt · Answer 17 · Tue Jan 10 2023 18:52:32 GMT+0800 (China Standard Time)

"lazy session" headers are passed on OIDCUnAuthAction pass, I don't see that in your config?

Maximilian Weber · Answer 18 · Tue Jan 10 2023 18:59:37 GMT+0800 (China Standard Time)

"lazy session" headers are passed on OIDCUnAuthAction pass, I don't see that in your config?

Absolutely, my fault, I updated the code snippet accordingly (and double checked our setup - same as the snippet and not working yet).

P.S.: Awesome work & awesome response time – worth sponsoring!

Hans Zandbelt · Answer 19 · Tue Jan 10 2023 19:02:33 GMT+0800 (China Standard Time)

I just verified myself that this still works as expected; since you're sponsoring you can send your server debug logs to support@openidc.com and we'll take a look, tnx