Stale request about django-shibboleth-remoteuser HOT 8 CLOSED

@sternj please give more details. Can you post the full traceback?

from django-shibboleth-remoteuser.

The docker-compose is located here. Upon navigating to localhost/web (specified in the httpd-proxy container routing to the sp container), I get the following screen:

The text of the log starting from the request is this. Note that the configuration for that specific container is located in /sp/etc-httpd/conf.d/sp.conf

web_1            | [13/Aug/2018 19:49:51] "GET / HTTP/1.1" 302 0
sp_1             | sp-native 2018-08-13 19:49:51 WARN Shibboleth.Config : DEPRECATED: legacy 2.0 configuration, support will be removed from a future version of the software
sp_1             | sp-native 2018-08-13 19:49:51 WARN Shibboleth.RequestMapper : DEPRECATED: legacy 2.0 configuration, support will be removed from a future version of the software
sp_1             | sp-native 2018-08-13 19:49:51 WARN Shibboleth.Application : handlerSSL should be enabled for SSL/TLS-enabled web sites
idp_1            | 2018-08-13 19:49:52,083 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request
idp_1            | org.opensaml.messaging.decoder.MessageDecodingException: No SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP Redirect message
idp_1            | 	at org.opensaml.saml.saml2.binding.decoding.impl.HTTPRedirectDeflateDecoder.doDecode(HTTPRedirectDeflateDecoder.java:108)
idp_1            | 2018-08-13 19:49:52,103 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: UnableToDecode
ldap_1           | tail: '/var/log/dirsrv/slapd-dir/access' has been replaced;  following end of new file
ldap_1           | 	389-Directory/1.3.7.5 B2018.178.1311
ldap_1           | 	localhost:389 (/etc/dirsrv/slapd-dir)
ldap_1           | 
ldap_1           | [13/Aug/2018:19:49:31.833164994 +0000] conn=1 fd=64 slot=64 connection from 172.19.0.7 to 172.19.0.4
ldap_1           | [13/Aug/2018:19:49:31.833386548 +0000] conn=1 op=0 BIND dn="cn=admin,dc=idptestbed" method=128 version=3
ldap_1           | [13/Aug/2018:19:49:31.833821186 +0000] conn=1 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0000581104 dn="cn=admin,dc=idptestbed"
ldap_1           | [13/Aug/2018:19:49:31.834867868 +0000] conn=1 op=1 UNBIND
ldap_1           | [13/Aug/2018:19:49:31.834889716 +0000] conn=1 op=1 fd=64 closed - U1
idp_1            | 2018-08-13 19:50:34,852 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request
idp_1            | org.opensaml.messaging.decoder.MessageDecodingException: No SAMLRequest or SAMLResponse query path parameter, invalid SAML 2 HTTP Redirect message
idp_1            | 	at org.opensaml.saml.saml2.binding.decoding.impl.HTTPRedirectDeflateDecoder.doDecode(HTTPRedirectDeflateDecoder.java:108)
idp_1            | 2018-08-13 19:50:34,854 - WARN [org.opensaml.profile.action.impl.LogEvent:105] - A non-proceed event occurred while processing the request: UnableToDecode

from django-shibboleth-remoteuser.

Try taking this package, and even django itself, out of the picture completely, and just make sure you can secure a URL with Shib. Once that's working, try django and this package again.

from django-shibboleth-remoteuser.

I can secure a URL with shib, navigating to / and clicking on the first link demonstrates that

from django-shibboleth-remoteuser.

with just a django app (not using this package), can you secure a django view and see your REMOTE_USER in request.META after you log in through Shib?

from django-shibboleth-remoteuser.

I'm not sure what you're asking here, I don't know how one would have a shib session (or a remote user) accessible to Django aside from using the integration interface that you provide. The error readout seems to indicate some sort of issues with saml decoding. Could the issue have to do with the fact that I ProxyPass to the Django server?

from django-shibboleth-remoteuser.

Yup, the issue could be with ProxyPass. For this package to work, you've got to be able to see REMOTE_USER (or some other header or environment variable you've configured) in request.META. When you secure a session with Shib, the REMOTE_USER env variable in Apache will be set (unless your shib is configured differently), and then Django can see it, and then this package can act on it.

You can remove this package completely, and just make sure that that REMOTE_USER header or environment variable is visible in request.META. If it's not visible, then the issue isn't anything in this package. And REMOTE_USER might not be set because of the ProxyPass setup, like you mention. We don't use this package with ProxyPass. You would need to pass through or set some header or environment variable in the request that actually gets to django - this might help: https://httpd.apache.org/docs/trunk/mod/mod_headers.html.

Here's how you would test it: set up your django app at /django_app. In your shib config, require a session for all /django_app URLs. When you visit it, you'll have to log in to shib. Then, you can see what's in your request.META information in the django view - there needs to be some information about the user that's logged in through shib. And this test doesn't require this package at all - it's just shib and django.

This page might be helpful: https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPAttributeAccess

from django-shibboleth-remoteuser.

I moved to a Flask implementation and ran into the same issue, I resolved it.
For future people with the same problem-- I resolved the issue by putting a specific subpath of my Django site behind Shibboleth protection (in Apache) and having the login link be to there instead of to the actual SSO link (which is what caused the stale request.

@bcail thank you for your help!!!

from django-shibboleth-remoteuser.