How BrowserID works (in Federated Identity terms)

The point of this post is to delve a little into how BrowserID works in the context of what those of us in the Identity & Access Management (IAM) world understand as Enterprise Identity Federation. I'm NOT advocating that BrowserID be used in place of SAML (or any other Federation protocol). I'm merely trying to put on my IAM-glasses and taking a look at the flows in a BrowserID environment.

If you want a less technical, introductory view, read my previous post relating to BrowserID.

Here are the important parts of the "BrowserID dance" and how they map (roughly) to the common terms we understand in the IAM world:

• Email Address - Persona
• Relying Party - Service Provider (SP)
• Email Provider - Identity Provider (IDP)
• Web Browser - Identity Proxy (I know there's not a common definition for what an Identity proxy is but this is the closest I could think of - better suggestions welcome)

Mozilla has specific terms for each of the components, but I've used more commonly understood references to make things a little less confusing. For example, the web browser is officially the "Implementation Provider" in the BrowserID world. Mozilla uses a generic term to allow for the use of something other than a web browser as the medium for accessing an Internet service (e.g. a mobile or desktop client).

The way a relying party validates that you are the rightful owner of an email address is by validating the assertion that is presented along with it. The assertion uses proper cryptographic mechanisms and hence is fairly secure in terms of one NOT being able to generate a valid assertion without being in possession of the relevant certificate (of course, if your browser is compromised, all bets are off). The assertion is signed by the email provider (which as I've pointed out above, is the IDP in the whole scheme of things).

Sound familiar? If you have experience with Enterprise Federated Sign-On concepts, the notion of signed assertions should be second nature to you. The main difference here is that the signed assertion is stored in the browser and presented to the relying party by the browser without necessarily having to interact with the email provider (the IDP). The relying party is then expected to validate the assertion with the email provider before allowing the user access. In a typical Enterprise Federation scenario, the browser is simply a facilitator of information and interactions between the IDP and the SP.

Using Gmail as an example, the (simplified) flow to sign in to myfavefictionalsite.com (obviously not a real site) using BrowserID would go something like this:

1. Visit myfavefictionalsite.com and click "sign in with BrowserID".
2. If your browser is clueless about your Gmail email address, it will ask you for it (if it already knows about your Gmail address, skip to the next step). Once you are signed in to Gmail, the browser will do the "BrowserID dance" with Gmail to get an assertion provisioned to (stored in) your browser for your Gmail email address.
   
3. At this point, your browser knows about your Gmail account and has a valid assertion. It will pass the assertion to myfavefictionalsite.com and you will be registered (if you are a new user) and signed in (after myfavefictionalsite.com does whatever it needs to do to validate your assertion).

Sound simple? Yes, but as always, the devil is always in the details. For BrowserID to work this way, the email provider (Gmail in the example) needs to support the "BrowserID dance". Gmail does not. In fact, I don't know of any email provider that currently supports BrowserID.

This brings me to the fall-back option, which is how the prescribed demo site (http://myfavoritebeer.org/) works. BrowserID has this notion of "Secondary Identity Authorities". The email providers are known as "Primary Identity Authorities". If the email address you are trying to use belongs to a provider that does not support BrowserID, the use of a "Secondary Identity Authority" is used. At the moment, the default is browserid.org.

Mozilla states that anyone can be a "Secondary Identity Authority" if they so choose. A "Secondary Identity Authority" is supposed to hold user information (e.g. username, password, email) and also facilitate the process required to validate ownership of an email address. The typical way to do this is to send the user an email with a validation link which the user must visit. Only when the URL within the link is visited can an email address be designated as valid. In essence, a "Secondary Identity Authority" is an IDP which validates that your email address is actually "owned" by you and also signs you in.

Because there are no email providers today that support BrowserID, the only way a user can sign in using BrowserID is by using a "Secondary Identity Authority".

The best way to understand this is to try signing in to Mozilla's My FavoriteBeer demo. When you attempt to sign in, you will be asked for an email address. The demo's sign-in prompt will wait there until you check your email and click the validation link. Doing so validates your email address and the demo site will proceed to log you in.

I've tried to keep things in this post at a fairly high level in terms of technicality. If you're interested in getting your hands a little dirtier with the flows and specific interactions, the best description I've come across of how BrowserID hangs together is by Lloyd Hilaiel, who works for Mozilla and is responsible for the My FavoriteBeer demo. It's quite detailed and should give those of you interested a lot more "guts" than I have here.

Finally, my previous BrowserID post mentioned a few issues. But I've just come across a question about BrowserID in the IT Security section of StackExchange that has answers which bring up a few more more valid technical issues. Check it out if you're interested in that kind of thing.