Questions about Shibboleth Attribute Access with modern Webservers

[Peter Schober]

Vivienne,

Unless axum has support for inbound FCGI or uwsgi or AJP (all of which
would enable the transmission of server environment variables from
Apache httpd to the other server) you're left with HTTP Proxying.
There's hardly a modern software stack that's not heavily relying on
HTTP proxying (for better or for worth), though, so this isn't the end
of the world.

Just make sure the protected ressource (the axum-based web server)
only listens on the loopback interface or (even better) on a Unix
socket, making direct access to the protected ressource (without going
through Apache httpd and Shibboleth) much harder.
(For containerised deployments the implementation of that will need to
differ but the same principles apply: Custom network between
front-end web server container and back-end web server container, RFC
1918 IP-adresses between containers, etc.pp.)

Scott Cantor via users <users at shibboleth.net> [2026-08-14 17:41 CEST]:
> That doesn't mean the headers being produced by Apache as a proxy
> have to come from headers (and they shouldn't). Outbound header
> creation can generally source from the secure server environment.

Right. So forget anything concerning Headers vs. Environment variables
in the Shibboleth docs. Then in your httpd config, just make sure
attributes are available (via at least passive protection[1]) and
where you're proxying requests to axum set HTTP request headers as
needed, e.g.: RequestHeader set X-SubjectID: %{subject-id}e

HTH,
-peter

[1] AuthType shibboleth
    Require shibboleth