Seamless site-to-site account creation and login via OpenID
Drummond Reed
drummond.reed at cordance.net
Mon Aug 28 17:55:21 UTC 2006
+1 to Mike's flow here. I believe this eliminates the security issues that
I'm worried would surface with proxied IdPs.
The remaining issue is privacy. Site A reveals the identifier the user used
with Site A to Site B. With OpenID 2.0, the user can have site-specific
identifiers ("directed identity"). The whole idea of directed identity is
that you don't have to reveal the same identifier to different sites, and
yet you still get single sign-on and profile exchange.
The only solution I can see that would retain that benefit is for Site A to
redirect not to Site B, but to a redirect service at the user's IdP, who
then redirects to SiteB AFTER determining if the user wants a site-specific
identifier for Site B.
This way Site A and Site B never have to share identifiers for the user; all
they know is that the user uses a particular IdP.
=Drummond
-----Original Message-----
From: yadis-bounces at lists.danga.com [mailto:yadis-bounces at lists.danga.com]
On Behalf Of Michael Mell
Sent: Sunday, August 27, 2006 7:52 AM
To: Tony
Cc: Yadis list
Subject: Re: Seamless site-to-site account creation and login via OpenID
Hi Tony,
The scenario you describe does make a lot of sense. It's occurred to me
too. But I worry that creating Proxy IdP's will degrade the security
and reliability of the authentication. The IdP is a complex application
with strict compliance requirements. Adding a new process in the IdP or
rolling your own ancillary process could introduce new security holes
(and require a lot of work!).
Here's an example of a much easier flow that achieves your goal today:
User logs in to Site A. Site A presents a link to Site B with User's
identifier in the url arguments. The Site B Landing page recognizes
that an identifier has been passed which indicates the user should be
logged in as that identifier. Site B redirects User to Site B login
which redirects to User's IdP. User has a session at the IdP so no
password is requied. User is routed back to Site B with authentication
tokens. Site B confirms authentication and routes User to Site B
Landing page.
I don't see much to gain from Proxy IdP'ing. If you really want Site A
to be the authentication authority then Site A *is* the IdP and should
run the strongest IdP processes available.
hope that helps,
Mike
On Aug 24, 2006, at 12:36 PM, Tony wrote:
> Yes, that's correct. The idea is to have a partner network of a
> number of sites that all trust each other, and allow any user of any
> site in the partner network to move around the network utilizing
> various services which are tied to an account on that site.
>
> - Tony
>
>
> On 8/24/06, Drummond Reed < drummond.reed at cordance.net> wrote:Tony,
>>
>>
>>
>> So if I understand this (fascinating) scenario, what you're really
>> talking about is the capability for any site A to dynamically begin
>> serving as a "proxy" IdP for a user to another trusted site B, simply
>> by issuing a URL for accessing site B that points back to site A as
>> the OpenID IdP.
>>
>>
>>
>> Do I have that right?
>>
>>
>>
>> If so, that's both really cool, and possibly a little scary,
>> because the user may not expect/want site A to act in that proxy IdP
>> capacity.
>>
>>
>>
>> What do folks think?
>>
>>
>>
>> =Drummond (i-name: =drummond.reed, http://xri.net/=drummond.reed)
>>
>>
>>
>>
>> From: yadis-bounces at lists.danga.com [mailto:
>> yadis-bounces at lists.danga.com] On Behalf Of Tony
>> Sent: Thursday, August 24, 2006 1:21 AM
>> To: yadis at lists.danga.com
>> Subject: Seamless site-to-site account creation and login via OpenID
>>
>>
>>
>>
>> Thus far I've only read about OpenID and tried it out with some scant
>> services. However as far as I can tell, the process of creating an
>> account and logging in to a trusted "partner" site could be made
>> completely automated, correct?
>>
>> Example:
>>
>> User has an account on Web Site A. User logs into Site A and a
>> session cookie is set.
>>
>> User wants to access a service on Site B which is part of Site A's
>> trusted network of partner sites.
>>
>> User requests Site B's feature on Site A. Site A directs the user
>> to Site B, passing their OpenID XRI for Site A to Site B.
>>
>> Site B would then contact Site A based on the OpenID to verify
>> User's identity. Site B would then issue an HTTP redirect for the
>> user to a specially designed landing URL.
>>
>> When User's browser hits the landing URL, Site A checks the session
>> cookie and sets up the trust relationship with Site B.
>>
>> As far as I can tell, this can be 100% seamless and behind the
>> scenes, provided the user has 1) already logged into Site A and 2)
>> Site A and B trust each other enough to use OpenID in this manner.
>>
>> Correct, or am I missing something?
>>
>> Tony Arcieri
>> ClickCaster.com
>
More information about the yadis
mailing list