Shared Code for Login Users and Management: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 5: Line 5:
==Authentication==
==Authentication==


We'll be using the minimalistic [https://browserid.org/ BrowserID].  
We'll be using the minimalistic [https://browserid.org/ BrowserID]. Essentially, by using a couple of HTTP requests--one from the client and one from the server--you are able to establish the identity of a user by their email address. This client web code is trivial to use, and the server code very easy to write.


http://accordion.lbl.gov/cgi-bin/browserid/secret
In addition, while we could create our own our verification servers, the provided ones should suit the needs of most users.


http://geneontology.svn.sourceforge.net/viewvc/geneontology/installations/browserid/secret?view=log
A small example of the functionality can be found [http://accordion.lbl.gov/cgi-bin/browserid/secret here], with the source [http://geneontology.svn.sourceforge.net/viewvc/geneontology/installations/browserid/secret?view=log here].


==Authorization==
Authorization will be handled by a JSON file/blob with the format:
{'user@emailaddress': {'application_name_1': ['permission_1', 'permission_2']}
Such a simple format in JSON makes it easy to use for local applications, as well as being relatively easy to share around in a more distributed environment.
While things like the application name and what the permissions mean are left to the program reading the file, documentation and discipline should cover ambiguities.


=Discussion points=
=Discussion points=
Here are the initial things we wanted with commentary about our current choice.


==Wish list==
==Wish list==
Line 21: Line 32:


Also, we don't want to get locked into depending on a third-party for access (and neither should people downstream from us).
Also, we don't want to get locked into depending on a third-party for access (and neither should people downstream from us).
* We're a little weak here for authentication as at least some kind of web connection is needed (although a degenerate case where you embed your own verification server would be possible). Authorization would require your own network code (couch?), but fine otherwise.


===Reusable user identities===
===Reusable user identities===


A person could have a single login across multiple GO applications. Similarly, if somebody did implement their own backend server, they'd be able to use it for single identities across multiple pieces of our software (or use it as a base for their own).
A person could have a single login across multiple GO applications. Similarly, if somebody did implement their own backend server, they'd be able to use it for single identities across multiple pieces of our software (or use it as a base for their own).
* Great here.


===Simple management===
===Simple management===
Line 33: Line 48:


Question: How many roles are envisaged? I can think of three: user (can use designated apps), admin (can add/drop users, give/revoke permission to use apps) and admin (can do everything). Do we need more than that? Fewer?
Question: How many roles are envisaged? I can think of three: user (can use designated apps), admin (can add/drop users, give/revoke permission to use apps) and admin (can do everything). Do we need more than that? Fewer?
* Great here.


===Simple implementation (many languages)===
===Simple implementation (many languages)===


It would be very nice if this was not locked into a single language. This would either mean that is relatively easy and has been implemented many times with a lot of client and server libraries (like OpenID) or had a web API that makes it easy to interoperate with alien software.
It would be very nice if this was not locked into a single language. This would either mean that is relatively easy and has been implemented many times with a lot of client and server libraries (like OpenID) or had a web API that makes it easy to interoperate with alien software.
* Good here, but there will be a bunch of http client code floating around.


===Easy maintenance===
===Easy maintenance===


The simpler the implementation the better. A layer of software and a small sqlite3 database that can be easily copied = good. Multiple high-availability servers needing synchronized clocks = bad.
The simpler the implementation the better. A layer of software and a small sqlite3 database that can be easily copied = good. Multiple high-availability servers needing synchronized clocks = bad.
* We're crazy simple. However, unless you had a central server (couch?) for authorization, a networked situation could get hairy.


===One-stop shopping===
===One-stop shopping===


It would be nice to handle everything through a single unified interface (thinking about Drupal users and permissions here).
It would be nice to handle everything through a single unified interface (thinking about Drupal users and permissions here).
* Not great, as we'd have to write our own if it came to it. But again, at least it would be relatively simple and we don't have to worry too much about authentication.


==Risks==
==Risks==

Revision as of 19:36, 30 September 2011

Implementation

At this point, we've decided to go BrowserID for authentication and a standardized JSON file for authorization. While it is not an integrated solution, and some unique code will have to we written for every platform, it seems to offer the best balance of our requirements and wishlist.

Authentication

We'll be using the minimalistic BrowserID. Essentially, by using a couple of HTTP requests--one from the client and one from the server--you are able to establish the identity of a user by their email address. This client web code is trivial to use, and the server code very easy to write.

In addition, while we could create our own our verification servers, the provided ones should suit the needs of most users.

A small example of the functionality can be found here, with the source here.

Authorization

Authorization will be handled by a JSON file/blob with the format:

{'user@emailaddress': {'application_name_1': ['permission_1', 'permission_2']}

Such a simple format in JSON makes it easy to use for local applications, as well as being relatively easy to share around in a more distributed environment.

While things like the application name and what the permissions mean are left to the program reading the file, documentation and discipline should cover ambiguities.

Discussion points

Here are the initial things we wanted with commentary about our current choice.

Wish list

Interchangeable backends

An implementation should have the ability to run off of the local filesystem (for a smaller group sized app) or communicate with a remote third-party server. To some extent, the former may be more important.

Also, we don't want to get locked into depending on a third-party for access (and neither should people downstream from us).

  • We're a little weak here for authentication as at least some kind of web connection is needed (although a degenerate case where you embed your own verification server would be possible). Authorization would require your own network code (couch?), but fine otherwise.

Reusable user identities

A person could have a single login across multiple GO applications. Similarly, if somebody did implement their own backend server, they'd be able to use it for single identities across multiple pieces of our software (or use it as a base for their own).

  • Great here.

Simple management

It would be nice if there was an easy easy to add and drop users, as well as control what permissions they had for applications that used this system.

Also, role-based users would be a good way to handle application permissions.

Question: How many roles are envisaged? I can think of three: user (can use designated apps), admin (can add/drop users, give/revoke permission to use apps) and admin (can do everything). Do we need more than that? Fewer?

  • Great here.

Simple implementation (many languages)

It would be very nice if this was not locked into a single language. This would either mean that is relatively easy and has been implemented many times with a lot of client and server libraries (like OpenID) or had a web API that makes it easy to interoperate with alien software.

  • Good here, but there will be a bunch of http client code floating around.

Easy maintenance

The simpler the implementation the better. A layer of software and a small sqlite3 database that can be easily copied = good. Multiple high-availability servers needing synchronized clocks = bad.

  • We're crazy simple. However, unless you had a central server (couch?) for authorization, a networked situation could get hairy.

One-stop shopping

It would be nice to handle everything through a single unified interface (thinking about Drupal users and permissions here).

  • Not great, as we'd have to write our own if it came to it. But again, at least it would be relatively simple and we don't have to worry too much about authentication.

Risks

Things that we're particularly worried about in an implementation.

Accidental exposure

This would cover things like web crawlers somehow finding an "erase all" link

Hacking

I think in general we're not super worried about security (for example, a man in the middle after login was something that got a lot of shrugs), but want the general bases covered. As we're not security experts, reusing a tested stack by somebody else would be nice.

Other practical concerns

We're not super happy about running and maintaining a database for logins. But this can be punted for now as we want local use and the immediate applications are of such small scope.

Packages considered

Login/Authentication Roles/Auth Notes
OpenID OAuth Unsure how to tie together and handle management. Running our own OpenId server we could have local control of sign-on but also allow entry from other OpenId providers (eg, Google). We would then not be dependent on a 3rd party but would have the convenience of the 3rd party for people who are already signed on from said 3rd party. There are implementations in numerous languages of both the server and client. My reading of OAuth seems like it's intended for different servers to exchange data without forcing the User to sign onto both. It could could probably be used for role regulation, but might be overkill.
Drupal Seems heavy when all we would want is the user code
LDAP ...
Stanford WebAuth Cookie-based; open source; requires Apache and Kerberos or LDAP
Central Authentication Service Enterprise level single sign-on; open source; java server and client libraries for Apache, Drupal, Java, PAM, PHP, Perl, Ruby, etc.

Consumers

  • GOLD database administration
  • TermGenie