780202 - [Security review] MozLDAP

Status: RESOLVED FIXED

(mozilla.org :: Security Assurance: Review Request, task, P3)

Description

[Peter Bengtsson [:peterbe]]

> Who is/are the point of contact(s) for this review?
Peter Bengtsson, [e-mail]


> Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):

It's an abstraction on top of the Mozilla LDAP using an Web API as the interface. 
You can, for example, do `curl http://server/employee?mail=[e-mail]` and deduce if that email address matches an active employee and if matched some additional elements such as first and last name and UID. 

The three entry points for the API are:

1. /exists?mail=<mail address>
2. /employee?mail=<mail address>
3. /in-group?mail=<mail address>&cn=<group name>

All three always returns JSON. If nothing is found, you get just `{}`. 
On the first two, if you do get a match you get something that looks like this:
{"mail": ["[e-mail]"], 
 "sn": ["Bengtsson"], 
 "givenName": ["Peter"], 
 "cn": ["Peter Bengtsson"], 
 "uid": ["pbengtsson"]}
On the third one, if there's a match you just get:
{"group": "OK"}

For all entry points a GET parameter called "mail" is always required. However, all other GET parameters are appended to the search. E.g. 
`/employee?mail=<mail>&someattribute=value&otherattribute=othervalue` or you can leave the value empty and it's assumed a boolean like this for example:
`/exists?mail=[e-mail]&hgaccountenabled`

There is NO authentication to use the Web API. The assumption is that it will be behind the VPN. 

The use case is websites that want to interact with our LDAP but don't want the hassle of using ldap binaries and maintaining a bind user. For example, internal sites that use Persona.org to just get an email address but you want to A) find out if the user is an active employee and B) fetch the given name so you can say "Welcome back Tim!"


> Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:

Original bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=773691
Mana page:
https://mana.mozilla.org/wiki/display/websites/MozLDAP
Code:
https://github.com/mozilla/moz-ldap


> Does this request block another bug? If so, please indicate the bug number

No other bug other than #773691

> This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?

Normal.


> To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list? If so, which goal?

Q3 2012 Goal
https://intranet.mozilla.org/2012Q3Goals#Web_Development
(See under section "Grow Mozilla")

> Please answer the following few questions: (Note: If you are asked to describe anything, 1-2 sentences shall suffice.)
>        Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?

No.

>      Are there any portions of the project that interact with 3rd party services?

No. Only our own LDAP server.

>        Will your application/service collect user data? If so, please describe 

None. Not even caching. 

>    If you feel something is missing here or you would like to provide other kind of feedback, feel free to do so here (no limits on size):

The tech lead is me, Peter. 
The team lead is Laura Thomson, [e-mail].

The app actually does more than just the JSON entry points in the API. 
At `/docs` there's a basic form that helps you understand how to use the API. You fill in a form with the mail address and or what type of search you want to do. It then displays the API URL for that query and also the output. 

There will be more documentation available later. Most of this probably in form of links to Mana and Intranet/Wiki for hints about what other attributes you can use and what groups you can query for. 


>    Desired Date of review (if known from https://mail.mozilla.com/home/[e-mail]/Security%20Review.html) and whom to invite. 

ASAP :)

Comment 1

[Guillaume Destuynder [:kang] [this account is no longer active]]

Note: this comment is not the webappsec review.

MozLDAP appears to be an interface to LDAP, that replaces the LDAP protocol by JSON and is easier and faster to work with for the web developers.

