Override result of oidc_util_request_is_secure for Secure attribute with config directive

[studersi]

There are cases where the Apache instance running mod_auth_openidc is not the one performing TLS termination.
For example, in containerized environments, like cloud environments with edge TLS termination, the connection might be TLS encrypted between the user-agent and the edge proxy but not between the edge proxy and the Apache instance running mod_auth_oidc.
In this case the Secure attribute for the OIDC cookie is still desired but oidc_util_request_is_secure will return false and the Secure attribute is thus not set.
This is particularly bothersome in cases where SameSite=None is required as it cannot be used without the Secure attribute.

A configuration option analogous to OIDCCookieHTTPOnly could be added for such cases to override the result of oidc_util_request_is_secure where the default value Auto corresponds to the current behaviour.

For example:

# Defines whether the Secure flag will be set on cookies.
# When not defined the default is Auto.
# 
# Auto -> Secure flag is set if the current connection is secured with TLS
# On -> Secure flag is always set
# Off -> Secure flag is never set
# 
#OIDCCookieSecure [Auto|On|Off]

A possible workaround is to set OIDC_SET_COOKIE_APPEND to include both Secure and SameSite=None.

Would it be possible to add such a directive to override the result of oidc_util_request_is_secure when it comes to setting the Secure attribute?

[zandbelt]

I agree that this would be a useful addition; just to make sure, you are using OIDC_SET_COOKIE_APPEND today to achieve this?

Edit: thinking some more about this: in this situation one would typically use X-Forwarded-Proto on the load balancer to make things work anyhow, which would also solve this, isn't it?

[studersi]

Thank you for your response. Yes, setting the Secure attribute in OIDC_SET_COOKIE_APPEND removes the SameSite attribute but if both are set in OIDC_SET_COOKIE_APPEND we get the desired behaviour.

That is a good point regarding X-Forwarded-Proto I did not notice that this is taken into account but looking at the code, I agree, this should work as well. This might be the cleanest solution.

On that note, it looks like only the X-Forwarded-* headers are used. As far as I can tell the standardized header Forwarded is not used in mod_auth_openidc: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Forwarded.