[Systers-dev] Considering LDAP and OpenID
Malveeka Tewari
malveeka at gmail.com
Thu May 28 12:07:22 PDT 2009
Hi Sarah
I am the student who'll be working on this project - extending mailman
support for single sign on.
>From what I gather from the discussion, the issues, with using mailman
passwords is that they are not not very well protected.
But if we can fix these issues with mailman for our implementation, openID
seems to be a good idea to work on.
So I guess we can agree we want to implement openID provider for a *more
secure version* of mailman. Can we?
I'll start working on that. I'll go through the openID enabled mailman
support and figure put what places we need to strengthen the password
security.
(Or if we are coming with Systers wiki then we can use the Systers wiki to
act as the openID provider) I think we can start implementing an openID
provider module for the mailman first, test the effectiveness of single sign
on and then once the wiki is up and working we can consider whether or want
we want to make the Systers wiki as the openID provider.
About Robins mail,
I might be a bit biased here but using openID should not be very difficult
for Systers users to adapt to. It is a new idea agreed, but using openID
would mean they would not need to remember separate usernames and passwords
for each of their Systers wiki or other systers affiliated accounts.
It appears that we want to extend openID support for only Systers affiliated
accounts. In that case we would not need to worry about openID being used
for bank accounts. Also one can use openID for acessing bank accounts only
if banks allow use of openIDs.
Looking forward to the summer of coding :)
Thanks all
Malveeka
On Thu, May 28, 2009 at 7:07 PM, Sarah Mei <sarahmei at gmail.com> wrote:
> 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.
>
>
> To unsubscribe from this conversation, send email to <
> systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org>>
> or visit <
> http://systers.org/mailman/options/systers-dev?override=9&preference=0>
> To contribute to this conversation, use your mailer's reply-all or
> reply-group command or send your message to
> systers-dev+authenticatio at systers.org<systers-dev%2Bauthenticatio at systers.org>
> To start a new conversation, send email to <systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> >
> To unsubscribe entirely from systers-dev, send email to <
> systers-dev-request at systers.org> with subject unsubscribe.
>
More information about the Systers-dev
mailing list