On 2/21/11 2:51 PM, Simon Metson wrote:
Simon:
It took me awhile to grok what you're getting at ... is this the
undocumented "proxy_authentification_handler" that I see in the current
couch sources? Also, do I assume correctly that with this approach I
could bypass the _users database completely, while still using
individual database security objects to enforce access control?
Many thanks for the help,
Tim
Hi, We did some front end auth{n,z}. In our set up Couch runs behind
an
httpd reverse-proxy, which also proxies other applications. All the
applications use the front end to authenticate/authorise the request and
the front end passes a signed header (with role/group ACL's) to the back
end. James (cc'ed) added an auth handler to read these signed headers
and set the user context accordingly. This is nice because the two are
totally decoupled (which works well for our use case) and reuses our
existing auth{n,z} infrastructure.
IIRC the code is up on github, but I don't have the URL to hand
right
now...
Cheers Simon
On 21 Feb 2011, at 18:42, Timothy Shead wrote:
I'm interested in hearing about any alternatives to the current
authentication mechanisms in CouchDB. In particular, I'd like to bypass
the _users database to base authentication and access control on
existing directories of user and group information (LDAP, Kerberos, or
what-have-you). Any experience out there?
In an ideal world, I'd love to have some sort of "external auth"
mechanism that would be comparable to the current external processes,
making it possible to implement authentication logic in any language /
use whatever libraries are available. Any thoughts?
Cheers,
Tim
--
Timothy M. Shead
Sandia National Laboratories
1461, Scalable Analysis and Visualization
--
Timothy M. Shead
Sandia National Laboratories
1461, Scalable Analysis and Visualization
