Difference between revisions of "Persona"

From Sudo Room
Jump to navigation Jump to search
(adds use case section)
(→‎Use Case: updates statement)
Line 12: Line 12:
Our hackerspace community has an opportunity to support an environment for creative expression and new, elegant services. We have basic infrastructure including a wordpress website (with blog and shared calendar system), this mediawiki wiki, a membership application (in the works), and an issue tracker (next on deck). However, a limitation to running 2 or ''n'' services is managing more than one user account. Hackerspaces commonly write manual hacks to shim user account generation, and to propogate password updates across multiple systems. These solutions are a pain and very unstable. Persona offers a viable alternative, so at the very least we can use the same shim in each system.  
Our hackerspace community has an opportunity to support an environment for creative expression and new, elegant services. We have basic infrastructure including a wordpress website (with blog and shared calendar system), this mediawiki wiki, a membership application (in the works), and an issue tracker (next on deck). However, a limitation to running 2 or ''n'' services is managing more than one user account. Hackerspaces commonly write manual hacks to shim user account generation, and to propogate password updates across multiple systems. These solutions are a pain and very unstable. Persona offers a viable alternative, so at the very least we can use the same shim in each system.  


'''The value of doing this is creating environment where creating lots of new apps is encouraged over bottlenecking on centralized/monolithic apps, and adoption has a low barrier to entry since every user existing can authenticate without registration.'''
'''We want to create an environment where members are encourage do create lots of new apps, rather than bottlenecking on centralized/monolithic apps. With persona, these apps may have a lower barrier to entry since every user existing can authenticate without registration.'''


==Identity Provider (IdP)==
==Identity Provider (IdP)==

Revision as of 01:01, 4 May 2014

There aren't many decentralized authentication solutions out there. Namely, there are few alternatives to OpenID, and Mozilla Persona seems to be the most modern and most viable. Persona is based on the underlying BrowserID protocol. Further, Mozilla currently runs an Identity Provider (IdP) service at https://login.persona.org/ but one can run an IdP themselves, allowing for decentralization.

In terms of practical usage for sudo room, there are a sufficient number of libraries and plugins available for integrating and developing with lots of different applications and environments. This blog post from 2013 explains some more about how these libraries can be used.

As of March 7, 2014, Mozilla plans to turn Persona to Community Ownership, but not decommission the project:

"Should we ever consider decommissioning it, we will provide ample notice and a long deprecation window. This will absolutely not happen in 2014."

This is good and clear, but the future is undetermined. We should look to implement our own IdP, but for now we can bootstrap our apps with Mozilla's service to keep the overhead low as we integrate verification.

Use Case

Our hackerspace community has an opportunity to support an environment for creative expression and new, elegant services. We have basic infrastructure including a wordpress website (with blog and shared calendar system), this mediawiki wiki, a membership application (in the works), and an issue tracker (next on deck). However, a limitation to running 2 or n services is managing more than one user account. Hackerspaces commonly write manual hacks to shim user account generation, and to propogate password updates across multiple systems. These solutions are a pain and very unstable. Persona offers a viable alternative, so at the very least we can use the same shim in each system.

We want to create an environment where members are encourage do create lots of new apps, rather than bottlenecking on centralized/monolithic apps. With persona, these apps may have a lower barrier to entry since every user existing can authenticate without registration.

Identity Provider (IdP)

Verification

Interesting, there's a drop-in apache module for persona-based auth:

Implementations

WordPress

Using BrowserID plugin.

MediaWiki

Using Persona extension.

SeltzerCRM

Persona Auth Module

First-pass (not tested, development version, probably broken): https://github.com/sudoroom/seltzer/tree/persona_auth

A dead-simple verification plugin that allows users to authenticate using an email address via persona. Uses MIT-licensed verification library Auth-BrowserID and based on SeltzerCRM's User Module, both are dependencies.

pseudo code
  1. include BrowserID.php verification library class (gpl-compatible Mozilla license)
  2. create alternative Persona-based login form
  3. ensure login form shows up in the right places
  4. write handler to catch the POST login request, perform an assertion, add user id to session data, and respond in affirmative
  5. shouldn't need to write handler to catch the GET logout request, existing logout should simply clear session data
notes

Relevant sections of code: https://github.com/elplatt/seltzer/blob/master/crm/modules/user/user.inc.php#L467-L498 https://github.com/elplatt/seltzer/blob/master/crm/modules/user/user.inc.php#L623-L687

Helpful thoughts: Confirms idea of how this could work http://stackoverflow.com/a/18930982 Demonstrated hack example in php http://ubuntuforums.org/archive/index.php/t-2126891.html

Libraries: Looks like I want to use this: https://github.com/fmarier/auth-browserid namely: https://github.com/fmarier/auth-browserid/blob/master/docs/demo.php