mozilla / persona

Persona is a secure, distributed, and easy to use identification system.

This repository contains the core Mozilla Persona services. Persona is a login system based on the BrowserID protocol.

To learn about using Persona on your site, check out our documentation on MDN.

Repository Contents

This repository contains several projects related to Persona:

• The Persona Fallback IdP: A fallback Identity Provider (IdP) for users without native support for Persona via their email provider. Written in node.js, hosted at https://login.persona.org.

• The Persona Remote Verification Service: A stateless node.js server which handles cryptographic verification of identity assertions. Hosted at verifier.login.persona.org, but easy to run locally.

• The Cross-Browser Persona Support Library: The include.js file that provides the navigator.id API for browsers without native support for Persona. This also includes the code for the dialog shown to users of those browsers.

• Sample and Test Code: For all of the above.

Getting Started

The Persona team uses Git and GitHub for all of our development and issue tracking. If you'd like to contribute code back to us, please do so using a Pull Request. If you get stuck and need help, you can find the core team on our public mailing list or in #identity on irc.mozilla.org.

Install Dependencies

BrowserID needs the following dependencies before it can run:

• node.js (>= 0.8.11)
• libgmp3
• g++

For detailed instructions for your specific operating system, check out the SETUP docs in the docs/ folder.

Running BrowserID Locally

To run the BrowserID service locally:

1. Clone the repository to your machine.
2. Run npm install from the root of your clone.
3. Run npm start from the root of your clone.

When you run npm start, it will print several URLs to your terminal. You can test that everything is working by visiting the URL for the example (RP) site. Look for a line like this in the terminal:

example (10361): running on http://127.0.0.1:10001

You can stop the services by typing Control-C in the terminal.

Staying Up to Date

To stay up to date with BrowserID:

1. Use git pull to retrieve new changes.
2. Delete both the var and node_modules folders in the root of your local clone.
3. Run npm install from the root of your local clone.

Testing

Local testing:

Unit tests can be run by invoking npm test at the top level. At present, there are three classes of unit tests to be run:

• Backend unit tests against a custom, zero-dependency JSON database.
• Backend unit tests against MySQL, what we use in production.
• Frontend unit tests run headlessly against PhantomJS.

You can control which tests are run using the WHAT_TESTS env var, see scripts/test for details.

Continuous Integration Testing:

Integration tests are done with Travis-CI. It is recommended that you setup Travis-CI for your BrowserID fork so that tests are automatically run when you push changes. This will give the BrowserID team confidence that your changes both function correctly and do not cause regressions in other parts of the code. Configuration files are already included in the repo but some setup is necessary.

1. Sign in to GitHub
2. Open Travis-CI
3. Click "Sign in with GitHub" if you are not signed in. If you are signed in, click on your username then "Profile" and go to step 5.
4. Click "Allow" if this is your first time signing in.
5. Find "browserid" in "Your Repositories"
6. Move the switch from "OFF" to "ON"
7. Open your fork of BrowserID on GitHub
8. Click the "Settings" button
9. Click "Service Hooks" and find the "Travis" Service Hook
10. Paste in your "Token" which you can find it on your Travis-CI Profile.
11. Ensure that "Travis" has a green radio button
12. Push to your fork and return to Travis-CI. Watch the tests run.

LICENSE

All source code here is available under the MPL 2.0 license, unless otherwise indicated.

persona's Issues

with two emails, the manage screen "show public key" link does the wrong thing

The first link opens up the second public key

port to express

rather than using connect, why not use express? it's a thin layer atop connect that provides additional interesting features.

login CSRF

/wsapi/authenticate should be a POST with an anti-CSRF token

make verifier service return actual values

so no need to parse in two places

twitter/facebook connect/Open ID support?

What if there were a simple experience for using popular identities, or those that don't actually use SMTP? This issue is for the exploration of how integrating first class support into BrowserID for popular networks might look.

Progress bar during id sync

key generation takes a while. user feedback is good.

change verifier to expect and verify certificates

currently the verifier checks with the issuer to ensure that the public key used to sign an assertion is owned by the user. We'll have to change this so that the verifier pulls the issuer's public key(s) and verifies that the assertion is properly signed.

use new logo on browserid.org

http://cl.ly/09153C2d0o3j0X3c3g45

contact sean if you need a higher-res/different format image

