[Systers-dev] Considering LDAP and OpenID

[P. A. Grubel]

I'm new so if I am stepping out just let me know. Why couldn't you email
them their password instead of resetting it, but only when they have lost
it. I hate it when I have to go through resetting one and yes I'm one who
usually doesn't go to the site. I am mostly a lurker because I keep
"thinking" of re-entering the field. You would still eliminate the monthly
mailing of the password.
Pat

-----Original Message-----
From: systers-dev-bounces at systers.org
[mailto:systers-dev-bounces at systers.org] On Behalf Of Robin Jeffries
Sent: Thursday, May 28, 2009 8:56 PM
To: Malveeka Tewari
Cc: systers-dev+authenticatio at systers.org
Subject: Re: [Systers-dev] Considering LDAP and OpenID

On Thu, May 28, 2009 at 12:07 PM, Malveeka Tewari <malveeka at gmail.com>wrote:

> 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.


One thing to think about.  Because systers can go years without accessing
the site, they often have to have their password mailed to them when they do
want to access the site.  We could eliminate the monthly "here are your
passwords in plain text", but we still need a way of providing passwords to
users who have forgotten.  The obvious solution is to reset the person's
password, send them a random generated password (plaintext), and then force
them to reset it to something when they first log in.  That's a lot of extra
steps.  Granted, we will get higher security that way, but it's not like we
have had security breaches (everything on the site has been sent plaintext
to 3000 women).  So where is the balance here between usability and security
(Not sure I know the answer, but I want to provoke the discussion)


>
>
> 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.


Right now 95% of systers have one password to one part of systers (that
might be an underestimate).  Probably 10% of them will want to access or
write to the wiki in the first year.  From their perspective, there is no
issue of needing to remember separate usernames and passwords now --  so
anything you do is more work for them.  It might be worth the extra work for
the extra value, but we have to consider the value to our users and to us
the administrators (where the negative value is having to handhold a lot of
confused users through the process).  I'm especially concerned about it
interfering with new users getting accustomed to the site.

Robin

>
>
> 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%2Bauthenticati
o%2Bunsubscribe at systers.org>
>
<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthe
nticatio%252Bunsubscribe 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.or
g>
>
<systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio at syste
rs.org>
> >
> > To start a new conversation, send email to
<systers-dev+new at systers.org<systers-dev%2Bnew at systers.org>
> <systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org>>
> > >
> > To unsubscribe entirely from systers-dev, send email to <
> > systers-dev-request at systers.org> with subject unsubscribe.
> >
>
>
> To unsubscribe from this conversation, send email to <
>
systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticati
o%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.or
g>
> 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.
>


To unsubscribe from this conversation, send email to
<systers-dev+authenticatio+unsubscribe 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
To start a new conversation, send email to <systers-dev+new at systers.org>
To unsubscribe entirely from systers-dev, send email to
<systers-dev-request at systers.org> with subject unsubscribe.


No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 8.5.339 / Virus Database: 270.12.43/2139 - Release Date: 05/28/09
08:10:00