[Systers-dev] Considering LDAP and OpenID

[Sarah Mei]

On Wed, May 27, 2009 at 5:33 PM, Jennifer Redman <jenred at gmail.com> wrote:
>> Is the goal to allow single sign-on to several Systers-related sites,
>> for Systers members, without making them register for each site?
>
> Yes, but using Mailman member information (uid and password) as the starting
> point.

Oh, ok - so the plan is to extract and encrypt the Mailman data,
import it into an application that can be an OpenID provider, and use
that as the basis for single sign-on?

One caution, Mailman stores passwords in plaintext, and emails them to
you once a month. Unless as part of this process they're encrypted
(and the monthly emails turned off, and mailman patched to use
OpenID[1]), it's not a great base for a single sign-on system.

>> And/or, do you want to allow Systers to use the Systers OpenID
>> provider for other services that take OpenID? I'm thinking of
>> non-Systers-affiliated sites like Stack Overflow.
>
> This is a question we are working on answering.  What do you think?

Given that we're talking about my Mailman password here, I don't think
I'd use it. Plus, it's sort of a separate project - maybe for the
summer, we can focus on getting some good infrastructure set up for
single sign-on, then take it from there. It would make for a more
achievable project. :)

> OpenLDAP would be used primarily for authenticating against specific
> applications for Systers running on Systers' infrastructure.   For example,
> we set up Mediawiki for Systers to use and then use OpenLDAP as our
> authentication tool.  (Could also be any of the major CMS's.)

OpenID could work this way too. When you install an OpenID provider,
you can restrict which sites it will authenticate - just blacklist
all, whitelist the existing Systers sites, and edit as needed.

BTW, setting up an OpenID provider is pretty lightweight. For
instance, the OpenID extension for mediawiki allows you accept OpenID
logins for mediawiki, and also allows user pages to be OpenID URLs
(i.e., it can be a provider, too). The plugin for wordpress works
similarly.

> One of the questions is would Systers be interested in having a "Systers"
> OpenID that they could use to authenticate against other non-Systers sites,
> and if so what are the implications of running an OpenID Identity Provider
> (security and system overhead).

I think we can put this off until OpenID is running internally
(meaning not within ABI, but for Systers logging into other pieces of
Systers infrastructure). Then we can evaluate the system
administration and overhead costs and see if it's worthwhile to
extend.

> Do you know if there is way to restrict people accessing Systers
> infrastructure with their non-Systers OpenID?  Maybe configuring the
> application or framework to accept only Systers as the OpenID Identity
> Provider?

Yep, this is a basic config setting in both OpenID providers, and
OpenID acceptors. Providers can blacklist/whitelist sites, usually by
URL (the exact method varies depending on the provider). So a provider
can say "I only authenticate for sites ending in systers.org."
Acceptors can say "I only take Systers OpenID." In that way we have a
closed system that won't accept outside OpenIDs, won't authenticate
against external sites, but leaves us the option to open the latter if
we want to, once we know the system administration and resource
overhead of internal-only use.

Sarah

[1] Mailman with OpenID support:
http://www.openidenabled.com/unsupported-software/
You'd definitely want to audit this code and see how up-to-date it is.