connecting PANDA user logins to network login?

[MaryJo Webster]

I'm setting up a PANDA at the St. Paul Pioneer Press and the IT guys who are helping me are wondering if it's possible to somehow link the PANDA user logins/passwords to the existing logins/passwords that staff currently use to login to the company network/email, etc.? I didn't see anything along these lines in the documentation. 

What do other newsrooms do? And how do you keep up with the comings and goings of staff over time (in terms of adding and deleting people)?

thanks,

MaryJo Webster

[wm higgins]

i considered trying that, but keeping it all in sync didn't seem worth the effort.

it was easy to assemble a csv of staffer emails and names and to create users with the bulk-creation option available at admin/panda/userproxy/add_many/

given the number of people who actually use our panda instance, i'm glad i didn't put more effort into syncing log-ins.

[MaryJo Webster]

Just FYI....we are using it to replace a very long-standing intranet that gets a lot of use. So I'm expecting a large percentage of the newsroom to need access to it -- maybe not regular access, but something. I'm kind of wondering if we could get away with individual accounts for the "power" users (particularly those who might actually put their own data up there) and then a generic account that everyone else could share. Thoughts?

thanks.

MaryJo Webster

Senior Data Reporter

Digital First Media

mweb...@digitalfirstmedia.com

(651) 491-6576 (cell)

@MaryJoDFM

--
You received this message because you are subscribed to the Google Groups "PANDA Project Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to panda-project-u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Clark]

Here at Newsday, we had a couple requirements: We wanted everyone to have access to PANDA at launch and we wanted users to be disabled or created auto-magically. 

We didn't want to have to constantly monitor when people leave for the Wall Street Journal or the New York Times. Disabling their accounts was a priority for us, because much of our data is statewide. This might not be a problem at other papers. We also didn't want to have to constantly be adding new accounts. 

We also wanted buy-in for our hard work of setting up PANDA, and felt that giving everyone access at launch increases the chance of them using it — they got to start using it right after the unveiling! It's nice to lock in whatever excitement comes from first showing off PANDA by giving people the chance to try it out right after the presentation.

We run Windows here for our user logins. So, I had to connect PANDA to LDAP, the Windows user account thingy. This actually sounds a bit easy to a coder, because both Python and Django — two key components of PANDA — have LDAP tools. I couldn't use Django for this, though (more on this later). Python has a decent library in python-ldap, and I used it...

http://www.python-ldap.org/

However, since our PANDA is running in the cloud, we were not permitted to connect it directly to LDAP. The IT folks were not happy with the idea of allowing the cloud server to connect to our LDAP server, which is behind our firewall. This is why I couldn't just hook PANDA's Django directly into LDAP. So, I came up with a workaround.

On a different, local server running in our building behind the firewall for fun data/I-team things, I setup a script I wrote to run every night. It queries the LDAP database, compiles the emails/names of newsroom employees into a csv, uploads them to the cloud, and then runs another script I wrote that is on the cloud server. The cloud script then uses the CSV to find new users or delete old users from PANDA.

New users get an email asking them to activate and set a password. Yup, they don't automatically get the same password that they use for Windows, but, hey, it's better than no automation. They can change the password as needed to have it match their Windows password or just keep it the same for eternity.

I did not use the PANDA API, but I just noticed that it can be used to create user accounts. That is very helpful....

http://panda.readthedocs.org/en/1.1.1/users.html

Anyway, just some food for thought.

Cheers,

Matt Clark

To unsubscribe from this group and stop receiving emails from it, send an email to panda-project-users+unsub...@googlegroups.com.

[Nolan Hicks]

Like Bill in Tampa, we're just using the PANDA user management tools that were provided and we haven't had any trouble so far. Though, we haven't attempted to manage anywhere near the number of users that you will be managing. 

Nolan

[Brian Boyer]

Wow, Matt. That's a fantastic hack. I've implemented a couple of LDAP+firewall connections, and yeah, it took a lot of convincing w/ the IT crews. If it's possible to share the code, I'm sure the PANDA community would make good use of it! b

To unsubscribe from this group and stop receiving emails from it, send an email to panda-project-u...@googlegroups.com.

[Todd Wallack]

I'm about to introduce the Boston Globe staff to Panda and am planning to encourage most people to just use one generic account because it's simpler and you can do most everything with a shared login (except for downloading databases.) 

Our implementation of Panda is only available through our Intranet or a VPN, and it's all public records anyway, so I'm not worried about former employees accing it.

However, I'll probably set up individual accounts for any "power users" who are interested in downloading entire databases or uploading their own.  I think you can do virtually everything else with a shared account.

Todd Wallack

Boston Globe

twal...@globe.com

[Serdar Tumgoren]

Hey folks,

Posting back with a report on efforts to integrate LDAP with PANDA. This a long one, so here's the TL;DR:

LDAP works seamlessly with PANDA and is relatively easy to install if you're experienced with LDAP in general.

LONG VERSION

I'm happy to report that integrating LDAP with PANDA worked like a charm, simply by leveraging Django's native authentication functionality. This is a testament to Chris and Brian's code design -- I was shocked at how little we had to modify to get this working.

So, how did we do it?

At a very high-level, you need to use or create an alternative Django Authentication Backend and hook it into your settings file. If you're lucky enough to have OpenLDAP, then much of the hard work has been done for you by django-auth-ldap. This module wraps the lower-level python-ldap library and makes LDAP integration pretty much entirely a configuration issue.

