[okfn-help] Bibliographica ticket #76 OpenID login and API keys

Wed Jun 16 10:20:04 BST 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Floating a kite for addressing most of #76 (adding OpenID login and  
API keys) and showing a functioning candidate solution.

<http://knowledgeforge.net/pdw/trac/ticket/76>

Flickr set of screenshots showing the web interface:
http://www.flickr.com/photos/46197271@N00/sets/72157624286088556/

Summarised requirements:
========================
* A way for users to log in and identify themselves (authentication)
- - Perhaps we do not allow editing without a login - (authorisation).
- - Perhaps even when logged in one can "own" some graphs and others  
cannot edit them - (authorisation).

* OpenID required for using openid username in RDF store (e.g. on  
changesets)

* An API key for write operations (HTTP PUT on /graph)

* A system of owners and permissions on RDF graphs that exist in the  
store (assume RDF store)

* User data (preferences, API keys) to go in user store, (sqlalchemy +  
sqlite)

* Scope for extending this to a mini-auth package (factored out so we  
can reuse):
- - repoze.who: for identification
- - basic Acccount (User) model object create script (repoze.what)
- - based on sqlalchemy - openid + form
- - email confirmation for accounts

* Priority right now is to get this working in bibliographica.

Wearing my package integrator's hat, it occurred to me that there may  
be some time and effort to be saved by re-using or adapting other  
approaches to auth'n'auth, some of which are in the form of (very  
nearly) ready-to-use Pylons controllers ...

My solution is a composite of:

Kai
===
Ben Bangert's authn solution (an "accounts" controller with  
accompanying OpenID consumer) for PylonsHQ:

http://bitbucket.org/bbangert/kai/src/tip/kai/controllers/accounts.py

The code is elegant and clean, and it also provides the email facility  
that is required for user-managed accounts. The identity model in Kai  
is modest and expressed in couchDB but given that we prefer a SQL  
store for user data, NoSQL storage fails a couple of the requirements.

Shabti
======
Some other alternative approaches to auth'n'auth are available and  
I've explored a couple in Shabti, which I'll include here purely to  
illustrate that a lot of the preliminary spadework has already been  
done:

+ the Kai identity model expressed in Elixir (1) and the accounts  
controller (and accompanying OpenID consumer controller) decanted into  
a Shabti template:

http://bitbucket.org/gjhiggins/shabti/src/f4ae951fb588/shabti/templates/authplus/+package+/controllers/accounts.py_tmpl

+ The old tesla-pylons-elixir elixir/SQLA identity model re-expressed  
using Phillip Cooper's "RDFAlchemy" (an RDF ORM for Python) --- this  
should be fairly straightforward to re-express in ORDF:

http://bitbucket.org/gjhiggins/shabti/src/f4ae951fb588/shabti/templates/auth_rdfalchemy/+package+/model/rdfmodel.py_tmpl

Expanding or contracting the range of attributes of the identity model  
is straightforward in any of the approaches and I don't anticipate any  
difficulties in that direction.

(1) TBH, it's all the same model (by design) and a vanilla SQLA  
version of the identity model is defined in one of the other Shabti  
templates. So if an identity model expressed in vanilla SQLA is  
preferable to one expressed in elixir (perhaps a sensible approach as  
it's one less dependency to worry about) then it's pretty much just a  
copy'n'paste job.

[ some time later ... ]

Now that I have my instance of Bibliographica up and running, I  
thought I might as well use it as a testbed and load it up with the  
relevant components taken from the Shabti "authplus" template.

I now have illustrations of the functioning code which I have uploaded  
as screen shots (of the account registration / login process pages) to  
flickr:

http://www.flickr.com/photos/46197271@N00/sets/72157624286088556/

It all adds dependencies (SQLAlchemy, elixir, Babel, pytz, python- 
openid, toscawidgets and tw.forms) but all are pure Python. With some  
work, a few of these additional dependencies could be made to go away  
but this is pretty much exactly the kind of job that they were  
designed to perform. IMHO the more compelling argument might be the  
amount of ground covered.

The only potentially knotty problem is the "system of owners and  
permissions on RDF graphs", the SQL store will need to keep in synch  
with the various comings and goings of user-generated graphs in the  
RDF store.

I wonder if signed graphs have any relevance here?

http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf
http://semedia.deit.univpm.it/submissions/www2005/WWW2005_signignRDF.pdf

- -- Cheers,

Graham

http://www.linkedin.com/in/ghiggins

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAkwYl0UACgkQOsmLt1Nhivz8mACgtyJf6wwVgSFAGR4NhkdN2GLW
vj4AoK2HIUlZSadD2bvIbmRvyMrPnfdgiQCVAgUBTBiXRVnrWVZ7aXD1AQJ5vAQA
tGLMVi1MW+QQtx9PKQo4CkH8HaxZ2eN1V3K7TRa0LjFKhSaK00GGKkPnARp/CVWe
g6N82gfqO3n5y27yPXYk+KK6y7hbwsc+PP5MLDNWJyGHofzGFjh2j1NotVQkG2XM
1VjZ4pj3lH5Sc+Aef3mUPFRHki0ICfr1d+87oOeme/k=
=xCEp
-----END PGP SIGNATURE-----