OpenID Provider Supporrt

[GoogleCodeExporter]

At the simplest, the enhancement here is that other webapps can use
Nectarine as a provider for OpenID.

'''Reason for enhancement:'''
 - Enables the ability for a compo-related voting application that is only
open to demovibes members without requiring them to create a new account.

'''Side benefits:'''
 - Users of demovibes installations can use their demovibes account as a
login point for other websites.

'''Information:'''
http://openid.net/specs/openid-authentication-2_0.html#requesting_authentication

'''Basics:'''
demovibes will receive a URL as described in the OpenID documentation. The
presence of valid non-optional OpenID attributes will indicate an OpenID
request is in process. If the asked-for user is logged in, the user will be
redirected to the return-to location. If asked-for user is not logged in,
the user will log in first and be redirected to the return-to location.
Proper OpenID information will be appended to the return-to location before
redirection.

'''Technical Details:'''
demovibes OpenID URL would be something similar to:

 http://www.example.com/demovibes/

This page would also then have to contain the following inside the head tag
of the page:

 <link rel="openid2.provider" href="http://www.example.com/accounts/login" />

The href is the location of the OpenID enabled login page of the demovibes
installation, and --even though indicated otherwise above-- does not have
to be the same as the standard demovibes login page. If the login URL
specified by that link receives an OpenID request with a mode of
"checkid_immediate", it must not show a login page if the user is not
logged in and instead back the authentication failed (as part of the
redirect). If a mode of "checkid_setup" is received, a login page may be
shown if the user is not logged in.

So given all this, an OpenID request sent to the URL indicated above would
look similar to this:

 http://www.example.com/accounts/login?openid.ns=http://specs.openid.net/auth/2.0&openid.mode=checkid_setup&openid.claimed_id=http://www.example.com/demovibes&openid.identity=http://www.example.com/demovibes&openid.return_to=http://www.example2.com/welcome&openid.realm=http://www.example2.com/*

The claimed_id/identity are just possible indicators of the username a
person is trying to log in as, for demovibes we'll save ourselves some work
because the claimed_id is just the website URL and can be ignored. It would
be possible to use something like
http://www.example.com/demovibes/user/Username as the entry point for
OpenID, but then the discovery link (shown above) needs to be output on
each profile page (easy) and demovibes has to ensure that when login for
http://www.example.com/demovibes/user/Username only Username can log in.
Which means the username must be restricted, not just anyone on demovibes
can log in via that URL (which is harder). In our return responses, the
openid.identity should be replaced with the actual id of the user, which
can then be a URL to their profile page if we wish.

The return_to is the location the initiator website wishes the user to be
redirected to on successful completion of logging in.

The URL being redirected to must have the following parameters:

 openid.ns=http://specs.openid.net/auth/2.0
 openid.mode=id_res
 openid.op_endpoint=http://www.example.com/demovibes (the URL used above to
initiate all this)
 openid.claimed_id=http://www.example.com/demovibes/user/Username
 openid.identity=http://www.example.com/demovibes/user/Username
 openid.return_to=http://www.example2.com/welcome (verbatim; as provided by
the initiator)
 openid.response_nonce=YYYY-MM-DDTHH:MM:SSZUNIQUEVALUE (replace with the
current date and time in UTC timezone, UNIQUEVALUE is for anything we want;
total must be less than 255 ASCII characters)
 openid.invalidate_handle={handle} (optionally given to us by the initiator
via openid.handle, this signifies they shouldn't use it anymore (a good
idea for security))

 openid.assoc_handle={stuff} (it's not optional, but we aren't handling
associations ... so make it the same as the nonce? unique, that is?)
 openid.signed=op_endpoint,identity,claimed_id,return_to,assoc_handle,response_nonce (comma separated list of openid.fields that we include in the signature, sans the "openid." prefix)

 openid.sig={signature} (the signature is the result of a sha1 or sha256 of
the list of fields indicated above (and in that order) like this:
op_endpoint:endpointvalue\nidentity:idtyvalue\n...lastkey:lstkeyv )

It may also be possible that *despite* all this, the initiator may make
another request with openid.mode of "check_authentication", in which case
we need to respond to the request with following parameters:

 openid.ns=http://specs.openid.net/auth/2.0
 openid.is_valid=true|false (depending on whether login was a success or not)
 openid.invalidate_handle={handle} (optionally given to us by the initiator
via openid.handle, this signifies they shouldn't use it anymore (a good
idea for security))

If anyone actually made it this far, it was quite an effort to actually
work this all out. I think specifications were written to be complex
because if people could actually understand them, then someone might
actually implement it right, and everyone else would no longer have the
right to bitch and moan about nobody supporting the spec. Besides that
though, I worked it out in as much detail as I thought I'd need to later
implement the authentication part of the spec for demovibes, without having
to dig through it all again.

