Can't find attribute REMOTE_USER value in https request

Peter Schober peter.schober at univie.ac.at
Wed Jul 18 17:28:43 EDT 2018


* Tony Ennis <tennis at eagle6.com> [2018-07-18 20:26]:
> I don't see REMOTE_USER being returned to my application endpoint.

Since we know nothing technically specific about your application
deployment let's keep it that way and concentrate on httpd running the
Shib SP.

> Here are some of the configs and results that seem important.
> 
> https://imgur.com/a/rCQwuw0

The httpd access log of you accessing /Shibboleth.sso/Login and
/Shibboleth.sso/Session is irrelevant. (Access to the SP's own
handlers is immaterial as that couldn't ever be protected by the Shib
SP, you'd never get anywhere.)

What would be telling is the log of you accessing a resource (that's
not the SP's own handlers) served by httpd with active or passive
configured by the Shib SP, I've already sent pointers to the docs.
Earlier you claimed to having already configured passive protection
for the whole virtual host (Location /), so essentially all you need
to verify that the SP is fully working is accessing anything on that
server, e.g. /foo, *after* first having established a session with the
SP (as you can verify by checking /Shibboleth.sso/Session).

The response from httpd (302 or 404 or whatever) is mostly immaterial,
you're interested in the access log line, whether or not that contains
the value of REMOTE_USER for accessing the resource.


As for the next image, your inclusion of sn and givenName in
REMOTE_USER are highly inappropriate (givenName or is are not suitable
for identification even with a small organization), but technically
legal.  If all you care about is 'uid' just remove all other
attribute-ids from that setting.

The screenshot from /Shibboleth.sso/Session shows uid is mapped fine,
so that (and other stuff, including the IDP) are not of our concern
here.

> https://imgur.com/ZArrzqg

Again that provides no info (see above for why).

> I've also dumped out the entire http request when control was
> returned to my endpoint; I see no evidence of REMOTE_USER anywhere
> there.

That could mean many different technical things (on what server? httpd
or nginx; also REMOTE_USER is not a request-anything, it's a CGI
variable internally to httpd), so let's ignore that, too.

-peter


More information about the users mailing list