Plone User Management: LDAP vs RDBMS vs ?????

I’ve been faced with a user requirement I’ve never had to deal with before, and I’m on the fence as to what would be the best solution. I’m looking for war stories, implementation strategies, other ideas, anything that might help me make this decision.

Here are my basic requirements:

  • Multiple users will log into the following services with the same username/password:
    • Multiple Plone Sites
    • Samba
  • Most will be affiliated with the university I work for, but some will be outside collaborators.
  • We also need to store extra metadata about users:
    • Contact info
    • Application-specific info

Softer requirements:

  • Group/Role Management
  • Softer metadata requirements:

    • Store service info (which plone sites are they on, what Samba file shares do they have access to, etc)
    • Plone site-specific info

Our campus uses Active Directory. I’m able to authenticate against it in Plone and Samba. I have no direct access, however, to the AD or would ever be able to routinely modify it.

This situation is further complicated by the addition of users who are not affiliated with our university. For Plone this isn’t too big of a deal, but I have yet to figure out how to get Samba to authenticate against multiple sources (e.g. user not in AD? auth against local user).

So I’ve come up with some proposed scenarios, and have drawn up some diagrams to help convey the ideas.

Scenario 1

LDAP with central admin

Here LDAP is used as the central storage for users, groups, roles, etc, and LDAP handles both authentication and authorization. The information is managed via an external management interface. There are many LDAP management tools out there, so this wouldn’t require any development to that end.

There’s an alternate way to handle authentication here using Kerberos directly in Plone instead of letting LDAP do it. I added this after talking to a colleague of mine who’s ultimately in the same boat, and had a lot of trouble getting OpenLDAP to auth over Kerberos.

Scinerio 2

LDAP with Plone User Management

Here the situation is almost the same, except all of the user and group management is handled in Plone. This centralizes the user management to one common web-fronted UI (including Samba). I’m a little apprehensive of this situation. I don’t know if I like filesystem access decisions being made by Plone, and I also am not sure how well Plone works with LDAP in a read-write relationship.

Scinerio 3

RDBMS User Manager - Push to Plone

This option involves building a user management system, and storing all of our user info in a relational database. The user management system pushes out user and group info to the Plone sites via XML-RPC (or some sort of RESTful addon), and separately alters the local userbase and samba config files on the Samba server.

In this scenario, Plone does authentication via a PAS plugin that talks to the AD, and falls back to the RDBMS. Samba authenticates against PAM, which tries AD and falls back to the local system.

One caveat here, I haven’t researched PAM yet to be sure it can handle this.

So, I’m at an impasse. I don’t know what to do. Avoiding development effort would be nice, but I’m not afraid of building a solution if I need to. I’m apprehensive about cramming application-specific data into LDAP, but such things have been done before.

I don’t know what to do. Any input would be greatly appreciated. :)

Advertisements
This entry was posted in ldap, plone. Bookmark the permalink.

