Shibboleth Developers

[Peter Williams <>]

So let's work the exercise (and I have no special knowledge of what Eric is 
doing).

A few years ago, I had trustbearer (bought out by VeriSign) run an openid 
gateway. They took in their own Ops and Janrain Ops assertions, and spat out 
saml asserts. Two simple backback channels existed, so an event raised due to 
SAML2.AuthnReq on the intermediary induced an OP request on the openid IDP. 
Obviously, the reverse path was easy to find for the assertions being minted. 
My mental model was one from the VPN world, where every day one takes a route 
in its own address space from a local domain (e.g. an OSPF virtual routing 
table) and injects it into BGP. OPenid was oto BPG, what SAML2 was to OSPF.

Now that worked fine UNTIL openid changed gears - having introspected about 
what made Facebook connect work (while openid adoption foundered). Folks 
started to build UI windows -  hosted by the IDP - that an SP inserts into 
its page flow. This window instruments the same protocol as ever (but its is 
now implied vs an extant contruct at the UI).

Ill GUESS (as I don't know) that this is the design context behind what Eric 
is doing; when using iframe-type "implementation cheats". And, the topic is 
relevant generally to research on the topic of openid/saml "interaction" , 
"integration", or whatever other political term is used to address the 
cooperation.

Ive tried to use the idp-discovery stuff from OASIS. It wasn't viable, if for 
no other reason that I could not find anyone to interwork against!

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Lukas Hämmerle
Sent: Friday, December 17, 2010 4:06 AM
To: 

Subject: Re: [Shib-Dev] New IETF draft for IdP Discovery ("PingPong")

> 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