[Systers-dev] Considering LDAP and OpenID

[Sarah Mei]

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>
>> 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%2Bauthenticati
>> o%2Bunsubscribe at systers.org <o%252Bunsubscribe at systers.org>>
>> >
>> <systers-dev%2Bauthenticatio%2Bunsubscribe at systers.org<systers-dev%252Bauthenticatio%252Bunsubscribe at systers.org>
>> <systers-dev%252Bauthe
>> nticatio%252Bunsubscribe at systers.org<nticatio%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.or
>> g>
>> >
>> <systers-dev%2Bauthenticatio at systers.org<systers-dev%252Bauthenticatio 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>>>
>> > > >
>> > > 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%2Bauthenticati
>> o%2Bunsubscribe at systers.org <o%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.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>>
>> > >
>> > 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.
>>
>>
>> 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>>
>> 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> 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.
>