[Systers-dev] Considering LDAP and OpenID

[Jennifer Redman]

Sarah,
This is a really excellent outline of the differences between LDAP and
OpenID and why OpenID may be better then OpenLDAP for this particular
project.  Thank you for taking the time to post.

As we come up with good summaries of information I think it would be good to
include them on the systers wiki.  This way we create a reference source for
those of us directly working on the project and potentially a place for new
developers and/or people re-entering the work force to go and get some
background information in a fairly concise format.  It will look much nicer
when we switch to Mediawiki, but in the meantime would you mind posting on:

http://systers.org/systers-dev/doku.php/systers_open-source_development_projects
(we'll fix the url to be a little cleaner when we move to Mediawiki).

Or I'd be happy to post (or perhaps Malveeka?), if you don't mind.

Mailman archives are so hard to search that I think it would be good to pull
really excellent summaries and information out as they are posted to this
list -- which will, hopefully, eventually lead to a robust and useful volume
of documentation.

In fact, everyone on this list is invited to add information to the wiki if
you have a collection of resources or summaries, or bits of information that
may be helpful.  You just need to create an account to edit the wiki.  (
http://systers.org/wiki)

Thanks,
Jen



On Mon, Jun 1, 2009 at 4:11 PM, Sarah Mei <sarahmei at gmail.com> wrote:

> I happened to have dinner this weekend with a friend who knows a lot
> about directory services and authentication systems. I told him about
> this problem - OpenID vs OpenLDAP vs something else - and he had some
> really interesting comments. I apologize if some of this is obvious to
> folks who have been working on this project, but as a newcomer I
> wasn't exactly sure what LDAP was, what it was for, or how OpenID fit
> into the picture.
>
> OpenID and OpenLDAP are fundamentally different paradigms for a single
> sign-on system.
>
> OpenLDAP is a centralized directory service that keeps track of users,
> applications, actions, permissions, and all the mappings between them.
> So when a user logs in to an application, the application contacts the
> OpenLDAP server a) to authenticate and b) to get the list of actions
> the user can do. When a new app is brought online, someone in IT
> enters it into the OpenLDAP system and sets up which users have which
> permissions. Permissions changes of any granularity (i.e., you want to
> make someone a moderator for a particular forum) likewise require IT
> intervention.
>
> OpenID, on the other hand, *just* handles authentication. It confirms
> that the user is who she says she is, but says nothing about what she
> can do. Under an OpenID system, the Syster running each application
> would decide what permissions the various users had. In practice, this
> isn't too much work - she'd set up a default set of permissions and
> perhaps occasionally grant someone more privileges (as in the case of
> making someone a moderator). Permissions changes are easier to do than
> they are under OpenLDAP, but don't replicate.
>
> There are also differences in the usability of the two systems.
> OpenLDAP is kind of a dinosaur, written in C, hard to install, hard to
> modify, hard to debug - and permissions systems are notoriously
> tricky. OpenID, being a much younger (and less complex) system, has a
> number of implementations including some in Java, Python, Ruby, and
> PHP.
>
> There is also a third alternative - Apache Directory Server. It's an
> LDAP-compliant directory service, open source and written in Java. You
> can use the same extensions in web apps as you would use for OpenLDAP,
> and you get a centralized application/user/permission database, but if
> something's not working you can attach any normal Java debugger to the
> running process, set breakpoints, and figure out what's going on. In
> the directory services world, it's a rising star project as more
> companies try to move away from Active Directory (Microsoft's
> implementation of a directory server).
>
> So if ABI's priority is to make it easy for individual Systers to set
> up new applications (a twitter funnel, a wiki, a facebook app...) then
> OpenID is the way to go. If on the other hand there is a mandate to
> keep permissions centralized, then I think the Apache project is a
> better choice than OpenLDAP. Anyway, it's something to look at!
>
> Thanks for the interesting discussion.
>
> Sarah
>
> On Sat, May 30, 2009 at 8:41 AM, Robin Jeffries <robin at jeffries.org>
> wrote:
> > We can eliminate the monthly mailing, but it doesn't solve the problem --
> > the password is still being sent in cleartext through the mail.  But
> perhaps
> > if we restrict its use to just systers related sites, that isn't a
> security
> > compromise (or more of a security compromise than we have now). They
> won't
> > be using for their bank accounts or their email, etc.
> > Robin
> >
> > On Fri, May 29, 2009 at 6:22 AM, P. A. Grubel <pagrubel at tularosa.net>
> wrote:
> >
> >> 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<systers-dev%2Bauthenticatio at systers.org>
> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio 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%2Bauthenticatio%2Bunsubscribe at systers.org>
> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%252Bunsubscribe at systers.org>
> >
> >> <systers-dev%2Bauthenticati
> >> o%2Bunsubscribe at systers.org <o%252Bunsubscribe at systers.org> <
> o%252Bunsubscribe at systers.org <o%25252Bunsubscribe at systers.org>>>
> >> >
> >> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%252Bunsubscribe at systers.org>
> <systers-dev%252Bauthenticatio%252Bunsubscribe at systers.org<systers-dev%25252Bauthenticatio%25252Bunsubscribe at systers.org>
> >
> >> <systers-dev%252Bauthe
> >> nticatio%252Bunsubscribe at systers.org<nticatio%25252Bunsubscribe at systers.org>
> <nticatio%25252Bunsubscribe at systers.org<nticatio%2525252Bunsubscribe 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>
> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio at systers.org>
> >
> >> <systers-dev%2Bauthenticatio at systers.or
> >> g>
> >> >
> >> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio at systers.org>
> <systers-dev%252Bauthenticatio at systers.org<systers-dev%25252Bauthenticatio 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>><
> >> systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org> <
> systers-dev%252Bnew at systers.org <systers-dev%25252Bnew at systers.org>>>
> >> > <systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org> <
> systers-dev%252Bnew at systers.org <systers-dev%25252Bnew at systers.org>> <
> >> systers-dev%252Bnew at systers.org <systers-dev%25252Bnew at systers.org> <
> systers-dev%25252Bnew at systers.org <systers-dev%2525252Bnew 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%2Bauthenticatio%2Bunsubscribe at systers.org>
> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%252Bunsubscribe at systers.org>
> >
> >> <systers-dev%2Bauthenticati
> >> o%2Bunsubscribe at systers.org <o%252Bunsubscribe at systers.org> <
> o%252Bunsubscribe at systers.org <o%25252Bunsubscribe 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>
> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio 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> <
> systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org>><
> >> systers-dev%2Bnew at systers.org <systers-dev%252Bnew at systers.org> <
> systers-dev%252Bnew at systers.org <systers-dev%25252Bnew 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%2Bauthenticatio%2Bunsubscribe at systers.org>
> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%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.org>
> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio at systers.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.
> >>
> >>
> >> 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
> >>
> >>
> >>
> >> To unsubscribe from this conversation, send email to <
> >> systers-dev+authenticatio+unsubscribe at systers.org<systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org>
> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%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.org>
> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio at systers.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%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.
> >
>
>
> 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.
>