BASE must not include a path in mod_wsgi-hosted deployments

[xenophonf]

Code Version

master (v3.4.8)

Expected Behavior

I should be able to host SATOSA at any valid URL path, e.g., setting BASE to https://federation.example.com/satosa.

Likewise, the following values of BASE should be treated the same: https://federation.example.com/ and https://federation.example.com. However, only the latter value of BASE results in a working configuration.

Current Behavior

If one hosts the SATOSA WSGI application at a path other than /, and if one sets BASE in the SATOSA proxy configuration file to something other than <scheme>://<host>, then the SAML back end registers invalid endpoint mappings, e.g. with BASE set to https://federation.example.com/satosa, it sets up these mappings (url_map):

[
  ('^satosa/Saml2/acs/post$', 
   functools.partial(<bound method SAMLBackend.authn_response of <satosa.backends.saml2.SAMLBackend object at 0x7fcfc24a61d0>>, 
   binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST')), 
  ('^satosa/Saml2/acs/redirect$', 
   functools.partial(<bound method SAMLBackend.authn_response of <satosa.backends.saml2.SAMLBackend object at 0x7fcfc24a61d0>>, 
   binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'))
]

This results in the following error:

Unable to determine the entityID's for the IdP or SP

Whereas with BASE set to https://federation.example.com, it sets up these mappings

[
  ('^/Saml2/acs/post$', 
   functools.partial(<bound method SAMLBackend.authn_response of <satosa.backends.saml2.SAMLBackend object at 0x7f89c4aff1d0>>, 
   binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST')), 
  ('^/Saml2/acs/redirect$', 
   functools.partial(<bound method SAMLBackend.authn_response of <satosa.backends.saml2.SAMLBackend object at 0x7f89c4aff1d0>>, 
   binding='urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect'))
]

Due to differences in how the SAML front end configures endpoint mappings, it works as expected for both values of BASE.

Possible Solution

This might be related to issue #148.

As a workaround for situations where one might wish to co-locate SATOSA and other web applications or content on the same virtual host, use the WSGIScriptAliasMatch directive with a negative lookahead; for example:

WSGIScriptAliasMatch ^/(?!(Shibboleth\.sso|registry|img|css|js|favicon.ico|error.html)) /usr/lib/python3.6/site-packages/satosa/wsgi.py

Steps to Reproduce

1. Deploy SATOSA using mod_wsgi.
2. Use WSGIScriptAlias /satosa ... instead of WSGIScriptAlias / ....
3. Set BASE in proxy_conf.yaml to <scheme>://<host>/satosa.
4. Log into a SAML SP behind SATOSA; note the error when a SAML IdP posts a SAML authentication response to SATOSA's ACS endpoint.

[xenophonf]

Cf. my posts to the satosa-users mailing list:

https://lists.sunet.se/pipermail/satosa-users/2018-February/000029.html https://lists.sunet.se/pipermail/satosa-users/2018-March/000030.html

[huebnd]

Is there any update to this issue? I imagine, that the same limitations apply to running e.g. the docker container with a reverse proxy web server in front of it, since you'd have to set BASE in proxy_conf.yaml to the real path anyways.

Has anyone gotten the SAML plugins to work with SATOSA deployed on a BASE path other than root?

[ygrange]

I assume this is still an open issue? I have a hard time getting SATOSA up in any case but I certainly need it to run behind a URL path.

[c00kiemon5ter]

Hello, this is still an issue. I will try to boost development and move forward with this.