OIDCPreservePost response is incorrect when there is a claim authorization condition

[yagiaoskyworker]

There seem to be two problems when OIDCPreservePost is ON.
I think these are probably bugs, could you give me a comment?

Problems

• If OIDCPreservePost is On and there is claim condition, POST save contents and 401 error contents will be mixed.
• Since content-lentgh does not match the response body size, the response will not be returned correctly if it is passed through ALB etc.

My environments

OS: CentOS Linux release 7.9.2009 (Core)
OP: Keycloak 14.0.0
Apache: 2.4.6-99.el7.centos.1.x86_64
mod_auth_openidc: 2.4.15.1-1.el7.x86_64

Configuration

<VirtualHost *:80>

    ErrorLog "/var/log/httpd/service.example.com/error_log"
    TransferLog "/var/log/httpd/service.example.com/access_log"

    DocumentRoot /var/www/html

    ServerName service.example.com

    OIDCResponseType code
    OIDCCryptoPassphrase a-random-secret-used-by-apache-oidc-and-balancer
    OIDCProviderMetadataURL https://kc-server.example.com:443/auth/realms/demo/.well-known/openid-configuration

    OIDCClientID service
    OIDCClientSecret 08e95831-9807-40dd-9d3f-**********
    OIDCRedirectURI http://service.example.com/callback

    OIDCPreservePost On

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

    <Location /secure/>
        AuthType openid-connect
        Require claim realm_access.roles:admin
    </Location>

</VirtualHost>

How to reproduce

1. start capturing packets
2. OK pattern
   2.1 curl --request POST http://service.example.com/ -d "param1=value1&param2=value2"
   2.2. response and content-length are correct
3. NG pattern
   3.1. curl --request POST http://service.example.com/secure/ -d "param1=value1&param2=value2"
   3.2. response and content-length are incorrect
4. stop capturing packets

access_log

OK pattern:

192.178.185.145 - "" [06/Feb/2024:11:15:27 +0900] "POST / HTTP/1.1" 200 913

=> status code and content-length are correct

NG pattern:

192.178.185.145 - "" [06/Feb/2024:11:15:39 +0900] "POST /secure/ HTTP/1.1" 401 1294

=> status code and content-length are not correct

Network capture

OK pattern:

NG pattern:

[zandbelt]

this is indeed a limitation caused by the way the Apache internals work (redirecting in the authorization handler phase comes with restrictions); I have just added a section to the Known Limitations, thanks for reporting; from our tests it appears that a workaround would be to run over HTTPs rather than plain HTTP as Apache seems to apply some correctional measures wrt. the extra content added at the end of the reponse

[yagiaoskyworker]

Thank you for your comment.

I also tried accepting Apache via https, but it still didn't solve the problem.

After further investigation, we found that if ALB's HTTP/2 is enabled, POST save responses are not processed correctly. Turning off ALB's HTTP/2 seems to resolve the issue.

If ALB's HTTP/2 is ON, a screen like this will appear and processing will stop (you can see that the POST save content and the 401 error screen overlap).

The root cause is thought to be a mix of unnecessary 401 content and mismatched content-lengths, but in combination with ALB, turning off HTTP/2 seems to be a workaround.