Shibboleth Developers

[Lukas Haemmerle <>]

> What I meant is that providers like ebsco uses a different aproach to
> what you show in your example:
> If you want to log in with shibboleth in Ebsco
> (https://shibboleth.ebscohost.com/ ) you must first select your
> federation. After then ebsco builds a list of IdPs, while reload the
> entire site.
> 
> Would this been able to be accomplish with your solution?

Not right now but in theory yes :) I'm assuming that in most cases the
number of different Home Organizations that should get access is
reasonably small so that you wouldn't have to categorize the IdPs also
into different federations. This would require the user to interact
twice with some UI element and therefore also decrease usability slightly.

On 23.9.2008 Peter Schober wrote:
> My guess is that the top 5 or 10 shib/SAML-enabled publishers in the
> world will roll their own, no matter what.

Absolutely, but that's because they have the resources to do that :)


On 23.9.2008 Franck Borel wrote:
>
> Wouldn't it be nice to make applicable to the rest of the SPs?

Sorry, what do you mean by that? If I add the source code of this
proof-of-concept to our PHP WAYF/DS, it could be used by any SP in any
federation.


> Another questionI have, is concerns security:
>
> Is there any danger of XSS using this method?

Yes, that is mentioned in the document I wrote. If an attacker could
manage to hack and edit the PHP pages of the central WAYF, he could
modify the javascript that then is embedded on remote sites. Using this
it would be possible to do all sorts of bad things. Therefore, it is
important to make sure that the central WAYF is protected carefully.

Rod Widdowson wrote:
> Lukas,
>
> This sounds like fun, but my mind begings to explode with the
> intricacies of which server sets which cookie for collection by which
> javascript stored on what machine on behalf of which entity.

It's pretty simple. The embedded WAYF doesn't set any cookies at all.
The cookies are only set by the central WAYF from where the Javascript
is loaded and therefore these cookies are also only set for this one domain.

When I wrote that the embedded WAYF sets a cookie to remember settings
this was a bit misleading. Actually it's really only the Shibboleth SP
that sets a _saml_domain cookie for the domain the SP is located and the
central WAYF that sets cookies for its domain. And only these cookies
are used by the WAYF in the end.


> To help me I wanted to chase the cookies through the system so I
> could get my mind round this since I haven't yet completely grocked
> how you update the cookie for the central WAYF's store - the one at
> https://wayf-test.switch.ch/, do I gather that this is just a web
> server which you just bounce through and which sets the cookie on its
> way (with no policing of the parameters?)

In order to see what is going on cookie wise etc, I would recommend
using the Live HTTP Header extension for Firefox:
https://addons.mozilla.org/en-US/firefox/addon/3829

The cookies on the central WAYF are updated by the central WAYF
directly. The embedded WAYF basically makes your browser post the form
directly to same place that you would post the form to if you were using
the central wayf directly.
When using an IdP from another federation, the behaviour is different
because then you won't come accross the central wayf at all (because it
wouldn't know anything about IdPs of other federerations). Instead the
embedded wayf sends you directly to the SP's (which in most cases will
be on the same host) SessionInitiator handler, e.g.
/Shibboleth.sso/Login?entity=#selected entityID#


> But I am having problems - does this work with IE?  I have a pretty
> standard install but when I compare it side by side with firefox and
> I'm missing about 50% of the display (I get the pull down list, but
> not the "remember selection" selection nor the "login" button).

Yes, I extended the original code a bit without testing it again on IE.
After testing it again and fixing a small bug, it should now being
displayed also on our beloved standard-compliant internet browser again
:) There is no rocket science and no fancy Javascript constructs needed.

Lukas


-- 
SWITCH
Serving Swiss Universities
--------------------------
Lukas Haemmerle, Software Engineer, Security
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 64, fax +41 44 268 15 68
,
 http://www.switch.ch