My initial thoughts/questions
7 views
Skip to first unread message
George Fletcher
May 16, 2010, 8:04:37 PM5/16/10
to pingpong-id...@googlegroups.com
1. I know "we" are running
into some issues with 3rd party cookies and
iframes. This may apply more to writing cookies than reading them... I
need to do a little more research. This of course applies to the
iframes loading the IdP PingHandler.
2. I'm a little worried about performance for long distance treks. Browsers only support a small number of simultaneous sockets (by default) and so even if 5 or 6 iframes were returned in the html/js, it's likely that only two IdP PingHandler requests will be happening simultaneously.
3. The SP still has to pick a set of IdPs to check (note that this is similar to the work that Andrew Arnott has done with OpenID but more generalized). So while this is better than NASCAR for many users, the number of IdPs checked is still going to be limited. Mostly likely by how many can be checked in a "reasonable" period of time.
4. As an SP/RP, I still have to have a fallback UI that either allows the user to type something in or pick from a list. Personally, I allow very few persistent cookies so an IdP persistent cookie won't work for people like me (I admit that this is so small and edge case as to not worry about:)
5. On the security side, many consumer services write the session authentication cookie/token on their root domain and don't necessarily make it secure. Hence the concern about session hijacking is real. However, if someone wants to steal their cookie, it probably doesn't require the SP to do it. The user is likely using the service that is their IdP and so the session auth token is exposed via that core service regardless of what the SP does. I do wish that this was a bigger security issue in the consumer space.
6. I'm a little worried about the session state required at the SP to manage all the information coming in via the PongHandlers and PongStatus. It seems like this makes the SP statefull, unless the expectation is that session state is maintained in some form of a cookie. As a point of reference, we have many machines, geo-distributed, that form our web IdP.
Thanks,
George
2. I'm a little worried about performance for long distance treks. Browsers only support a small number of simultaneous sockets (by default) and so even if 5 or 6 iframes were returned in the html/js, it's likely that only two IdP PingHandler requests will be happening simultaneously.
3. The SP still has to pick a set of IdPs to check (note that this is similar to the work that Andrew Arnott has done with OpenID but more generalized). So while this is better than NASCAR for many users, the number of IdPs checked is still going to be limited. Mostly likely by how many can be checked in a "reasonable" period of time.
4. As an SP/RP, I still have to have a fallback UI that either allows the user to type something in or pick from a list. Personally, I allow very few persistent cookies so an IdP persistent cookie won't work for people like me (I admit that this is so small and edge case as to not worry about:)
5. On the security side, many consumer services write the session authentication cookie/token on their root domain and don't necessarily make it secure. Hence the concern about session hijacking is real. However, if someone wants to steal their cookie, it probably doesn't require the SP to do it. The user is likely using the service that is their IdP and so the session auth token is exposed via that core service regardless of what the SP does. I do wish that this was a bigger security issue in the consumer space.
6. I'm a little worried about the session state required at the SP to manage all the information coming in via the PongHandlers and PongStatus. It seems like this makes the SP statefull, unless the expectation is that session state is maintained in some form of a cookie. As a point of reference, we have many machines, geo-distributed, that form our web IdP.
Thanks,
George
Chuck Mortimore
May 16, 2010, 8:19:42 PM5/16/10
to pingpong-id...@googlegroups.com
On Sun, May 16, 2010 at 5:04 PM, George Fletcher <gffl...@aol.com> wrote:
This is a legitimate concern - spec should definitely describe the P3P headers required to make this work.
1. I know "we" are running into some issues with 3rd party cookies and iframes. This may apply more to writing cookies than reading them... I need to do a little more research. This of course applies to the iframes loading the IdP PingHandler.'
This is a legitimate concern - spec should definitely describe the P3P headers required to make this work.
2. I'm a little worried about performance for long distance treks. Browsers only support a small number of simultaneous sockets (by default) and so even if 5 or 6 iframes were returned in the html/js, it's likely that only two IdP PingHandler requests will be happening simultaneously.
I think in most modern browsers the socket limitations are per-domain.
3. The SP still has to pick a set of IdPs to check (note that this is similar to the work that Andrew Arnott has done with OpenID but more generalized). So while this is better than NASCAR for many users, the number of IdPs checked is still going to be limited. Mostly likely by how many can be checked in a "reasonable" period of time.
4. As an SP/RP, I still have to have a fallback UI that either allows the user to type something in or pick from a list. Personally, I allow very few persistent cookies so an IdP persistent cookie won't work for people like me (I admit that this is so small and edge case as to not worry about:)
5. On the security side, many consumer services write the session authentication cookie/token on their root domain and don't necessarily make it secure. Hence the concern about session hijacking is real. However, if someone wants to steal their cookie, it probably doesn't require the SP to do it. The user is likely using the service that is their IdP and so the session auth token is exposed via that core service regardless of what the SP does. I do wish that this was a bigger security issue in the consumer space.
I'm not sure I follow the concern about session hi-jacking. iFrames are inherently sandboxed from their parent page if they're not in the same domain. There isn't a practical means for the parent page to dip into the child frames and extract any session, is there?
From a security perspective, I do think this makes it quite easy for a phishing site to "test" what site to impersonate for phishing. I'm also worried about the amount of information leakage this causes. Assume this gets deployed for large consumer IDPs....they'd be able to correlate and track users across the SPs, regardless if they were involved in the subsequent authentication. This might work well for closed circles where that isn't as much of an issue.
-cmort
George Fletcher
May 16, 2010, 8:35:23 PM5/16/10
to pingpong-id...@googlegroups.com, Chuck Mortimore
For number 5 I was referring
to the text in the last paragraph of the document. I agree it's not
really viable for a parent page to steal/hijack data from the iframe
(otherwise Facebook's iframe widgets would really leak privacy data).
However, this method does cause a lot of IDP's to be queried which
means their session cookies are exposed over HTTP so on an open network
this might be an issue.
I do agree with your concern that IdP's the user might never use could track the user's behavior (at least by IP and referrer).
Thanks,
George
I do agree with your concern that IdP's the user might never use could track the user's behavior (at least by IP and referrer).
Thanks,
George
Chuck Mortimore
May 16, 2010, 8:42:21 PM5/16/10
to George Fletcher, pingpong-id...@googlegroups.com
On Sun, May 16, 2010 at 5:35 PM, George Fletcher <gffl...@aol.com> wrote:
For number 5 I was referring to the text in the last paragraph of the document. I agree it's not really viable for a parent page to steal/hijack data from the iframe (otherwise Facebook's iframe widgets would really leak privacy data). However, this method does cause a lot of IDP's to be queried which means their session cookies are exposed over HTTP so on an open network this might be an issue.
Thanks - that makes more sense. ( not the part about the IDPs setting their cookies in clear text :-) )
I do agree with your concern that IdP's the user might never use could track the user's behavior (at least by IP and referrer).
I think it's worse than that. Since each IDP is ping'd and needs to 302 a reply back to the SP, every IDP would be informed of the SP I was attempting to visit, wouldn't they? It looks like the callback URL to the SP is actually passed as a query parameter. Hence, all IDPs can follow me around all participating SPs.
-cmort
George Fletcher
May 16, 2010, 8:47:07 PM5/16/10
to Chuck Mortimore, pingpong-id...@googlegroups.com
On 5/16/10 8:42 PM, Chuck Mortimore wrote:
On Sun, May 16, 2010 at 5:35 PM, George Fletcher <gffl...@aol.com> wrote:
For number 5 I was referring to the text in the last paragraph of the document. I agree it's not really viable for a parent page to steal/hijack data from the iframe (otherwise Facebook's iframe widgets would really leak privacy data). However, this method does cause a lot of IDP's to be queried which means their session cookies are exposed over HTTP so on an open network this might be an issue.
Thanks - that makes more sense. ( not the part about the IDPs setting their cookies in clear text :-) )
I do agree with your concern that IdP's the user might never use could track the user's behavior (at least by IP and referrer).
I think it's worse than that. Since each IDP is ping'd and needs to 302 a reply back to the SP, every IDP would be informed of the SP I was attempting to visit, wouldn't they? It looks like the callback URL to the SP is actually passed as a query parameter. Hence, all IDPs can follow me around all participating SPs.
So any IDP that you use would be able to track you across all SPs. But
for the IDPs you don't use, they could also track the IP and referrer.
It depends on the user's relationship (or not) with the different IDPs
being "Ping'd".
Eric Fazendin
May 16, 2010, 10:16:50 PM5/16/10
to PingPong IdP Discovery
Thanks for the discussion. I'll address the user profiling question /
intended use case first:
We were thinking of the TV Everywhere use case when designing
PingPong. In that use case there are a closed circuit of
participating IdPs and SPs. Most of the IdPs and SPs have a legally
binding relationship already in place. For those IdPs that do not
have a legally binding relationship with a particular SP, they
wouldn't be included in that SP's PingPong IdP Discovery.
In this use case, I think the main questions are:
1. Is the nature of the relationships between the SPs and IdPs ones
that would force everyone to play nicely?
2. If not, what are the risks of the IdPs building a profile of a
user?
3. Are these risks mitigated by the use of the cookie that records the
IdP that a user successfully SSO'ed from? This limits the number of
times the "other" IdPs see a user's attempt to a particular SP to just
once. I understand users could clear their cookies, leading to the
"other" IdPs being Pinged again, but the clearing of cookies would
also likely lead to clearing any tracking cookie the IdP had.
On May 16, 6:47 pm, George Fletcher <gffle...@aol.com> wrote:
> On 5/16/10 8:42 PM, Chuck Mortimore wrote:
>
>
>
>
>
> > On Sun, May 16, 2010 at 5:35 PM, George Fletcher <gffle...@aol.com
> > <mailto:gffle...@aol.com>> wrote:
>
> > For number 5 I was referring to the text in the last paragraph of
> > the document. I agree it's not really viable for a parent page to
> > steal/hijack data from the iframe (otherwise Facebook's iframe
> > widgets would really leak privacy data). However, this method does
> > cause a lot of IDP's to be queried which means their session
> > cookies are exposed over HTTP so on an open network this might be
> > an issue.
>
> > Thanks - that makes more sense. ( not the part about the IDPs setting
> > their cookies in clear text :-) )
>
Session cookies that can be sent over HTTP is a concern for more
reasons than I think PingPong highlights.
> > I do agree with your concern that IdP's the user might never use
> > could track the user's behavior (at least by IP and referrer).
>
> > I think it's worse than that. Since each IDP is ping'd and needs to
> > 302 a reply back to the SP, every IDP would be informed of the SP I
> > was attempting to visit, wouldn't they? It looks like the callback
> > URL to the SP is actually passed as a query parameter. Hence, all
> > IDPs can follow me around all participating SPs.
>
> So any IDP that you use would be able to track you across all SPs. But
> for the IDPs you don't use, they could also track the IP and referrer.
> It depends on the user's relationship (or not) with the different IDPs
> being "Ping'd".
>
>
>
>
>
> > -cmort
>
> > Thanks,
> > George
>
> > On 5/16/10 8:19 PM, Chuck Mortimore wrote:
>
> >> On Sun, May 16, 2010 at 5:04 PM, George Fletcher
cookies in an iframe. Surprisingly, the other browsers we tested were
happy to do it without a privacy policy. We have not looked at
writing cookies in an iframe as it's not needed in PingPong, but given
your points about profiling , it is something we'll look at further,
specifically blocking the ability.
> >> 2. I'm a little worried about performance for long distance
> >> treks. Browsers only support a small number of simultaneous
> >> sockets (by default) and so even if 5 or 6 iframes were
> >> returned in the html/js, it's likely that only two IdP
> >> PingHandler requests will be happening simultaneously.
>
> >> I think in most modern browsers the socket limitations are
> >> per-domain.
>
We've done some very non-scientific testing of loading a number of
iframes in a browser to well known websites. For example, we tested
with 10 iframes to what we consider to be very intensive sites. In
general, the the initial response from all 10 were in a reasonable
amount of time.
> >> 3. The SP still has to pick a set of IdPs to check (note that
> >> this is similar to the work that Andrew Arnott has done with
> >> OpenID but more generalized). So while this is better than
> >> NASCAR for many users, the number of IdPs checked is still
> >> going to be limited. Mostly likely by how many can be checked
> >> in a "reasonable" period of time.
>
Right, the SP would need to decide which IdPs they want users to
potentially SSO from. This list is already identified if the SP's SSO
protocol is SAML. Regarding '"reasonable" period of time', an IdP
prioritization algorithm and a paging mechanism helps.
> >> 4. As an SP/RP, I still have to have a fallback UI that
> >> either allows the user to type something in or pick from a
> >> list. Personally, I allow very few persistent cookies so an
> >> IdP persistent cookie won't work for people like me (I admit
> >> that this is so small and edge case as to not worry about:)
>
Yes, the IdP's persistent loggedInHere cookie is critical for this
protocol to be useful.
The design we've worked on does maintain state at the SP application.
I would think this could be pushed to the browser pretty easily
though.
> >> Thanks,
> >> George
intended use case first:
We were thinking of the TV Everywhere use case when designing
PingPong. In that use case there are a closed circuit of
participating IdPs and SPs. Most of the IdPs and SPs have a legally
binding relationship already in place. For those IdPs that do not
have a legally binding relationship with a particular SP, they
wouldn't be included in that SP's PingPong IdP Discovery.
In this use case, I think the main questions are:
1. Is the nature of the relationships between the SPs and IdPs ones
that would force everyone to play nicely?
2. If not, what are the risks of the IdPs building a profile of a
user?
3. Are these risks mitigated by the use of the cookie that records the
IdP that a user successfully SSO'ed from? This limits the number of
times the "other" IdPs see a user's attempt to a particular SP to just
once. I understand users could clear their cookies, leading to the
"other" IdPs being Pinged again, but the clearing of cookies would
also likely lead to clearing any tracking cookie the IdP had.
On May 16, 6:47 pm, George Fletcher <gffle...@aol.com> wrote:
> On 5/16/10 8:42 PM, Chuck Mortimore wrote:
>
>
>
>
>
> > On Sun, May 16, 2010 at 5:35 PM, George Fletcher <gffle...@aol.com
> > <mailto:gffle...@aol.com>> wrote:
>
> > For number 5 I was referring to the text in the last paragraph of
> > the document. I agree it's not really viable for a parent page to
> > steal/hijack data from the iframe (otherwise Facebook's iframe
> > widgets would really leak privacy data). However, this method does
> > cause a lot of IDP's to be queried which means their session
> > cookies are exposed over HTTP so on an open network this might be
> > an issue.
>
> > Thanks - that makes more sense. ( not the part about the IDPs setting
> > their cookies in clear text :-) )
>
reasons than I think PingPong highlights.
> > I do agree with your concern that IdP's the user might never use
> > could track the user's behavior (at least by IP and referrer).
>
> > I think it's worse than that. Since each IDP is ping'd and needs to
> > 302 a reply back to the SP, every IDP would be informed of the SP I
> > was attempting to visit, wouldn't they? It looks like the callback
> > URL to the SP is actually passed as a query parameter. Hence, all
> > IDPs can follow me around all participating SPs.
>
> So any IDP that you use would be able to track you across all SPs. But
> for the IDPs you don't use, they could also track the IP and referrer.
> It depends on the user's relationship (or not) with the different IDPs
> being "Ping'd".
>
>
>
>
>
> > -cmort
>
> > Thanks,
> > George
>
> > On 5/16/10 8:19 PM, Chuck Mortimore wrote:
>
> >> On Sun, May 16, 2010 at 5:04 PM, George Fletcher
> >> <gffle...@aol.com <mailto:gffle...@aol.com>> wrote:
>
> >> 1. I know "we" are running into some issues with 3rd party
> >> cookies and iframes. This may apply more to writing cookies
> >> than reading them... I need to do a little more research.
> >> This of course applies to the iframes loading the IdP
> >> PingHandler.'
>
> >> This is a legitimate concern - spec should definitely describe
> >> the P3P headers required to make this work.
>
Yes, in our testing we found IE8 is pretty finicky about sending
>
> >> 1. I know "we" are running into some issues with 3rd party
> >> cookies and iframes. This may apply more to writing cookies
> >> than reading them... I need to do a little more research.
> >> This of course applies to the iframes loading the IdP
> >> PingHandler.'
>
> >> This is a legitimate concern - spec should definitely describe
> >> the P3P headers required to make this work.
>
cookies in an iframe. Surprisingly, the other browsers we tested were
happy to do it without a privacy policy. We have not looked at
writing cookies in an iframe as it's not needed in PingPong, but given
your points about profiling , it is something we'll look at further,
specifically blocking the ability.
> >> 2. I'm a little worried about performance for long distance
> >> treks. Browsers only support a small number of simultaneous
> >> sockets (by default) and so even if 5 or 6 iframes were
> >> returned in the html/js, it's likely that only two IdP
> >> PingHandler requests will be happening simultaneously.
>
> >> I think in most modern browsers the socket limitations are
> >> per-domain.
>
iframes in a browser to well known websites. For example, we tested
with 10 iframes to what we consider to be very intensive sites. In
general, the the initial response from all 10 were in a reasonable
amount of time.
> >> 3. The SP still has to pick a set of IdPs to check (note that
> >> this is similar to the work that Andrew Arnott has done with
> >> OpenID but more generalized). So while this is better than
> >> NASCAR for many users, the number of IdPs checked is still
> >> going to be limited. Mostly likely by how many can be checked
> >> in a "reasonable" period of time.
>
potentially SSO from. This list is already identified if the SP's SSO
protocol is SAML. Regarding '"reasonable" period of time', an IdP
prioritization algorithm and a paging mechanism helps.
> >> 4. As an SP/RP, I still have to have a fallback UI that
> >> either allows the user to type something in or pick from a
> >> list. Personally, I allow very few persistent cookies so an
> >> IdP persistent cookie won't work for people like me (I admit
> >> that this is so small and edge case as to not worry about:)
>
protocol to be useful.
I would think this could be pushed to the browser pretty easily
though.
> >> Thanks,
> >> George
Eric Fazendin
May 16, 2010, 10:37:12 PM5/16/10
to PingPong IdP Discovery
And I guess the 4th question to ask as it relates to TVE:
4. Do the profiling risks outweigh the risks and usability issues of
the current IdP discovery solutions?
4. Do the profiling risks outweigh the risks and usability issues of
the current IdP discovery solutions?
Reply all
Reply to author
Forward
0 new messages