Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (google.com: domain of rnewson@apache.org designates
 10.50.153.234 as permitted sender) client-ip=10.50.153.234;
MIME-Version: 1.0
In-Reply-To: <1EBEDCD2-6239-40B6-9C1F-EF95FF100854@gmail.com>
References: <DF714ABC-F4EB-40D4-B2AF-6CBECE863B84@gmail.com>
	<CAJ_m3YC-P4DJzcWeo1UPoKwZV_1dfbPShGXFchko7MEnX16cuw@mail.gmail.com>
	<1EBEDCD2-6239-40B6-9C1F-EF95FF100854@gmail.com>
Date: Thu, 23 Feb 2012 19:07:34 +0000
Message-ID: 
 <CABvT1DHbU0kue-nuxwWa6CVXau5Qv91Y5t+qC7Ha-oD=2tP+5A@mail.gmail.com>
Subject: Re: proxy authentication handler
From: Robert Newson <rnewson@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I certainly see value in being able to delegate authentication to an
external service. Shouldn't be difficult.

B.

On 23 February 2012 19:02, Michael Ferjancic
<michael.ferjancic@gmail.com> wrote:
> Hi Paul,
>
> thanks for the quick answer. Exactly that is what i want to do - i would =
like to use some nodejs-stuff in front to do the authentication and after a=
 successful auth-attempt =A0"trust" the session to couchdb (=3Dcreate the c=
ouch cookie)....
>
> Cheers
> Michael
>
> Am 23.02.2012 um 19:54 schrieb Paul Davis:
>
>> On Mon, Feb 13, 2012 at 3:02 PM, Michael Ferjancic
>> <michael.ferjancic@gmail.com> wrote:
>>> Hi guys,
>>>
>>> I have to admit that i am fairly new to this topic, especially new to e=
rlang. Currently i am trying to play around with the various authentication=
 handlers - goal is to have a working "delegated authentication" on faceboo=
k, twitter and such.
>>>
>>> 1) as far as i understood the oAuth implementation of couchdb is just t=
he opposite i need - you can use that to create tokens for couch-users, but=
 not to accept twitter accessTokens/secrets and map that to a couch user
>>> 2) i found exactly what i need in datacouch - authentication against tw=
itter with nodejs, and after that getting the plaintext password from a pri=
vate couch and use it with _session-API to create a couch cookie.
>>> 3) i modified the sample a little bit and used everyauth to handle the =
delegated authentication. I map the userinfos i get from facebook etc. agai=
nst user profiles in a private db, which also contains the user passwords (=
unfortunately still in plaintext). Works perfectly, but.....
>>>
>>> Now i am trying to avoid storing the plaintext passwords. I heard about=
 to use proxy_authentification_handler, but it seems i am too stupid to use=
 it. I made the (as far as i understood) correct entries in couch_httpd_aut=
h
>>>
>>> couch_httpd_auth =A0 =A0 =A0 =A0auth_cache_size
>>> 50
>>> x
>>> authentication_db
>>> _users
>>> x
>>> authentication_redirect
>>> /_utils/session.html
>>> x
>>> require_valid_user
>>> false
>>> x
>>> secret
>>> xxxxxxxxxxxx
>>> x
>>> timeout
>>> 43200
>>> x
>>> x_auth_roles
>>> roles
>>> x
>>> x_auth_token
>>> token
>>> x
>>> x_auth_username
>>> uname
>>>
>>>
>>> and also in httpd
>>> httpd =A0 allow_jsonp
>>> true
>>> x
>>> authentication_handlers
>>> {couch_httpd_auth, proxy_authentification_handler},{couch_httpd_auth, c=
ookie_authentication_handler}, {couch_httpd_auth, default_authentication_ha=
ndler}
>>> x
>>> bind_address
>>> 127.0.0.1
>>> x
>>> default_handler
>>> {couch_httpd_db, handle_request}
>>> x
>>> port
>>> 5984
>>> x
>>> secure_rewrites
>>> false
>>> x
>>> vhost_global_handlers
>>> _utils, _uuids, _session, _oauth, _users
>>>
>>> When i now do a GET on http://localhost:5984/_utils/config.html?uname=
=3Duser1&roles=3Duser that seems to doesn't lead to anything...
>>>
>>> Anybody ever got that thing running? Am i missing something? Or is ther=
e any chance to implement a custom authentication handler without coding er=
lang?
>>>
>>> Thanks for your help
>>> Michael
>>>
>>
>> I'm not super familiar with this code but AFAIK, the proxy auth module
>> is for accepting auth done by a proxy (as opposed to proxying auth to
>> an external service).
>>
>> So for instance, nginx could auth requests to some LDAP server and
>> then couchdb would trust nginx's auth passed forward. Theoretically if
>> you have your auth stuff working infront of couch you could do the
>> same thing but I'm not familiar enough to be much more help on that.
>