couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suraj Kumar <suraj.ku...@inmobi.com>
Subject Re: LDAP Auth strategy using nginx
Date Tue, 21 Jan 2014 13:34:49 GMT
On further reading of the CouchDB documentation, I figured the /_session
API is the nearest to what we want. So, we're going to completely NOT write
the middle ware and just use the /_session API.


On Tue, Jan 21, 2014 at 5:12 PM, Stefan Klein <st.fankl.in@gmail.com> wrote:

> 2014/1/21 Suraj Kumar <suraj.kumar@inmobi.com>
>
> > Hi,
> >
> > We use nginx as a load balancing proxy in front of couchdb and let our
> > clients directly talk REST with couchdb. We have a company standard
> "LDAP"
> > server to auth against. I've tried (and given up) setting up the ldap
> auth
> > plugin for couchdb. Here is our alternate strategy to get things going:
> >
> > 1. Clients will attempt auth on a specific route (ex: /auth). This is
> > routed by nginx to a middleware which, after auth against LDAP, may
> insert
> > / update the couchdb _users DB with similar user account.
> > 2. The middle ware also returns a "session" cookie that is nothing but
> > crypt("username:password", "myserversecret").
> > 3. On nginx side, we write a 'lua' module that decrypts the session
> cookie
> > using the same shared  "myserversecret" password. This module will fill
> in
> > the http basic Authorization header. Since nginx is routing to couchDB
> too,
> > I expect auth against couch to work transparently.
> >
> > What do you think about this approach?
> >
> >
> Hi,
>
> from my understanding (played around with it, but not in production yet)
> you don't need to create the users in the DB.
> You could just use "Proxy Authentication"*
>
> http://docs.couchdb.org/en/latest/api/server/authn.html#proxy-authentication
> So your nginx proxy just has to set some extra headers and couchdb will
> trust it completely without further validation.
> If your middle ware i able to provide all needed information about the
> users (i.e. roles) proxy authentication might be an option.
>
> regards,
> Stefan
>
> * beware, there was/is a typo in the documentation, the
> "proxy_authentication_handler" is actualy called
> "proxy_authenti*fi*cation_handler"
> not sure if it is fixed yet, so if it doesn't work try both spellings.
>



-- 
An Onion is the Onion skin and the Onion under the skin until the Onion
Skin without any Onion underneath.

-- 
_____________________________________________________________
The information contained in this communication is intended solely for the 
use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally privileged 
information. If you are not the intended recipient you are hereby notified 
that any disclosure, copying, distribution or taking any action in reliance 
on the contents of this information is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify 
us immediately by responding to this email and then delete it from your 
system. The firm is neither liable for the proper and complete transmission 
of the information contained in this communication nor for any delay in its 
receipt.

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