IT, Operations, Security and Webdev have prepared a BrowserID adoption plan for our LDAP directory. Questions come up frequently, so I wanted to capture the basics of the plan.
In terms of BrowserID adoption, there are three classes of Mozilla websites.
- Many webapps that use MoCo’s LDAP instance for authentication and group permissions
- Mozillians.org which uses a new community LDAP instance for auth and groups
- Many more webapps that manage their own authentication (via MySQL or whatever)
Number 3 has nothing to do with LDAP, so we can go dogfood BrowserID on a case by case basis.
Classes 1 and 2 depend on LDAP and what that means is fairly confusing, so I wanted to clarify our current plan and where we are at.
We all know the the Frog Prince story.
BrowserID is a lonely Princess as well as a protocol that gives the person currently using your webapp a way to disclose a verified email address.
LDAP (aka slapd) is an unloved frog that moonlights as a backend database; it authenticates people and keeps track of who is in what group. It’s got some warts, but don’t be so superficial.
sasl-browserid is the magical golden ball. Huh? Ya, blame the Brother’s Grimm.
When our princess drops the golden ball into the frog’s pond, poof, the frog transmogrifies into the princess’ long sought after life-partner. And they live happily ever after…
Okay, sasl-browserid is more of a C plugin than a mystical sphere, but whatever. This plugin BrowserID enables LDAP.
This will be short and painful, I promise.
- You enter your email address and password into a form
- Middleware code does a
simple bindwith a shared account
- Code does a
filtering by your email address to find your
- Code does a second
simple bindusing your DN and password, attempting to authenticate on your behalf:
- You are a known user with a good password
- Or not so much
- More stuff happens.
DN are LDAP terms.
- You click a link or button and do the BrowserID dance. Frontend code gets a BrowserID assertion and sends it to middleware.
- Middleware code does a
sasl interactive bindwith your
- Code uses ldap’s
whoami* and checks the output
- You are a known user in the system
- You are an unknown user in the system
- More stuff happens
sasl interactive bind and
whoami are also LDAP terms.
If that didn’t make your eyes glaze over, there is more gnarly details and an architectural diagram here.
What changed between before and after BrowserID? The authentication mechanism. What usually doesn’t change? The authorization and business logic of an application. Both sections have a "More stuff happens" section which means the goodness your app does and the permissions your users have, usually just continue to work.
We do not have to re-write our internal apps to take advantage of BrowserID.
sasl-browserid is getting a thorough review from the platform security team. In particular, David Chan has been doing a kick-ass job of finding flaws and ways to improve it.
Once it is ready, we’ll deploy it to development stage servers (next week or two).
But which app should we start with?
Our MoCo LDAP powers many, many Mozilla tools. This is beyond just web applications and bleeds into Desktop, command-line, and other uses; Reed’s biological functions are literally regulated by MoCo LDAP. It’s got both critical and sensitive information, so we have to be careful, but luckily we’ve also resently launched…
Mozillians.org also has a LDAP server backend. It has a lower risk profile, so we’ll deploy to it first. It’s lower risk for a bunch of reasons, including:
- Smaller, newer, fresher
- If it falls over, it won’t block Firefox development or othe critical Mozilla processes
- It has a dedicated team to monitor, diagnose, and fix any issues sasl-browserid introduces
The current plan is to BrowserID enable mozillians.org in it’s 1.2 release (3-5 weeks out). This will give us experience with sasl-browserid. Once it has proven itself production ready…
We’ll add the plugin to MoCo LDAP. We’ll update the internal phonebook’s PHP code. We’ll test, deploy, wait and see.
If that goes well, then all the other LDAP backed webapps can follow.
and gentleman… I use the acronym LDAP with all due respect for the Fear and Loathing I’m sure it provokes in each and every one of you…
We’ve made an organizational commitment (training, hiring, etc) to improving our ability to maintain our aging LDAP infrastructure. Jabba and Corey have done a top-notch job of revamping the MoCo LDAP, so it’s a sustainable sub-system.
We can adopt BrowserID without throwing away MoCo’s LDAP backend by utilizing sasl-browserid.
- This will not eliminate passwords from LDAP. Someone figure that part out, please.
- This plugin doesn’t automagically convert your webapp to BrowserID. Some additional coding is required
- Technically, this is not Single Sign On, but has some of the same useful properties
- Yes, I’m happy to help you design/setup/whatever your BrowserID solution. Ping me in #identity.
- Yes, this plugin might be reusable by large organizations such as schools, businesses, and pillow fight flash mobs. Please spread the word.
- Technically sasl-browserid should work with any Cyrus SASL enabled client or server. OpenLDAP and Postfix are two known servers, are there more? Clients?
Let’s figure out what works well and where we can improve the BrowserID project. If we can do LDAP, we can do anything
* Some programming languages lack whoami bindings, search can be used to emulate this check.