Authentication Question

[Paul Hirst <pa...@sophos.com>]

Hi, I've been trying to read around this on the web but I just can't find an answer which makes sense to me.

I would like to build a couch app and I would like to use an existing system to do the authentication. I can build an interface on this other system to do whatever is required to make this work (eg some REST thing issue cookies or validate username/password) but I can't see how I would make couch use this interface.

If I can avoid it I'd rather not have users really exist in the _users database but if this is unavoidable maybe I could create them on the fly?

I know I've been vague but can anyone offer a starting point?

________________________________
Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.

RE: Authentication Question

[Paul Hirst <pa...@sophos.com>]

>>> You could enable the proxy authentication handler;

>> 1. The roles don't appear to be included in the Token so how are they
>> validated? It sounds like the client could send whatever it liked? Only
>> the username is included in the token calculation.

> Why would youneed to validate roles? your app pass roles to couch, if
> they exists in db acls or validate functionserfect, if not who care?
>

I was going to use roles in a validate function to check who was allowed
to write to the database. This would mean I could tie it into the roles
which exist on the existing system. However it seems I can't do that
since they aren't validated. For example, a user could get told
about the following headers from the authentication server. Eg:

Username: bob
Roles: user
Token: <some opaque string>

It could then talk to the couchdb server using

Username: bob
Roles: _admin
Token: <same opaque string>

The couch server would validate the Username against the Token and
believe everything is fine but the user has gained admin rights they
shouldn't have.

I think for my purposes I can distil all real users down to the same couch
username and use that in validation functions and ignore roles entirely
but it seems a bit of a shame.

Thanks for the suggestions. At least I think I can press on now with
what I was trying to achieve.

Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.

Re: Authentication Question

[Benoit Chesneau <bc...@gmail.com>]

On Wednesday, October 19, 2011, Paul Hirst <pa...@sophos.com> wrote:
>> -----Original Message-----
>> From: Robert Newson [mailto:rnewson@apache.org]
>> Sent: 19 October 2011 11:04
>> To: user@couchdb.apache.org
>> Subject: Re: Authentication Question
>>
>> You could enable the proxy authentication handler;
>
> [snip]
>
> I read about that but it wasn't clear to me how I could use it. Maybe if I
go through how I imagine it someone will tell me where I have got it wrong.
>
> Assuming I have a pre-existing system which has the concept of sessions
using cookies and has it's own login page.
>
> First make an Ajax request to that system requesting the three headers I
need to send to couch (ie X-Auth-CouchDB-UserName, X-Auth-CouchDB-Roles and
most importantly X-Auth-CouchDB-Token). The token can be generated using the
same secret key which has been configured on the couch server.
>
> This request could somehow send the user to the login page if they aren't
already logged in. If they have a pre-existing session it can just return
the appropriate information.
>
> From then on I can make Ajax requests to the couch server and provided I
manually send the three headers each time, the couch server can authenticate
me and I can use the userCtx role information in validation function to
prevent unauthenticated writes.
>
> What I don't understand (or find odd) is:
>
> 1. The roles don't appear to be included in the Token so how are they
validated? It sounds like the client could send whatever it liked? Only the
username is included in the token calculation.
> 2. How do I get round cross domain problems for the initial step of 'get
me the 3 headers I need'? I have some thoughts on how to do this but if
there are any good suggestions I'd love to hear them.
> 3. I have to send the headers every time round. Is there any way of
requesting a cookie from couch using these credentials or should I just not
be lazy?
>
> I'm most worried about #1.

Why would youneed to validate roles? your app pass roles to couch, if they
exists in db acls or validate functionserfect, if not who care?

-be,oît




>
> Thanks.
>
> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP,
United Kingdom.
> Company Reg No 2096520. VAT Reg No GB 991 2418 08.
>

RE: Authentication Question

[Paul Hirst <pa...@sophos.com>]

> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 19 October 2011 11:04
> To: user@couchdb.apache.org
> Subject: Re: Authentication Question
>
> You could enable the proxy authentication handler;

[snip]

