Unexpected 401 on step-up authorization in the module version 2.4.19.2

[perry19987]

Hi all,

I updated from a previous release (2.4.15.3) to the latest (2.4.19.2) and I found a possible regression.
We have a 401 while we perform a legit step-up authorization from a POST request; so, having this configuration during a step-up az:

• OIDCUnAutzAction auth
• OIDCPreservePost On
  we encounter a 401.

Did anyone else find the same behavior?
@zandbelt could it be a regression or just my missconfiguration?

Thanks for help,
Pier

[zandbelt]

to answer that question we'd need the complete config related to mod_auth_openidc (including the relevant and Require statements), the server log using LogLevel auth_openidc:debug and preferably the browser trace, or at least all HTTP Request headers that are sent with the failing request

[zandbelt]

a CI test in our dev environment shows no problem with this setup:

  <Location /openidc/post-preserve>
    AuthType openid-connect
    Require claim scope:admin
    OIDCUnAutzAction auth
    OIDCPathScope admin
    OIDCPreservePost On
  </Location>

resulting in a HTML response with a meta refresh tag that contains an authentication request/redirect

[perry19987]

I attach here the file you asked @zandbelt where we perform a step-up authorization from APPLICATION1 to APPLICATION2
vhost.conf.txt
browser.har.txt
access.log.txt
error.log.txt

[perry19987]

Hello @zandbelt , did you have the chance to review the config and evidences?
Thanks.

[zandbelt]

Unfortunately this appears to be a limitation of the implementation, see https://github.com/OpenIDC/mod_auth_openidc/wiki/Known-Limitations#post-data-preservation-2-and-authorization--step-up-authentication ; we'll modify the text to reflect that running over https does not seem to mitigate this (anymore)

[perry19987]

@zandbelt thanks for the update.
May I ask you if this is a known issue / regression since a specific version? For example release 2.4.14.2 or 2.4.15.3 don't seem to be affected.

[zandbelt]

the reason that it worked before is because of an unexpected side effect

[perry19987]

@zandbelt got it. Last few questions:

• this issue is a technical non-negotiable constraint (maybe tied to underlying libraries and/or the Apache HTTP Server itself),
  or is it something specific to the module and therefore potentially fixable or addressable through further developments and support from both side?
• the side-effect behavior that currently enables the functionality on earlier versions, could represent a source of instability for that functionality when running on those older versions?

Thanks again and really appreciate for support and help.