700702 - Elmo to use BrowserID

Status: RESOLVED WORKSFORME

(Webtools Graveyard :: Elmo, defect, P5)

Description

[Peter Bengtsson [:peterbe]]

Dogfooding BrowserID is an important Mozilla goal. We should use it in Elmo. Elmo is a good candidate because it's more than intranet-like exposure and our Elmo users are our friends which might lend us the necessary patience if we need it. 

To be able to use it, we need to depend on sasl-browserid [1]. That's what connects our BrowserID users to our LDAP for the "backend". However, to be able to figure out an authenticated user's group memberships we'd need an independent LDAP lookup using a binduser. BrowserID will basically just replace the password checking part of logging in. 

sasl-browserid is currently going through a security audit which might take some time.

Also, I have volunteered Elmo on the BrowserID wiki [2]. 

[1] https://github.com/ozten/sasl-browserid & https://github.com/ozten/mozillians/blob/browserid/docs/browserid.rst

[2] https://wiki.mozilla.org/Identity/BrowserID/MozillaDogfood

Comment 1

[Axel Hecht [:Pike]]

I'm not sure how "browserid" we'll be in the short term. What's the story of browserid regarding locking people in to one account authority?

I'm asking because logging in against any other store is just endorsing confusion, like "I'm logged in, why can't I sign off?" We've had a few of those for people with multiple ldap accounts with different permissions.

Comment 2

[Peter Bengtsson [:peterbe]]

Interesting point. Let's assume we pull it off so that the right permissions work just like it works today on the pure LDAP authentication. 

We might potentially have a choice upon logging in to Elmo. Either by BrowserID or by the old email + password thing. Similar to how Stackoverflow and Kwissle [1] does it.

To be honest, I'm a complete BrowserID novice but I can see the long-term benefit. Upon tackling this bug (when time allows) I know I'm going to have to do a lot of reading up to really understand how it works. Also, in the sense of dogfooding, if this is too hard and confusing to implement we need to feed that back to the Identity team that they're docs/demos need more work. 

[1] http://kwissle.com/login/

Comment 3

[Austin King [:ozten]]

> What's the story of browserid regarding locking people in to one account authority?

BrowserID is designed to be decentralized. Your "locked in" to your email provider... which you choose.

>  "I'm logged in, why can't I sign off?"

Elmo sessions length, and logout would still be controlled in Elmo.

Comment 4

[Austin King [:ozten]]

(In reply to Peter Bengtsson [:peterbe] from comment #2)
> Also, in the sense of dogfooding, if this is too hard and confusing to implement we need to feed that back to the Identity team that they're docs/demos need more work. 

+1000

Comment 5

[Axel Hecht [:Pike]]

Given how properly I managed to confuse Austin, I think we should hold back on this.

Austin: We're taking our permissions directly from ldap groups, instead of maintaining them again in our user db. Thus, if you log in with credentials that we understand but don't map to, say, the scm_l10n ldap group, you can't do what you think you should be able to do. Armen and Rail are pet examples, as they have one identity in our ldap store that's a localizer person, and one that's a build person. So whenever they log in, they can't hit half the buttons. As we already spend quite some time vetting peoples permissions to be in ldap, we really don't want to do that manually in yet another place.

Which leads me to a follow-up documentation request: How do I tack business-logic control like permissions to a browserID-authenticated user? For me, it's kinda part of identity, but maybe that's explicitly not, and it'd be worth putting that up somewhere.

Alternative IDea, can we make a browserID verify service on top of our ldap? Could that export extended information on verification like user groups, maybe only if requested?

Comment 6

[Austin King [:ozten]]

(In reply to Axel Hecht [:Pike] from comment #5)

A dependency for this bug is sasl-browserid[[1] being deployed to the internal LDAP directory. This makes the directory BrowserID aware[2]. All ldap groups and business logic continues to work the same way it does today.

If a user chooses the wrong email address (one that is not in our LDAP) then Elmo would display a message... "foo@bar is unknown, do you want to _use a different email address_? If you are new, _file a bug_ to get access." or whatever.

@pike please join #identity (or Skype) and let's discuss how BrowserID currently works and any issues it would present for Elmo.

[1] https://github.com/ozten/sasl-browserid
[2] https://github.com/ozten/mozillians/blob/browserid/docs/browserid.rst

Comment 7

[Peter Bengtsson [:peterbe]]

Definitely worth reading: http://ozten.com/psto/2011/11/08/demystifying-browserid-mozilla-ldap-sites/

Comment 8

[Peter Bengtsson [:peterbe]]

@ozten, could we not just add BrowserID and use the binduser to 1) look up if the user exists (and is active) simply by searching from the verified email? and 2) look up what groups said found user belongs to and apply the django stuff accordingly. 

Or... is it better to patiently wait for sasl-browserid to get reviewed and finalised. Also you have a better handle on "stress level" of this browserID dogfooding that Todd pressed on. 

Lastly, might we send out the wrong message to users (e.g. my mom) who has a BrowserID account but has nothing to do with the Mozilla LDAP?

Comment 9

[Austin King [:ozten]]

My understanding is that you have to bind as the user to do #2. That means sasl-browserid.

> Lastly, might we send out the wrong message to users (e.g. my mom) who has a BrowserID 
> account but has nothing to do with the Mozilla LDAP?

Great product question, I can't answer that.

Comment 10

[Axel Hecht [:Pike]]

See also comment 1.

I think there's probably a UX when verification against our ldap store fails that other whatnots to auth against are not supported as you don't get any benefits.

Comment 11

[Austin King [:ozten]]

(In reply to Axel Hecht [:Pike] from comment #10)

If it is technically possible to check group association with the binduser, I'm all for shipping BrowserID with that solution.

Benefits:
* @peterbe's solution is simpler than sasl-browserid
* It could ship sooner
* Still uses LDAP group knowlege and doesn't duplicate any data

Comment 12

[Axel Hecht [:Pike]]

Let me see if I got this right?

- on pressing the browserid button the client opens browserid.org, and get's back an assertion.
- the client passes that assertion to browserid.org again to get the verified email? Or should elmo do that? I guess elmo, sounds insecure otherwise. https://github.com/mozilla/browserid/wiki/How-to-Use-BrowserID-on-Your-Site could be more specific on that, it only talks about "You".
- that email is then sent to elmo, or used locally, which then does most of the ldap requests it's doing right now (one bind less, I think).

I guess I'm still confused.

I also talked to thunder in KL, the user-facing bonus is that they don't have to rely on the password manager for their ldap account.
Not sure how much we actually dogfood, if we're taking an incremental step forward, though.

Comment 13

[Peter Bengtsson [:peterbe]]

Regarding the flow; you basically do a round-trip (to browserid.org) on the client side and then connect to the server-side with AJAX. Then the server-side does a round-trip (again to browserid.org/verify).

Good point regarding the "actually dogfooding" if we're not using sasl-browserid. 
A concern raised from Austin (by chat) is that using a binduser to look up a user (by email) might not have the ACL rights to also return group memberships. (Note the use of the word *might*)

To be honest. I've sort of gone off the idea a bit. I'm eager to give it a try but considering that awesome things are yet to come (sasl-browserid and the new branding) there is also good reasons to wait and work on more pressing issues in the mean time.

Comment 15

[Axel Hecht [:Pike]]

Clarifying status, this was actually not FIXED, but we decided to not use browserid in that timeframe, thus WORKSFORME.