Trouble getting attributes from Sibboleth into PHP/Tomcat

[Keith Osborne]

Peter,

Thanks - this is electronic gold and great spot on the typo but those 
42,000 merely flatlined, doctors all over the world reached for the 
crash cart and we only lost 4 in the end :)

  I didn't realise an actual resource needed to be protected, I thought 
I could pick the variables up after a successful iDP login.

Adding in the "Location /" apache stuff has worked and I can finally see 
the variables within my application (as headers - but will switch to AJP 
shortly)

The reason why I used <Location /Shibboleth.sso> was because I was 
debugging and everything else is set to be proxied with Jkmount to 
Tomcat but everybody seems to use that reference URL.

Thanks for your help once again.

Keith


On 26/05/2013 17:02, Peter Schober wrote:
> * 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
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net