I read about that but it wasn't clear to me how I could use it. Maybe if I go through how I imagine it someone will tell me where I have got it wrong.

Assuming I have a pre-existing system which has the concept of sessions using cookies and has it's own login page.

First make an Ajax request to that system requesting the three headers I need to send to couch (ie X-Auth-CouchDB-UserName, X-Auth-CouchDB-Roles and most importantly X-Auth-CouchDB-Token). The token can be generated using the same secret key which has been configured on the couch server.

This request could somehow send the user to the login page if they aren't already logged in. If they have a pre-existing session it can just return the appropriate information.

>From then on I can make Ajax requests to the couch server and provided I manually send the three headers each time, the couch server can authenticate me and I can use the userCtx role information in validation function to prevent unauthenticated writes.

What I don't understand (or find odd) is:

1. The roles don't appear to be included in the Token so how are they validated? It sounds like the client could send whatever it liked? Only the username is included in the token calculation.
2. How do I get round cross domain problems for the initial step of 'get me the 3 headers I need'? I have some thoughts on how to do this but if there are any good suggestions I'd love to hear them.
3. I have to send the headers every time round. Is there any way of requesting a cookie from couch using these credentials or should I just not be lazy?

I'm most worried about #1.

Thanks.

Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 991 2418 08.

Re: Authentication Question

[Robert Newson <rn...@apache.org>]

You could enable the proxy authentication handler;

%% @doc proxy auth handler.
%
% This handler allows creation of a userCtx object from a user
authenticated remotly.
% The client just pass specific headers to CouchDB and the handler
create the userCtx.
% Headers  name can be defined in local.ini. By thefault they are :
%
%   * X-Auth-CouchDB-UserName : contain the username, (x_auth_username in
%   couch_httpd_auth section)
%   * X-Auth-CouchDB-Roles : contain the user roles, list of roles
separated by a
%   comma (x_auth_roles in couch_httpd_auth section)
%   * X-Auth-CouchDB-Token : token to authenticate the authorization
(x_auth_token
%   in couch_httpd_auth section). This token is an hmac-sha1 created
from secret key
%   and username. The secret key should be the same in the client and
couchdb node. s
%   ecret key is the secret key in couch_httpd_auth section of ini.
This token is optional
%   if value of proxy_use_secret key in couch_httpd_auth section of
ini isn't true.
%

Add {couch_httpd_auth, proxy_authentification_handler} to [httpd]
authentication_handlers. And, yes, it's really called
authentification. I assume an ancient typo or possibly a hilarious
in-joke.

B.


On 19 October 2011 11:08, CGS <cg...@gmail.com> wrote:
> I think you can start by deploying your DB files in directories protected by
> password (https) and use redirection in your server. Never tried it.
>
> Cheers,
> CGS
>
>
>
> On 10/19/2011 11:59 AM, Paul Hirst wrote:
>>
>> Hi, I've been trying to read around this on the web but I just can't find
>> an answer which makes sense to me.
>>
>> I would like to build a couch app and I would like to use an existing
>> system to do the authentication. I can build an interface on this other
>> system to do whatever is required to make this work (eg some REST thing
>> issue cookies or validate username/password) but I can't see how I would
>> make couch use this interface.
>>
>> If I can avoid it I'd rather not have users really exist in the _users
>> database but if this is unavoidable maybe I could create them on the fly?
>>
>> I know I've been vague but can anyone offer a starting point?
>>
>> ________________________________
>> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP,
>> United Kingdom.
>> Company Reg No 2096520. VAT Reg No GB 991 2418 08.
>>
>
>

Re: Authentication Question

[CGS <cg...@gmail.com>]

I think you can start by deploying your DB files in directories 
protected by password (https) and use redirection in your server. Never 
tried it.

Cheers,
CGS



