Login Federation

[John Ehn]

Sounds good.  I'm working on a draft.  Once it's in a readable state, I'll
post it for comments.

Thanks!


On 2/19/08, Brett Carter <brett at rdnzl.net> wrote:
>
>  This is close to what I was thinking, however why not simply pass the
> user's open id url to the external site, through some yet undefined
> parameter.  This way, there's little chance for cache poisoning.  Passing
> the open id url, the consumer site can just proceed with authentication
> normally, using any cached data it has already.  Also, I think IMG tags are
> a better idea than IFRAMES, in another post.  They're more compatible, for
> one.
>
>
> A point I didn't think of at first is that we have the converse issue of
> being able to log out of federated sites as well.
> -Brett
>
>
>
>  On Feb 18, 2008, at 11:58 AM, John Ehn wrote:
>
>  I think I've figured out the flow.  It's seamless from the point of view
> of the user.  It will require explicit support from the Idenity Provider (on
> top of AX), and the client website will need to have an AX update receiver
> that supports this as well.  No special support is needed in the web
> browser.
>
> Turn on auto-logon on each site
>
> 1. Log into the relying party normally
> 2. Site begins OpenID authentication, sends AX request asking for the
> IsLoggedIn variable, and requests updates when the value changes.
> 3. User selects whether or not they want this to occur (automatically
> notify the site upon login)
> 4. From the user's point-of-view, login now occurs automatically at that
> site.
>
> Federated login
>
> 1. User logs in to OpenID Provider
> 2. IsLoggedIn variable is updated with a pseudo-random value
> 3. All sites subscribing to the IsLoggedIn variable are updated using AX.
> 4. OpenID Provider displays a page loaded with hidden iframes pointing
> to the same site URLs used for listening for AX updates. The IsLoggedIn
> variable is included as an argument.
> 5. Each site's iframe performs regular OpenID authentication using
> the identity info already cached by the AX update receiver.
> 6. As browser loads each iframe, it receives a standard login cookie from
> each site.
> 7. User can connect to each site and will be automatically logged in.
>
> Federated logout
>
> 1. User logs out of OpenID Provider
> 2. IsLoggedIn variable is updated with a value of "false"
> 3. All sites subscribing to the IsLoggedIn variable are updated using AX.
> 4. Each receiving site expires the user session.
>
> Does this sound feasible?
>
>
> On 2/18/08, John Ehn <john at extremeswank.com> wrote:
> >
> > This can be pretty easily done by piggy-backing on the Attribute
> > Exchange extension.  Have your OpenID Provider store a "IsLoggedIn"
> > variable.  When the value is updated, the OpenID Provider can update all the
> > websites subscribing to the value.
> >
> > The tricky part is having the web browser be automatically identifiable
> > from all of these supported sites.  My first thought would be:
> >
> > * Store and send out the value in of the IsLoggedIn variable to all the
> > websites
> > * Give the browser multiple session cookies that are visible from each
> > of the websites that the values was sent to, which contains a hash of the
> > value plus the website URL.
> > * When the website sees the cookie, it can take the cookie, generate and
> > compare the hash.  If the hashes match, automatically do an OpenID login
> > * When the user logs out at the OpenID Provider, AX will update all
> > subscribing websites, thereby logging the user out of all sites
> >
> > Although, I believe most web browsers won't let you store cookies that
> > are visible from multiple sites.  Perhaps someone more familiar with these
> > mechanics and chip in?  Maybe somehow detect the web browser's "signature"
> > without involving any functionality in the browser itself?
> >
> > Thanks,
> >
> > John Ehn
> > extremeswank.com
> >
> >  On 2/18/08, Martin Paljak <martin at paljak.pri.ee> wrote:
> > >
> > >
> > > On Feb 18, 2008, at 5:11 PM, McGovern, James F (HTSC, IT) wrote:
> > > > Likewise, I would think that for automatic signon, it would be a
> > > good
> > > > thing if the OpenID provider could tell the relying party how long
> > > to
> > > > leave an otherwise idle session open before timing it out. Not sure
> > > if
> > > > this would require an extension or not.
> > >
> > > expires_in from
> > > http://openid.net/specs/openid-authentication-2_0.html#anchor20
> > > should do exactly this.
> > >
> > > m.
> > > --
> > > Martin Paljak
> > > http://martin.paljak.pri.ee
> > > +3725156495
> > >
> > >
> > > _______________________________________________
> > > specs mailing list
> > > specs at openid.net
> > > http://openid.net/mailman/listinfo/specs
> > >
> >
> >
>
>
> _______________________________________________
> specs mailing list
> specs at openid.net
> http://openid.net/mailman/listinfo/specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20080219/c1b6d896/attachment-0002.htm>