[Catalog-sig] OpenID login to PyPI
paul at boddie.org.uk
Wed Nov 18 01:26:15 CET 2009
On Tuesday 17 November 2009 06:44:22 Martin v. Löwis wrote:
> The problem I have with this (and also partially with python-openid) is
> that I don't know how to integrate it with the existing application. How
> is the module supposed to know what PyPI accounts are, and how they
> relate to existing IDs, and what postgres database and table this
> information is to be stored in?
Since OpenID is an authentication solution, you should probably just accept
the claimed identity as the username. In fact, mod_auth_openid provides this
as the REMOTE_USER CGI environment variable. If you then want to associate
this information with things like e-mail addresses, you can do this using the
normal dialogues presumably implemented for this purpose - it's not as
optimal as asking the OpenID infrastructure for such information, but it's
nothing the application isn't doing already.
Such integration of authentication details is only awkward if applications
aren't designed to deal with REMOTE_USER or make special assumptions about
the nature of such information. Bugzilla, for instance, would rather you have
an e-mail address as a username, and in the "authentication pass-through"
mode (or whatever it's called) this imposes constraints on the usernames
employed in the actual authentication solution deployed in front of Bugzilla.
> For Roundup, the problem is even more difficult, IIUC, assuming I want
> people to add either an openid or a username/password pair into the
> existing fields: how is mod_auth_openid supposed to know that the name
> is not an openid in the first place, just because a password is also
> provided? The roundup installation uses a reverse proxy, so it would
> be better to create something that doesn't rely on Apache.
I can see that a hybrid solution could be a problem. The worst case might
involve having two separate URLs for the entire application, if Apache
insists on guarding the application with a specific authentication solution,
not setting REMOTE_USER outside that URL hierarchy, and preventing people
getting to a public page within that hierarchy to log in the traditional way.
P.S. Once upon a time I had a brief encounter with an Apache module for the
Sun single sign-on technology SAML (which led to the Liberty Alliance stuff),
and that probably also fed the identity via the standard REMOTE_USER
More information about the Catalog-SIG