On 10/19/2011 11:59 AM, Paul Hirst wrote:
> Hi, I've been trying to read around this on the web but I just can't find an answer which makes sense to me.
>
> I would like to build a couch app and I would like to use an existing system to do the authentication. I can build an interface on this other system to do whatever is required to make this work (eg some REST thing issue cookies or validate username/password) but I can't see how I would make couch use this interface.
>
> If I can avoid it I'd rather not have users really exist in the _users database but if this is unavoidable maybe I could create them on the fly?
>
> I know I've been vague but can anyone offer a starting point?
>
> ________________________________
> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
> Company Reg No 2096520. VAT Reg No GB 991 2418 08.
>

Re: Authentication Question

[Ido Ran <id...@gmail.com>]

Hi Marcus,

Sounds like you really solve the login via 3rd party cleanly.
Can you please refere me to some code or document explain it in more
details?
Also, is it possible to extend such solution to use CouchDB replication?

Thank you,
Ido

On Thu, Oct 20, 2011 at 4:55 AM, Wordit <wo...@gmail.com> wrote:

> On Wed, Oct 19, 2011 at 11:59 AM, Paul Hirst <pa...@sophos.com>
> wrote:
> >
> > If I can avoid it I'd rather not have users really exist in the _users
> database but if this is unavoidable maybe I could create them on the fly?
>
>
> Paul, I added users with existing logins to a couch db as needed. The
> existing system in my case was to use OpenID (and Facebook) logins,
> but the principal is the same.
>
> Authentication goes via another system, which talks to the third party
> login systems and then to the couch. It adds users to the couch as
> needed. Passwords are auto-generated and saved in an admin-only couch
> db.
>
> The neat thing being that even if anybody compromises the couch, the
> passwords are useless outside of this application. The actual login
> info the user enters is elsewhere, and the couch has no access to
> those systems (in this case being OpenIDs they are kept by Google,
> Yahoo, myOpenID etc).
>
> Once authenticated, the user is automatically logged in to the couch
> by getting the login details of the user's couch account, which it
> created earlier, and which is kept in a couch db. The _users db is
> also used, but users cannot login directly because they do not know
> the password which is stored in an admin-only db.
>
> The external authentication system sends info to the browser so the
> user can be logged in to the couch, with a cookie token. However, it
> never trusts the browser. All the browser sends over is the username
> of the user logged into the couch. Authentication is rechecked each
> time, which is easy and occurs without further user intervention.
> Users only do one login per session with their existing account. You
> can set a short-term session cookie or let the authentication system
> do its thing each time.
>
> Sounds a bit complicated and it was due the same-domain-policy issues
> (the elegant solution being PostMessage). It is rather good though
> because it gives you full control over the data and authentication.
>
> HTH,
>
> Marcus
>

Re: Authentication Question

[Wordit <wo...@gmail.com>]

On Wed, Oct 19, 2011 at 11:59 AM, Paul Hirst <pa...@sophos.com> wrote:
>
> If I can avoid it I'd rather not have users really exist in the _users database but if this is unavoidable maybe I could create them on the fly?


Paul, I added users with existing logins to a couch db as needed. The
existing system in my case was to use OpenID (and Facebook) logins,
but the principal is the same.

Authentication goes via another system, which talks to the third party
login systems and then to the couch. It adds users to the couch as
needed. Passwords are auto-generated and saved in an admin-only couch
db.

The neat thing being that even if anybody compromises the couch, the
passwords are useless outside of this application. The actual login
info the user enters is elsewhere, and the couch has no access to
those systems (in this case being OpenIDs they are kept by Google,
Yahoo, myOpenID etc).

Once authenticated, the user is automatically logged in to the couch
by getting the login details of the user's couch account, which it
created earlier, and which is kept in a couch db. The _users db is
also used, but users cannot login directly because they do not know
the password which is stored in an admin-only db.

The external authentication system sends info to the browser so the
user can be logged in to the couch, with a cookie token. However, it
never trusts the browser. All the browser sends over is the username
of the user logged into the couch. Authentication is rechecked each
time, which is easy and occurs without further user intervention.
Users only do one login per session with their existing account. You
can set a short-term session cookie or let the authentication system
do its thing each time.

Sounds a bit complicated and it was due the same-domain-policy issues
(the elegant solution being PostMessage). It is rather good though
because it gives you full control over the data and authentication.

HTH,

Marcus