Unfortunately, I was unable to use django-auth-ldap because it doesn't seem to play nice with ActiveDirectory (my corporate AD setup requires a username to have a REALM prefix (e.g. APFOO\stumgoren). I couldn't find a way to support this requirement in django-auth-ldap without seriously hacking up the source, so instead I wrote a custom auth backend that does precisely what we need. This may sound a lot more scary than it was. The Django docs, django-auth-ldap source code, and below Snippets provide solid guidance and sample code on how to wire up a custom auth backend:

• https://djangosnippets.org/snippets/2604/
• https://djangosnippets.org/snippets/2899/

I won't go into all the details, but generally speaking, you need to:

• Configure and initialize an ldap connection
• Perform an LDAP bind operation with the authenticating user's credentials
• Perform an LDAP search with the bound connection, fetching basic user info such as first and last name, email, etc. 
• Use the search results, if any, to create/update an instance of panda.models.UserProxy

Once you've written a backend that performs the above steps, just activate it in your settings:

### settings.py or local_settings.py ####

# Possible other LDAP configs, especially if using django-auth-ldap

AUTHENTICATION_BACKENDS = (

    'panda.auth.ActiveDirectoryBackend',# or, perhaps, 'django_auth_ldap.backend.LDAPBackend',

    # Enable Model login as well, so that we can log in using default panda superuser after bootstrap

    'django.contrib.auth.backends.ModelBackend',

)

Note above that we included the default ModelBackend auth, which allows us to login using the default panda superuser (this requires installing the test_users.json fixture). Django will try auth backends in the order they're listed in this setting, so if LDAP fails, it falls back to ModelBackend. You will

definitely *not* want to include this backend if you want to restrict auth to LDAP only.

We only included it in order to log in after bootstrapping and assign superuser/staff perms in the Django admin to ourselves. Security-minded folks will chide us for being lazy in the bad way (we are), and point out that you could just as easily do this in the django shell/dbshell. Anyhow, we're planning to de-activate this auth backend after soft launch, but it's a feature to be aware of if you need support for multiple authentication backends.

Other than adding a custom auth backend, we only lightly modified a few PANDA templates to avoid confusing end users. For example, we removed the "forgot password" feature on the login page and the password reset feature on the User profile page.

Overall, this process was pretty painless and the actual dev work fairly limited. The biggest hurdle for me was learning about LDAP and some of its idiosyncrasies, especially with respect to ActiveDirectory and our in-house configurations. A few gotchas I worked through are listed below, so hopefully they save you some time and pain. Also, I'd strongly recommend chatting with your IT folks up front to find out how to configure LDAP, rather than fumbling your way through it as I did using a tool called ldapsearch. A few key questions to ask:

• Are we using OpenLDAP or ActiveDirectory?
• Is anonymous bind supported?
• Do we use StartTLS or SSL for security?

Below are a few additional notes and gotchas:

• Email notifications - PANDA's email notifications "just worked" as expected after we wired up our custom Auth Backend. Specifically, user activation emails were *not* sent after initial login, whereas data upload emails *were* sent. I suspect the activation email was not triggered because our auth backend set a default "dummy" password on UserProxy at creation time, but I can't recall off-hand without going back to the code (Chris, feel free to set me straight there and let me know if there potential land mines).
• Referral chasing - This is a topic related to LDAP's inner workings, but suffice it to say that it will be a big source of headaches if your Python code does not handle LDAP referrals correctly. The general advice seems to be to disable referal chasing, which in our case resolved issues we were having with ldap search requests indefinitely hanging. Of course, I'd consult with your IT dept before making any decisions about this. If you do want to disable referral chasing, you have to configure the ldap connection *before* you bind:

        l = ldap.initialize(settings.AUTH_LDAP_URL)

        l.set_option(ldap.OPT_PROTOCOL_VERSION, 3)

        l.set_option(ldap.OPT_REFERRALS, 0) # DISABLE REFERRALS

        try:

            l.simple_bind_s(bind_dn, password)

        # etc.

• libsasl development headers - If you're working on Ubuntu 12.04 and serving the app from a virtualenv, you should install libsasl development headers in order to successfully build python-ldap: sudo apt-get install libsasl2-dev.

Those are the major notes/gotchas from our experience. Hopefully it helps others who want to integrate LDAP. Of course, don't be shy with questions or pointing out something that may be a hidden land mine in our setup. Meantime, thanks again to Chris and Brian for such elegant design.

Regards,

Serdar

[Brian Boyer]

Been meaning to reply to this thread for some time. This is really, really neat. Thanks so much for the write up, Serdar!

--

[Serdar Tumgoren]

Sure thing Brian. Happy to do it. I should also correct a few things from the original message: 

* Email updates *do* get sent on initial login. I suspect I misinterpreted this initially b/c I had enabled email notifications after creating the user I was testing with (could have sworn I had not done that, but probably did). Anyhow, we decided we could live without notifications, so we just disabled the feature and it works like a charm.

* Also, with regard to django-auth-ldap -- in retrospect, I can't say with 100% confidence that this is a viable option b/c of the need to create/update a UserProxy instance (rather than the standard User model). There are Django-level settings options to specify the user auth model and some related behavior, but I never tested these out thoroughly b/c this path proved unworkable for us for unrelated reasons. I suspect that a custom Auth Backend is really the way to go, even in the case of OpenLDAP setups, but again, I can't say this for certain and would be interested if anyone else got things up and running using django-auth-ldap.

Otherwise, the setup is working great for us so far. Thanks again to Brian, Joe, Chris and all the contributors to the project. We're loving it!

Best,

Serdar

ps -  Ping us online or off if anyone has questions about how to implement the LDAP stuff.