Shibboleth Developers

[Lukas Hämmerle <>]

> From a quick glance...
> 
>   "directing the browser to perform these queries to, potentially, all
>    possible IdPs for a given SP"
> 
> For some reason the date on that draft is not April, 1st.
> I guess that's just an oversight on the author's part?

It's not explicitly written and therefore would need some clarification
but I would assume that by "all possible IdPs for a given
SP" they mean all IdPs from which the SP would accept assertions from.

Sure, if an SP for example is accessible by the thousands of IdPs in the
UK Access federation, this still is a lot of queries. But the way I
understand this draft is that this protocol is used only the first time
a user accesses a service with a given web browser. After the first
time, it's already known (for example because the SP sets the saml
domain cookie) which IdP the user chose to authenticate.

Also, I would guess that most SPs have users only from a hand-ful of
Identity Providers. However, then one of course can argue that the IdP
Discovery problem is not so difficult to solve in this case because
users can easily select their institution from a list of only a handful
of organizations.

On the other hand: This protocol would be most useful for SPs with users
from a few hundred or thousand different institutuions and in this
scenario unfortunately the scalability problems start to become an issue.


>   "Each Pong response is recorded server side at the SP and indexed
>    using the user's browser session."
> 
> Meaning the SP needs to establish a session before authenticating the
> user, i.e. no relying on Shib's session and no protecting static
> content?

Yes, the way I understand it the session they are referring to has
nothing to do with the Shibboleth session. No big deal. Many web sites
already create a session even before a user is authenticated.

But you are making a valid point here:
There is the problem that it is unknown from the beginning at how many
IdPs a user already has authenticated with in the past. But the protocol
would stop querying after a first positive response from the first of
multiple IdPs where the user has authenticated. Therefore, it might be
necessary to query all IdPs anyway. And this is the case even for
non-shared browsers.


> "Prioritization" is fun as well:
> 
>   "SP SHOULD establish a prioritization mechanism to increase the
>    possibility that the user's IdP is found early in the PingPong IdP
>    Discovery Process"
> 
> And since these cookies are meant to have an expiration date in the
> far future (i.e., are not session cookies), how will this work on
> shared computers (where closing the browser does not destroy these
> cookies with the browsers accumulating IdP "Pong" resonses for every
> IdP someone sucessfully authenticated, at one point?)

I would hope that shared lab computers also reset long term cookies on
logout and not just the session cookies :-)


> > It proposes a profile for figuring out a user's Identity Provider
> > based on Javascript, IFRAMES and cookies.
> Which would mean it's useless without third party cookies, right?

No third party cookies are required. Only cookies at the IdP and at the
SP for which a user has set cookies anyway.


Reading the draft through again some further questions popped up:

>  Ping request  The request sent from the IdP to the SP to query
>          whether or not a user in the given browser context has
>          authenticated at that IdP previously.

Maybe the heaps of snow falling down right now in Zurich are affecting
my gray cells but this is probably not what they intended to write :-)
After all it's the user's browser that has to send these requests due to
the cookies. And if I got this right, it would be the SP that sends the
request to the IdP via the browser.


>    Pong response  The response returned from the IdP to the SP
>          indicating whether or not the IdP has previously authenticated
>          a user in the given browser context.

I think I understand this but maybe it would help the understanding if
it said "from the IdP via the browser to the SP".


Lukas


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