Original issue reported on code.google.com by mcbain....@gmail.com on 22 Feb 2010 at 12:34

[GoogleCodeExporter]

Typos, under "Technical Details" section:
 and instead sendback*

Clarification, "Technical Details" section:
the "authentication failed" response referred to follows the same procedures as 
a
successful one but only uses the following 2 attributes:

 openid.ns=http://specs.openid.net/auth/2.0
 openid.mode=cancel

Original comment by mcbain....@gmail.com on 22 Feb 2010 at 12:58

[GoogleCodeExporter]

More clarifications:

All URLs passed around should have proper URL encoding, so the really long URL 
would
really be the following, for example:

 http://www.example.com/accounts/login?openid.ns=http%3a%2f%2fspecs.openid.net%2fauth%2f2.0&openid.mode=checkid_setup&openid.claimed_id=http%3a%2f%2fwww.example.com%2fdemovibes&openid.identity=http%3a%2f%2fwww.example.com%2fdemovibes&openid.return_to=http%3a%2f%2fwww.example2.com%2fwelcome&openid.realm=http%3a%2f%2fwww.example2.com%2f*

For our purposes, the only URL we have to worry about encoding is the final 
return-to
URL we give the browser via 307/redirect.

Original comment by mcbain....@gmail.com on 22 Feb 2010 at 1:04

[GoogleCodeExporter]

Original comment by mcbain....@gmail.com on 22 Feb 2010 at 2:17

• Added labels: Usability

[GoogleCodeExporter]

There is some code at http://github.com/simonw/django-openid - maybe we can use 
some of 
that

Original comment by TheTerra...@gmail.com on 22 Feb 2010 at 6:58

[GoogleCodeExporter]

And just because I stumbled over it:
http://blogs.gnome.org/jamesh/2009/04/14/django-openid-auth/

A supposedly very simple to add django openid client part.

Original comment by TheTerra...@gmail.com on 22 Feb 2010 at 6:59

[GoogleCodeExporter]

I think both of those are for making a "relyer", which would enable demovibes to
consume OpenIDs (that is, people could create accounts with an OpenID) but 
unless I
missed something, they don't allow demovibes/django to be a *provider* (allow 
it to
be an OpenID source for other OpenID consumers).

Original comment by mcbain....@gmail.com on 23 Feb 2010 at 7:53

[GoogleCodeExporter]

http://www.djangosnippets.org/snippets/310/

http://www.romke.net/django/openid_provider/ - this one actually looks usable

Original comment by TheTerra...@gmail.com on 23 Feb 2010 at 8:58

[GoogleCodeExporter]

As far as they go, the second one looks promising. The snippet you linked to is 
quite
old, and the project it claims would eventually have OpenID support seems to be
abandoned. So I guess we just have to check out the romke project and see if it 
does
what we need. If not ... then I guess I have to learn django and python 
(learning
python will be the easy part :)

Original comment by mcbain....@gmail.com on 23 Feb 2010 at 9:17

[GoogleCodeExporter]

Already implented it, testing it to find the kinks and see if it actually works

Original comment by TheTerra...@gmail.com on 23 Feb 2010 at 10:58

[GoogleCodeExporter]

(lightly) tested and committed.

Original comment by TheTerra...@gmail.com on 23 Feb 2010 at 12:00

• Changed state: Fixed

[GoogleCodeExporter]

hehe. awesome. I'm going to CC FishGuy8765 because if/when he gets this pushed 
to
CVGM, I can test it with a simple local webapp.

Original comment by mcbain....@gmail.com on 23 Feb 2010 at 12:15

[GoogleCodeExporter]

http://demovibes.thelazy.net/demovibes/ have it running already :)

Original comment by TheTerra...@gmail.com on 23 Feb 2010 at 12:38

[GoogleCodeExporter]

Okay, I was able to log into StackOverflow with the OpenID listed in my user 
profile.
There is one issue though, somewhat annoying. When an OpenID request is 
received by
demovibes and the user is not logged in, they're presented a login form (which 
is
fine), however, after they log in, the OpenID request is forgotten entirely and 
they
remain on the demovibes site.

I also tested it with my web framework of choice, and it didn't work. I think 
their
framework's OpenID class can't find the URI, due to some sort of XPath parser 
issue.
Anyway, that's not our problem.

I'd call this done :)

Original comment by mcbain....@gmail.com on 23 Feb 2010 at 1:18

[GoogleCodeExporter]

CVGM will hold off on applying this patch for a while until I can scrape some 
time 
together to sit and play with it properly, and work on any changes needed etc.

Original comment by FishGuy8765@gmail.com on 23 Feb 2010 at 1:49