Skip to content

BASE must not include a path in mod_wsgi-hosted deployments #179

Open
@xenophonf

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions