rewrite/redirect just after authentication

Peter Schober peter.schober at univie.ac.at
Wed Apr 13 09:20:45 UTC 2022


* Marco Broglia <marco.broglia at mutex.it> [2022-04-13 11:05]:
> <Location />
>     AuthType shibboleth
>     ShibRequestSetting requireSession true
>     Require shib-session
> </Location>
> 
> RewriteCond %{LA-U:REMOTE_USER} .+
> RewriteRule ^/(.*) https://.../$1 [R,L]
> 
> The two goals are:
>  [major] redirect only auth'ed user to another (external) url

That seems like a pointless thing to do: Obviously this doesn't
prevent unauthorised (or even unauthenticated) access to the resource
you redirect to. I.e., once the target URL somehow "leaks" (logs,
browser history, social engineering, etc.) there's no need to even
access your web server running the Shib SP and instead go to the
target URL straight away.
If OTOH the target URL is protected by some SSO protocol you wouldn't
need the above.

The web server running the Shib SP could of course be configured as an
HTTP Reverse Proxy instead of merely redirecting the client to the
actual resource. If there's no other way to protect the target URL
that would at least be (potentially) secure, provided direct access to
the target URL can be disabled (i.e., any access should only be
allowed coming from the reverse proxy itself.)

> WARN Shibboleth.SSO.SAML2 [21] [default]: error processing incoming
> assertion: Invalid HTTP method (GET)

That means something accesses the endpoint the SP uses for the
HTTP-POST protocol bindung with HTTP GET. You'll be able to clearly
see that also in your web browser, e.g. using the SAMLtracer extension.

That could be a misconfigured/broken SAML IDP (e.g. KeyCloak defaults
to using HTTP GET for the transmission of the SAML Response from the
SAML IDP to the SAML SP, IIRC, which isn't even legal in SAML) or
maybe a SAML IDP with misconfigured/broken metadata for the SP.

Or something else entirely is messing with the web browser's request,
e.g. a network "security" appliance.

> - [minor] curl returns bad metadata (two concatenated output) when the
>     RewriteCond/Rule is present (it's ok without the rules)

Bad how? What is being concatenated?

-peter


More information about the users mailing list