7 Responses to Plone User Management: LDAP vs RDBMS vs ?????

  1. I worked on a similar scenario a few years ago for a client. The solution we came up with was to use OpenLDAP as a rewriting proxy to present a consistent, single ldap view of a number of directory servers.

    You may not need quite that level of indirection now that Plone has support for multiple authentication sources in PAS, though Samba might necessitate it.

    The simplest solution would be to just setup a new LDAP for your non-AD users and groups and use these group memberships for permissions in Samba.

    I wouldn’t be overly worried about using Plone to administrate your local users and groups, but you may find an dedicated LDAP admin tool such as phpLDAPadmin or Apache Directory Studio to be more suitable (it probably depends who does the administration). Having local users be able to update their own metadata through Plone can be a great time saver.

    You will need to ensure you have a scheme to avoid potential userid conflicts (ldap rewriting might be necessary here), as you have no control over users subsequently added to the Active Directory.

    • jjmojojjmojo says:

      I hadn’t thought about user id conflicts, that’s a very good point. I think we’d probably do some sort of asynchronous “pull” from AD to help get people started, but I don’t think it’s a huge problem if the two data sources differ. The AD is used for campus wide concerns (sending alert SMS messages, notices via campus mail, etc), our sites are very specific to research and I could see people intentionally having different data in our LDAP.

      In fact, AD is only in the mix because of our campus single sign on system. It forces the users to change their passwords every 3 months, has a good password policy, etc. And it’s ubiquitous. :)

      We do definitely want users to be able to update their own info, my concern is for Samba stuff. We deal with Private Health Information so we have to be extra careful.

      Thanks!!

  2. Kevin Teague says:

    Yeah, keeping track of users and groups can get pretty messy no matter how you approach it.

    In our organization we have Plone sites, other web apps, and all the major os’es (Linux, Windows and Mac). We have LDAP servers and ActiveDirectory servers for auth/auth.

    The LDAP for filesystem/server access uses a different set of accounts than we use for logging into web applications. This is because not all the web apps are over https, so we don’t want to comprise network security with user’s who are lax about their web passwords. Since the web-accessed content is less sensitive, we allow user’s to set weaker passwords themselves as well (for better-or-worse, I imagine some user’s just re-use their network password for web).

    One set of accounts is chosen to contain additional user data (doesn’t really matter that much if it’s AD, network LDAP or web LDAP, just pick one – we use the web LDAP). Then we point Linux and Mac mail clients to that LDAP source so that user’s can do address autocompletion in their mail client. Then we sync nightly that data using a simple Python script into the corresponding fields in AD so that Windows users can access address information in Outlook (although this app has no autocomplete with networked address books, but it’s no surprise that Outlook is a pretty poor mail client).

    For updating the main user and group data, I looked at many of the available LDAP and AD management tools, and didn’t really find them satisfactory. I do use phpLDAPadmin as an internal sysadmin-only tool for exploring/poking-at the different LDAP and AD servers. But all of LDAP and AD management tools are terribly generic, which gives them awful usability. I wanted a tool with the following criteria:

    * Only present the fields that we are interested in managing

    * Don’t use only the default help text for the LDAP schemas (we use inetOrgPerson as a base). This text is too generic and needs to be made more user-friendly in order to be useable by a project manager or admin secretary.

    * Web-based: installing a GUI tool across Windows, Mac and Linux workstations is way to much work. A sngle web apps are much easier to deploy than three different types of clients across 250 workstations.

    Since I couldn’t find a tool I liked, I wrote my own :)

    http://www.bcgsc.ca/platform/bioinfo/software/gum

    It’s actually worked out really well, since user’s really like that they have stable URLs they can reference to see who exactly belong to a specific group or viewing a person’s user account details. And we can delegate updates access to whomever we like. Originally I attemtped to provide fine-grained access to allowing people to only update certain accounts or certain groups, but found that was becoming a big hassle and there were way too many corner cases. So instead I just made a single role for all edits, and then just log all edits performed through GUM into the ZODB. In this way, we can see if anyone is doing any “problematic” edits (which is really super-rare), and having an edit history can be invaluable with employee turn-over and trying to figure out who/why certain accounts got like they did!

    Since it’s written in Grok, I’ve also found that the Zope Component Architecture works well for creating a plug-in system, so GUM also makes a good place to hang an assortment of synchronization and assorted management scripts that I’ve written to help push data around to different places, etc.

    For dealing with additional user data, that isn’t covered by a common LDAP or AD schema, I’ve tinkered with extending our inetOrgPerson schema objects with an additional custom schema. But I’ve found dealing with LDAP is generally quite a bit of hassle – documentation tends to be poor, writes are non-transactional, and the python-ldap api isn’t as comfortable to use as writing to whatever you’re happiest with for managing ad-hoc data, and finally you need to be more careful about updating LDAP since it sucks to take down *everything* in your organization because you’re just trying to restart the LDAP servers to update the schema for some inconsequintial field. For ad-hoc user data, I use the ZODB, since I’m really comfortable with it, and it’s super easy to use – then just add some custom Views in a seperate distribution installed alongside our GUM app instance. But using a relational db would work just as well if that’s what your comfortable with.

    Finally we use the old school, “PasswordResetTool” for Plone to allow external collaborators the chance to change their web-only passwords themselves.

    As for our groups, we have a single group source in LDAP, but groups only store Title, Id, and List of User Accounts. So we have a tonne of groups that are still isolated and need to be manually updated and are perpetually out-of-sync (e-mail groups, issue tracker groups, posix groups). Tackling groups in a more one-stop automated fashion is still on the to-do list.

    • jjmojojjmojo says:

      I knew I wasn’t the first one to have this problem :)

      And incidentally, it looks like we may be in the same area of study!

      I haven’t done a lot with LDAP in the past, but I had a feeling it wouldn’t be ideal for storing application data. Thanks for confirming that.

      I will definitely check out GUM, if we end up using it here we’ll be happy to help with that TODO list :)

  3. Petri Savolainen says:

    If you offer access to Plone to the outside collaborators, do they _really_ still need access to samba for file sharing? Unless there’s significant amount of files in samba shares the external collabs _absolutely_ need access to (ie. they cannot be moved/copied to Plone for external collabs), just use existing AD and add external collaborators to Plone manually. The lowest-cost approach by far.

    Often the most cost-effective solution is to rethink the problem and recheck the set of the absolutely critical minimum requirements, rather than jumping into implementation.

    • jjmojojjmojo says:

      It’s an odd situation. We’ve got a Director physically leaving, but her responsibilities as Director won’t be going away. She’s also adding new staff who won’t be affiliated with our university, but still working closely with her.

      That said, you do make an excellent point. When I added the requirement for Samba access, it was without any critical discussion. My boss said “we need to add these people to our website” and I said “OK, will they need Samba access too” and he said “yes”… and so a requirement was born :P

      I need to talk to him again and clarify exactly what sort of access is really required; I need to get some specific cases out of him. I’ll be surprised if Plone couldn’t handle all of it.

      Thanks :)

  4. Dan Thomas says:

    I have successfully deployed LDAP authentication for numerous Plone websites and I would suggest you use Plone for read-only lookup to multiple connectors. In my case I use Active Directory AND the local Plone user repository, but you can add more connectors, they are read sequentially. I don’t think it’s a good idea to update AD-based metadata directly from Plone, you invite breakage or insecure connections.

    In my typical use case, I create a Plone OU in AD, put new groups that Plone needs into it, and populate those groups with my AD users. Non-AD users get entered directly into Plone.

    You might want to consider a centralized LDAP tool for managing user data, and Plone for all lookups (cached, of course).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s