removing an email and re-adding it should require re-verification

If I go into the status page and "sign out", mentally I'm thinking "forget about this email" - maybe it should be labeled "forget" or "remove", or maybe my mental model is wrong(?)

Because I'm thinking about it as "forget", if I then go to an RP and sign in, it should a) not list that email, and b) require email verification to let me use it to sign in.

implement public key signing in browserid.org

this is the low level mechanisms to sign public keys. this must be implemented in the server, and should be sufficiently modular so that it can be packaged as a library/reference implementation for primaries.

clarify "argument" in verifier call

hostname, port, etc...

IP should check for primary support upon email addition

While the user is adding a new email, if the email is from a host who natively supports BrowserID, then the IP should query host-meta to determine the URL of the UI for that support. That UI should be embedded into the window spawned by the IP so that the user can log in.

Part of this is smoothing out the spec to which primaries will author auth code (postMessage? size? etc).

manage page: cancel link broke

This link seems to purge server based records, but not client based records.

STR:

1. setup browserid, add emails
2. go to https://browserid.org/manage.html
3. click cancel link at bottom of page
4. click ok in modal popup
5. notice that email addresses still appear on page

provide "this is not my computer" checkbox at signin

this should be done with a logout button that comes up in a popup when user doesn't check "remember me on this computer"

develop the primary pitch

We should be able to clearly explain to an entity who offers ID on the web today why supporting browserid is in their best interest, and in the interest of their users.

cert refresh when dropped in by primary

we need to work with the refresh_url

use sign-in buttons on developer instructions

tell developers that, while they can use anything they like, we'd like it if they used these:

http://cl.ly/09153C2d0o3j0X3c3g45

contact sean if you need them in some other format or whatever.

verifier.browserid.org

stand up the verifier code on verifier.browserid.org. This is a server behind strong SSL that lazy RPs can use for a simpler integration.

Consider mentioning CSRF validation steps on the server-side

I wasn't sure whether I needed to do any fancy CSRF protection when I passed the assertion from the user's browser to my server, and Ben Adida said I should. We should probably mention this in the developer guide, no?

move from eyedee.me to browserid.org

we've abused the eyedee.me domain thus far, putting the "implementation provider" and "secondary" on that domain. We should move the implementation provider and secondary onto browserid.org, and eyedee.me will be left as a domain where we can build a sample primary.

attempting to add an email that's already registered fails funny.

There are several cases where I might want to add an email address to my account that is already registered by someone else.

First, perhaps I forgot the password to my account and am re-verifying my emails as I need to use them to log in.

Next, maybe there's a shared email and I want to use it to log into some site, but my colleague (for instance) has already verified it.

At present, we let you get all the way to clicking on the link in your email before failing, at which point you get a non-obvious error message.

That's certainly bogus. In the spirit of how the rest of the system works (i.e. create new account/I forgot my password), I think for initial release we should just let you go all the way through the flow, and take ownership of the single email you're verifying.

mobile compatibility

Android and iOS. From James Burke:

Android 2.2, Firefox Mobile 4.0.1 on a 7" Galaxy Tab: no messages in
the console about a possible error. I do not see another window in the
list of browser windows either. I tried the example on browserid.org,
but seems to have the same problem. Clicking the button does not show
the browserid window.

iOS 4, Mobile Safari, on iphone: a JavaScript error in the console:
"undefined Channel.build() called without a valid window argument".

Need to present and have user agree to TOS & privacy policy

Sad, but true.

Contrast on grey 'sign in' button is way too low

On https://browserid.org/developers.html, there's a grey sign in button that's promoted for use. However, its foreground and background color have a very small contrast ratio.

Ref: http://juicystudio.com/services/luminositycontrastratio.php

The button has text in #aeaeae, and a background gradient from #9a9a9a to #757575. Even on the darkest side, that's a contrast ratio of 2.08:1, under the 3:1 minimum for big text, and way under the 4.5:1 minimum for small text, like on this button. In less analytical and more human terms, this means it's really hard / impossible to read for people with less-than-perfect eyesight.

Could this button please be replaced with a version with brighter text and/or a darker background? Thanks! :-)

implement "forgot password" flow

because it's easy to forget your password!

Implement email handshake

real email confirmation is needed once we move to production server. This will include figuring out portable UX for user feedback manifests upon clicking link in email.

