Trouble getting attributes from Sibboleth into PHP/Tomcat

[Peter Schober]

* Keith Osborne <keith at tdrnetworks.com> [2013-05-26 17:29]:
> I believe I have Sibboleth set-up correctly (famous last words), 

Very famous last words indeed, if you reflect briefly on the history
of the word "Shibboleth" http://en.wikipedia.org/wiki/Shibboleth#Origin
(Saying "Sibboleth" reportedly cost the lifes of 42000 people.)

> Attributes
> DisplayName: Fedtest1, Dfw
> EmailAddress: dfw.fedtest1 at xx.com
> FirstName: Dfw
> GeographicUnit: United States
> LastName: Fedtest1
> enterpriseId: dfw.fedtest1
> persistent-id: dfw.fedtest1 at xx.com

Meaning all that was recieved and mapped correctly by the SP.

> I have tried the scripts for both PHP and Tomcat (via mod_jk connector 
> and Apache) here: http://shib.kuleuven.be/download/sp/test_scripts/

Mostly obsolete now that the SP's Session handler shows all mapped
atributes. In this case doing it externally is helpful though, but you
wouldn't need more than <?php print_r($_SERVER); ?> to find that out.

> My main efforts are focussed around a Tomcat application but for now I'd 
> settled for getting the values in PHP - it seems Sibboleth/mod_shib 
> aren't passing the attributes as headers to Apache?  No HTTP_SHIB 
> headers are set so I'm really at a loss at how to get the information 
> from the mod_shib session page into an actual application.

These will only show up for a resource for which the Shibboleth SP is
active. Unless you protect some actual resource of yours, such as one
of the aforementioned scripts, the data will not be exported by
default.
Also note that HTTP requets headers are not the default and don't need
to be used in most deployments. Using environment variables (the
default) and forwarding those via AJP (for Java servlet containers)
works just fine (and allows for request.getRemoteUser() on the
Java-side to work, for example).

> This is my configuration:
> 
> <Location /Shibboleth.sso>
> AuthType shibboleth
>   ShibRequireSession On
>   ShibUseHeaders On
>   require valid-user
> </Location>

What in the documentation or distributed configuration did give you
the idea that this was necessary (or indeed made any sense)?
At (or "below") this location the Shibboleth SP recieves SAML protocol
messages (among other things). If the SP didn't actively ignore your
attempt to protect this resource you'd never be able to even login (as
you'd needed an existing session in order to access that location when
trying to establish a session).

So change your Location directive above to match a resource of yours
that should display the recieved attributes and you'll see much the
same data as /Shibboleth.sso/Session shows.

Alternatively you could only supply the minimum of syntactical sugar
that httpd requires for the module to kick in -- without requiring a
session if none exists (i.e., no active protection) -- using "lazy"
sessions:

<Location />
  AuthType shibboleth
  require shibboleth
</Location>

Then you'll see available attributes anywhere in that server (or
virtual host) context, also including any scripts of your own.

Finally, for using Tomcat (without resorting to HTTP request headers)
see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPJavaInstall
After fixing your Location directive (as indicated above) you'll have
done step one of the "Java install" guide and will need to perform the
other 3 steps.
-peter