Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xenophonf opened this issue Mar 6, 2018 · 4 comments
Open

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

xenophonf opened this issue Mar 6, 2018 · 4 comments

Comments

@xenophonf
Copy link
Contributor

xenophonf commented Mar 6, 2018

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
Copy link
Contributor Author

@huebnd
Copy link

huebnd commented Aug 17, 2018

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
Copy link

ygrange commented Mar 18, 2021

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
Copy link
Member

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

guillomovitch pushed a commit to Renater/SATOSA that referenced this issue Jan 21, 2025
declare only relative URLs in configuration, so as to fix registration
when base URL contains a path (issue IdentityPython#179), and expose those endpoints
to outer world by appending base URL when needed.

This is much simpler than parsing absolute URLs, and more consistent
with OIDC frontends behaviour.
guillomovitch pushed a commit to Renater/SATOSA that referenced this issue Jan 22, 2025
declare only relative URLs in configuration, so as to fix registration
when base URL contains a path (issue IdentityPython#179), and expose those endpoints
to outer world by appending base URL when needed.

This is much simpler than parsing absolute URLs, and more consistent
with OIDC frontends behaviour.
guillomovitch pushed a commit to Renater/SATOSA that referenced this issue Jan 22, 2025
declare only relative URLs in configuration, so as to fix registration
when base URL contains a path (issue IdentityPython#179), and expose those endpoints
to outer world by appending base URL when needed.

This is much simpler than parsing absolute URLs, and more consistent
with OIDC frontends behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants