couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michiel de Jong <mich...@unhosted.org>
Subject Re: browserid support
Date Mon, 26 Dec 2011 02:51:19 GMT
there are three parts to consider:
- the javascript shim
- the verifier
- the identity provider (whether primary or secondary)

the verifier is already available as a node module. this means you could
probably also host the javascript shim yourself, although i haven't tried
this. support for primary identity providers should be coming soon (i think
they already have it in dev, but not sure), which means you can also get
rid of browserid.org as a secondary identity provider.

I think by offline you mean only the browser and your server are involved
in the exchange, and not mozilla or anyone else. It will still not be
offline in that sense then, because your verifier will have to talk to your
primary identity provider.

now there are two things a person might want to implement: an IdP (identity
provider), or an RP (relying party).

IdP means that if you have a CouchDB instance on a domain name, say
mycouch.nl, then users at that domain become valid BrowserId logins,
without the intervention of browserid.org as a secondary, and without
relying on SMTP. So john@mycouch.nl would suddenly become a valid BrowserId
identity that you can use on sites elsewhere on the web - depending on the
_users database of mycouch.nl. This is nice. Or it will be, once we get
this working. IdP reference implementation will probably become available
in node i would expect, /but/ i'm working on configuring CouchDB in such a
way that it can redirect in the proper way to such a node service. Also,
presumably the node service will have a data backend, which you could then
host on CouchDB. That is, provide a BrowserId identity for each line in
_users. This is something I am trying to do, so if you also want to do
this, then let's work together.

The other thing, CouchDB as a BrowserId RP, would simply be instead of
clicking 'login' at the bottom right in futon, there would be a BrowserId
sign in button there. This is nice because then people don't have to
remember their CouchDB password all the time. Or for that matter, their
password in whatever app uses CouchDB. This would have to be something in
front of CouchDB, which check the BrowserId assertion, and opens a session
- which may involve storing the plain text admin password and sending this
to the client, or creating a session token and staying inbetween as a
proxy, or creating a session token and adding this into the _users database
as you send it in plain text to the client. There is an interesting
situation here, which is that you presumably aren't using federated
identity in the strict sense. Probably you're not going to allow just any
email address onto your couch - only your own existing users. So that means
that even if you don't play the role of IdP, you are accepting remote
identities because of how they map to local identities. The CouchDB server
asks 'who are you'. browserid responds 'i'm john@gmail.com', and then the
CouchDB server says 'ah, hello john, i know you as local user
john@mycouch.nl, so you're welcome.' But maybe that's always the case in a
sense.

anyway, to answer your question, i think it is possible to run server-side
javascript on CouchDB, but i do not think it's a good idea to implement the
RP's verifier, nor the IdP's certifier (or whatever it's called) in that. i
would use the node module(s) that Mozilla (will) provide, and run a
combination of CouchDB and nodejs to get your stuff working.

good luck, let me know your progress!

Cheers,
Michiel

On Mon, Dec 26, 2011 at 9:19 AM, Tim Kuijsten <info@netsend.nl> wrote:

> I'd like to run an offline (so no network dependencies on mozilla)
> browserid server in couch and was wondering if anyone has this already
> accomplished. If my understanding is correct, it's only possible to run any
> server-side code in erlang and not in javascript (so unfortunately I cannot
> build it myself yet).
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message