[Catalog-sig] OpenID login to PyPI

Paul Boddie 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 
variable, too.

More information about the Catalog-SIG mailing list