801833 - Investigate using LDAP for logins for access to sensitive data

Status: RESOLVED FIXED

(Input :: General, defect)

Description

[[:Cww]]

Was asked to try to match metrics privacy procedures and one thing they do is use LDAP for logins to ensure that sensitive data is only open to Mozilla employees (and only certain Mozilla employees at that).

I'd like to see if we can do the same for on-site access to things like email address and technical info.

This bug is to investigate feasibility. Please convert to an implementation bug if that's the decided path forward.

Comment 1

[Will Kahn-Greene [:willkg] ET needinfo? me]

James pointed out on IRC that we should talk to Peter because it's probably the case he's either looked into this or done this already.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

We need to be using LDAP for auth. James said this might be an ops issue. Needs research.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Grabbing this one.

Comment 4

[Will Kahn-Greene [:willkg] ET needinfo? me]

cc:ing :cturra and :melissa

Chris: I'm not entirely sure how to go about doing this, either. One person said that Mozillians uses LDAP logins for access to sensitive data and that ops might have set it up. Does that sound right?

Comment 5

[Chris Turra [:cturra]]

:willkg - we can definitely add ldap auth to one or more directories within the app. these will be done through apache configs. can you give me an example of a url you would want protected by ldap logins?

Comment 6

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm a little fuzzy here, but I'm pretty sure what we want to do is protect access to anything under /admin .

James: Does that sound right? Is it ok to do it with apache config rather than django auth modules?

Comment 7

[Will Kahn-Greene [:willkg] ET needinfo? me]

cturra made it require LDAP on input-dev.allizom.org. Once you log in with LDAP, then you're greeted with the django admin page.

Pretty sure we can fix the double-login. It's probably just a middleware or something. Will need to make sure that it's still usable in dev environments (e.g. on my laptop).

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

Mike pointed out I read the description wrong.

We actually don't want LDAP access on /admin. What we want is for django to authenticate users using LDAP which is a really different thing.

Chris: Can you remove the LDAP configuration? We (probably) need to fix this differently.

Tomorrow, I'll track down Cheng to find out if *all* users are going to be authenticated with LDAP (users and admin) or just some or what.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

A few meetings ago, we talked about crowd-sourcing translating feedback and categorizing and things like that. Those people would have user accounts in Fjord, but those accounts would not be in LDAP.

We have a second group of people who will have access to sensitive data and thus we need to require that they have an LDAP account and in this way restrict access to sensitive data to current employees.

Does that sound right? If so, then we have a requirement that we support two authentication systems.


Peter mentioned two systems for dealing with LDAP things:

* django-auth-ldap: http://packages.python.org/django-auth-ldap/
* MozLDAP: https://github.com/mozilla/moz-ldap

The first integrates everything into Django.

The second is a service that would be run by Mozilla that yields a REST API to LDAP which makes it easier to consume. It's currently stuck in sec review (https://bugzilla.mozilla.org/show_bug.cgi?id=780202) and thus IT hasn't set it up, yet. This is what Air Mozilla will use.

After talking with Peter, I'm inclined to think we have similar groups and requirements to AirMozilla and thus should just model our solution after what they're planning to do. However, that requires MozLDAP to make it through sec review and get stood up.

Does that sound ok?

Comment 10

[Will Kahn-Greene [:willkg] ET needinfo? me]

Assuming the material comment #9 looks ok, then we'd be blocked on the sec review for MozLDAP and also IT getting a server up and running. That seems like a lot of stuff, but Air Mozilla is going to use this, too.

In the meantime, our immediate 2013q1 needs probably let us slide by on implementing the following:

1. add persona
2. use the django groups/permissions system

Pretty sure that gives us a good upgrade path when MozLDAP is available.

I created bug #834279 for adding persona support. We don't have anything that requires us to denote anyone other than admin, and django has that built-in, so I think that's all we can do now.

I'm going to keep this in the blocking list for bug #832316, but I think we can let this slip if nothing depends on it.

Comment 11

[Will Kahn-Greene [:willkg] ET needinfo? me]

Removing the block for -prod. We don't need it right now and it's better to wait until some of the things that will make it easier are in place.

Comment 12

[Will Kahn-Greene [:willkg] ET needinfo? me]

Putting these in my queue for this quarter.

Comment 13

[Will Kahn-Greene [:willkg] ET needinfo? me]

We don't need this right now, so I'm going to push it off.

Comment 14

[Will Kahn-Greene [:willkg] ET needinfo? me]

I think what we have now is good enough. Marking this as FIXED.