Apache Shib SP and target URL rewrite

[Peter Schober]

* Jan Vilhuber <JVilhuber at absolute.com> [2017-03-15 10:53]:
> > [...] but what do you mean with passing things on to an external
> > service, specifically? Unless the webserver with the Shib SP is
> > acting as a reverse proxy to your "external resource" (i.e., no
> > direct access is possible to the resource, but *only* through the
> > proxy) that's likely insecure or requires a(nother) SSO protocol,
> > or both. Cf. https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPOneMany
>
> [JV:] Yes, apache is acting as a reverse proxy, so I can't use
> environment variables, unfortunately. What I was referring to was
> that I could write a short-ish cgi-script of some kind, that resides
> on the server, and can thus use the environment (which is safer),
> gather the data from them, and make an API call of some kind to a
> server that resides behind the GW (and apache would not let direct
> access to).

I do occasionally proxy and send HTTP Headers, but then in all such
cases the proxy and the proxied resource are actually on the same
system (i.e., I put the Shib SP on the same machine), making this more
of an operational issue, and less of a security one, IMO.

> imperfect steps :-/ And I can wrap some static api-key around this
> internal (probably should have used that word instead of 'external'
> which implies "out in the world") API call to give it the shine of
> security.

If you're certain the proxied resource cannot be accessed other than
from authorized requests (Shib) and through httpd+mod_proxy maybe
simpy prefixing all attribute names with loooong and ugly strings
would suffice, essentially appending "shared secrets" to them, making
them harder to guess/inject.
(Of course the data is still exposed on the network to the proxied
resource unless you're proxying via TLS, too, e.g. using
`SSLProxyEngine on` in httpd.)
-peter