However, we:
- restrict LDAP access per application (different applications get different views/access to LDAP attributes/groups etc)
- authenticate the access (this is also needed to know which set of restriction is needed)
- encrypt the transport (so that the information cannot be intercepted and authenticate it (so that one cannot inject data or perform a man in the middle)

The VPN does NOT solve this. In order to solve this with a VPN you would need a end-to-end VPN (ie from each host to the LDAP server), which is very unpractical, so I don't believe this is the case.

The VPNs are just a mean to communicate from one *network* to another, or  from one client to a *network*.

Instead we (as in opsec) propose that you use https between the applications and MozLDAP (and only https), and authenticate on top of https. Additionally, you would need to authenticate using valid LDAP credentials between the application and MozLDAP (one bind user per application)

This would effectively replicate a similar level of security as talking directly to LDAP (like we do right now), but with the ease of using JSON.

Feel free to include one of us during the secreview meeting for this bug if more information/discussion is needed on that point, or if our solution does not satisfy the needs.

Thanks!

Comment 2

[Laura Thomson :laura]

Is this in progress?

Comment 3

[Jake Maul [:jakem]]

Start and target dates in the whiteboard is over a month past... any news on this?

Comment 4

[Peter Bengtsson [:peterbe]]

What Jake said ^

Comment 5

[Laura Thomson :laura]

Status?

Comment 6

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

We're looking at using this for the new Input, too. It'd make some of what we need to do easier plus we'd be able to use the same authentication/authorization implementation that Air Mozilla is using.

Comment 7

[Laura Thomson :laura]

Can anyone please provide an update as to the status of this secreview?  It's been a month since I last asked, with no response.

Comment 8

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

(In reply to Laura Thomson :laura from comment #7)
> Can anyone please provide an update as to the status of this secreview? 
> It's been a month since I last asked, with no response.

Laura, I am trying to hunt down yvan, as he is the owner of this review, he was PTO last week.

Comment 9

[Yvan Boily [:ygjb][:yvan]]

Sent an email to peter and kang to hash out some details around authentication of consuming services.  Once thta is resolved, this review will be completed.

Comment 10

[Austin King [:ozten]]

Yvan - can you advise us in the following issues, to see if securing the APIs and reducing their surface area for 1.0 is viable?

https://github.com/mozilla/moz-ldap/issues/1
https://github.com/mozilla/moz-ldap/issues/2

Comment 11

[Peter Bengtsson [:peterbe]]

We met. We discussed. We decided. 
https://etherpad.mozilla.org/mozldap-discussion

Plan of action:
===============

* We go with Basic Auth to reach MozLDAP
** instead of .htpasswd file we use mod_ldap 
** developers (employees) file Service Now request or Bugzilla bugs to get new MozLDAP credentials (these are actually a form of LDAP bindusers but we don't want to confuse the nomenclature any further)
* A MozLDAP where employees can go on and generate their credentials themselves is a discussion for the future. Aka. self-service. Not part of 1.0.

peterbe
-------

* reduce the functionality to ALWAYS return booleans (e.g. {"match": "found"})
* make a webpage on MozLDAP that...
** explains where to go to request credentials
** how to use MozLDAP 
* show jabba what MozLDAP does. ie. what queries it sends.
** demonstrate how to run the code locally to debug
 
jabba
-----

* Participate in https://bugzilla.mozilla.org/show_bug.cgi?id=780317 to explain how to best use mod_ldap
* review how MozLDAP works to make sure its bindusers have the least possible power

kang
----

* Final sign off on this bug so that the deployment can start

ozten, yvan
-----------

* Nothing

Comment 12

[Guillaume Destuynder [:kang] [this account is no longer active]]

to be clear, the jabba task of restricting acls would make sure mozldap makes search queries instead of read, enforcing the boolean queries from the ldap side (as possible, it might be we require read sometimes)

I ack the plan of action from comment 11 for the opsec side (with the addition of what I wrote in this comment). It is ok for us to deploy it that way.

Thanks!

Comment 13

[Peter Bengtsson [:peterbe]]

:yvan Can you resolve this now? :kang has ack'ed it. This blocks the deployment bug.

Comment 14

[Austin King [:ozten]]

I think we're still blocked. Can we close this? Or what is left?

Comment 15

[Peter Bengtsson [:peterbe]]

What are we waiting for here? Is there anything I can help to explain to close this?

The deployment bug is still being blocked by this bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=780317

Comment 16

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Yvan - please respond to the need info here