Headers no coming back to Apache Shibboleth Service Provider

[Cahill, Charles (GE Appliances)]

Thanks !

I am able to see the headers coming now by going into the shibboleth2.xml and 
setting "showAttributesValues to true"  Now to see if I can get the application to read the
headers, I will be in business.

<Handler type="Session" Location="/Session" showAttributeValues="true"/>

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
Sent: Tuesday, November 24, 2015 5:50 AM
To: users at shibboleth.net
Subject: Re: Headers no coming back to Apache Shibboleth Service Provider

* Cahill, Charles (GE Appliances) <Charles.Cahill at ge.com> [2015-11-24 03:37]:
> Can anyone give me an idea why headers are coming back to my 3rd party 
> SAML 2.0 clients but dont seem to be coming back to my Apache Service 
> Provider configurations.

There is no connection whatsoever among those, as HTTP Request Headers is not what is being sent to those other SAML SPs, but SAML assertions. Everything else is local to the SP.

> ShibUseHeaders On

That's not recommended (as per the docs) but should be sufficient, i.e., the mod_headers directives for explicitly setting attributes are not needed.
Possibly that's also what breaks this, as you first tell mod_shib to use headers, not environment variables, and then tell mod_headers to populate headers from certain environment variables.  So you're likely doing too much.
Also and more fatally, you're setting those headers on the virtual host level but you only protect the location /NPI/, so those environment variables can never be there for access to e.g. / or /foo If it doesn't work (whatever that means in detail) when accessing /NPI/ that's a different / another error from headers not showing up when accessing / or /foo.
Check the documentation, NativeSPGettingStarted, then follow the link to Apache httpd on how to enable attributes in other locations without enforcing protection there ("lazy sessions").
TL;DR: authtype shibboleth, require shibboleth (depending on httpd version).

Finally, this is on a plain http vhost (port 80) so either your virtualization will be broken (if you're offloading TLS) or people will get security warnings from their browsers during SSO due to the HTTP POST from the (hopefully) HTTPS-secured IDP to the plain-HTTP SP.
So don't do that.
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net