navigator.id.getVerifiedEmail gives error from pages loaded using file:///

browserid returns an error saying "Payload audience does not match provided audience."

Create browserid.org site content

browserid.org should be a friendly and targeted description of the proposal: for users, for developers, and for authorities.

Port blobastorus to browserid

blobastorus is a perfect candidate for a hack that would be better with improved authentication. We should port it to browserid.

never store passwords in plaintext

there's no need to store plaintext passwords on the server. we should hash them right when they come in.

Stand up beta.browserid.org

A beta installation that will serve as a testing target for QA and house weekly trains for a week before push to production.

develop the user pitch

We should be able to clearly explain to a primary and to an end user why browserid is awesome. This should resonate with a non-technical user and should be backed up by an implemented login flow that is demonstrably better than what the web offers today.

ability to delete my account

for testing purposes, so I can demo account creation

stand up outbound email server on browserid.org

title says it all.

gravatar in login box

cause it's awesome

clear out username and password on "this is not me" click

stylize browserid dialog to match site

for a little bit of consistency and a slightly better look.

Consider mentioning the dangers of using https in Python

I'm working on a Python-based browserid auth mechanism, and realized that all the major built-in ways of doing HTTPS in Python--via httplib, urllib, and urllib2--offer no way to check the server's cert. This is terrible, and effectively means the communication occurs over HTTP.

Some searches on google yield two particularly interesting links:

• http://bugs.python.org/issue1114345
• http://stackoverflow.com/questions/1087227/validate-ssl-certificates-with-python

Anyhow, it seems doing HTTPS the right way in Python is nontrivial, so it'd be nice if we provided a bit of guidance here, so that folks don't accidentally introduce vulnerabilities into their apps.

Implement anonymous email support

Early feedback is that the possibility for value adding primaries which anonymize emails is huge. I think so to.

We should implement anonymizing email support in browserid.org (which means email forwarding, yes it does), and figure out how it would map into the fully distributed system. As well as figuring out the UX bits.

refine verification step in developer instructions

The developer instructions have a verification step written in JS. Unfortunately, many server-side hackers will assume this code is OK (or even expected to) run client-side, particularly if they don't read/skim the text above the code.

I propose a selector so you can see the same code in a few different languages (python, php, js), with the default something other than js. Maybe also call js "node js" or somesuch.

As a low bar, maybe we just rewrite the current code in python.

fix getVerifiedEmail function - error returns

getVerifiedEmail should not have a separate error function, according to the new spec:

https://wiki.mozilla.org/Identity/Verified_Email_Protocol/Latest

Complete the pitch: Why should people care about BrowserID?

BrowserID is a complicated solution to a real problem. The various actors that it affects are sufficiently different that it is important to develop and refine targeted explanations as to why BrowserID is important.

At the end of this milestone we should have concise, targeted explanations of why BrowserID is important. This excercise will also help focus and prioritize future development.

Fix whitespace in verification email

currently the email is all smashed together, double \n is collapsed into one. This is a mustache "feature" ?

Initial Manage page does not show newly auth'd email

I have no previous account or interaction with the site.

I registered an email, performed the verification, but when the verification switched to the manage page, the newly auth'd id was not listed. Refreshing the page showed the email.

Mobile Safari currently broken

some kind of window channel confusion.

sketch up a test plan for QA

a base level testing plan should be created as a starting point for QA for validating weekly pushes.

set-key CSRF

/wsapi/set-key should be a post with anti-CSRF protection

RP "Support"

Relying parties are sites that use BrowserID. In this milestone we'll take some existing sites and "upgrade" them with browserid support. In the process of building browserid support into real sites we'll be forced to think through the ease of integration and ensure the embedding APIs are sufficiently flexible to afford embedding sites freedom.

The output of this milestone will be a number of sites that use browserid, as well as excellent documentation for how to user browserid in your own site

After this milestone we'll be ready to start using browserid in various experiments and hacks.

Client should remember what ids you use

if you frequently use an identity for a site, the UI should sort that id to the top of the list and perhaps tell you (id last used for this site 4 days ago)

the data to support this ui can be automatically gathered and need never leave the client.

remove .email getter in assertion object

we'll delay the unverified email use-case until a later time, when we can propose some other API (e.g., part of a getProfile type API).