You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Tiago Freire <ti...@gmail.com> on 2010/09/06 15:39:46 UTC
Best performing login implementation?
Hi all,
I am starting to work with a Tornado+Python+CouchBD backend for our company
system. We currently have an old and crufty Apache+PHP+PostgreSQL system,
which we want to move into something better.
While there's nothing wrong with the LAPP stack, the code base has many very
old parts, and is not very consistent, as it evolved through several web
technology iterations. It is too time-consuming from the maintenance
perspective. We want to scale it better, and the document-based paradigm
seems to fit our needs of storing flexible documentation better than SQL.
I want to start at the beginning, which are the logins and various
permission levels. About logins, I am thinking of having just
username+password tuples stored in one place, and the contact information
separated, to make it as fast as possible, as we may potentially have
several thousand login credentials. I am wondering about the best method for
implementing this.
1) Each username+login in a document.
2) One document for username+logins, each one in a separate property.
{username:password}
3) One document for username+logins, all in a single 'logins' array.
{logins: [{username:foo, password: bar}]}
I would like some insight on the performance implications of each of the
three options, if you have some.
If no one knows, a few directions on how to benchmark CouchDB performance
would be appreciated too.
Best regards
--
-----
Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
Re: Best performing login implementation?
Posted by Wout Mertens <wo...@gmail.com>.
Flexible, granular per-document permissions are slow :-) So you have to implement a middle layer yourself that does the authorization as befitting you and talks to CouchDB.
Wout.
On Sep 6, 2010, at 19:34 , Tiago Freire wrote:
> It's a mix, and additionally there are specific documents from each client
> which may be shared with one or more of the other users, or even made
> public, but that's casa-by-case. Flexible, granular per-document permissions
> are needed.
>
> On Mon, Sep 6, 2010 at 2:21 PM, Wout Mertens <wo...@gmail.com> wrote:
>
>> If you store confidential information, they can be in 2 categories
>> 1. data the user has to be able to read
>> 2. data only you have to be able to read
>>
>> So if it is category 1, simply add a database for that data (remember, many
>> databases per couchdb server) and add only the user to the readers.
>>
>> If it is category 2, put all that confidential data in a database and add
>> only your server user to the readers.
>>
>> If it's a mix, implement 2 and expose some of the info through your server
>> scripts for the user to use. I wonder if you can use the CouchDB
>> authentication in that case though :-/
>>
>> Wout.
>>
>> On Sep 6, 2010, at 19:15 , Tiago Freire wrote:
>>
>>> 'Users can read the entire database' is a big no-no for our design. We
>> store
>>> confidential information from our clients an they cannot see each others'
>>> stuff.
>>> Now, the 'everyone-can-read' model is all the CouchDB authentication
>> system
>>> offers, or it is just a default, and I can restrict reading using the
>>> default authentication scheme?
>>>
>>>
>>> On Mon, Sep 6, 2010 at 1:38 PM, J Chris Anderson <jc...@apache.org>
>> wrote:
>>>
>>>>
>>>> On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
>>>>
>>>>> On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
>>>>>
>>>>>> Also it is worth noting that CouchDB has a builtin authentication
>> system
>>>> that gets this right, and you might just be able to piggyback on it,
>>>> depending on your application:
>>>>>>
>>>>>>
>>>>
>> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
>>>>>
>>>>> So the security model is:
>>>>> - Admins can do everything on all local databases
>>>>> - Readers can read the entire database
>>>>> - Writes can have any model you like with validation functions
>>>>>
>>>>> So if you want to segment your database readers you have to segment
>> your
>>>> databases.
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>> Furthermore, if you would like to use LDAP authentication, you'd have
>> to
>>>> use an LDAP-to-OAuth server.
>>>>>
>>>>
>>>> It should be a very simple patch to add new Erlang authentication
>> handlers
>>>> for things like LDAP, Kerberos, etc. That might be simpler than adding a
>>>> bunch of glue to speak OAuth.
>>>>
>>>>> Correct?
>>>>>
>>>>> Wout.
>>>>
>>>>
>>>
>>>
>>> --
>>> -----
>>> Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
>>
>>
>
>
> --
> -----
> Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
Re: Best performing login implementation?
Posted by J Chris Anderson <jc...@apache.org>.
On Sep 6, 2010, at 11:07 AM, Dmitry Yakimov wrote:
> On 06.09.2010 21:34, Tiago Freire wrote:
>> It's a mix, and additionally there are specific documents from each client
>> which may be shared with one or more of the other users, or even made
>> public, but that's casa-by-case. Flexible, granular per-document permissions
>> are needed.
>
> I need it as well. Do developers plan to add something like this?
>
No plans to add this, for lots of good reasons that have been discussed already.
Chris
> Best Regards,
> Dmitry Yakimov
Re: Best performing login implementation?
Posted by Dmitry Yakimov <su...@activekitten.com>.
On 06.09.2010 21:34, Tiago Freire wrote:
> It's a mix, and additionally there are specific documents from each client
> which may be shared with one or more of the other users, or even made
> public, but that's casa-by-case. Flexible, granular per-document permissions
> are needed.
I need it as well. Do developers plan to add something like this?
Best Regards,
Dmitry Yakimov
Re: Best performing login implementation?
Posted by Tiago Freire <ti...@gmail.com>.
It's a mix, and additionally there are specific documents from each client
which may be shared with one or more of the other users, or even made
public, but that's casa-by-case. Flexible, granular per-document permissions
are needed.
On Mon, Sep 6, 2010 at 2:21 PM, Wout Mertens <wo...@gmail.com> wrote:
> If you store confidential information, they can be in 2 categories
> 1. data the user has to be able to read
> 2. data only you have to be able to read
>
> So if it is category 1, simply add a database for that data (remember, many
> databases per couchdb server) and add only the user to the readers.
>
> If it is category 2, put all that confidential data in a database and add
> only your server user to the readers.
>
> If it's a mix, implement 2 and expose some of the info through your server
> scripts for the user to use. I wonder if you can use the CouchDB
> authentication in that case though :-/
>
> Wout.
>
> On Sep 6, 2010, at 19:15 , Tiago Freire wrote:
>
> > 'Users can read the entire database' is a big no-no for our design. We
> store
> > confidential information from our clients an they cannot see each others'
> > stuff.
> > Now, the 'everyone-can-read' model is all the CouchDB authentication
> system
> > offers, or it is just a default, and I can restrict reading using the
> > default authentication scheme?
> >
> >
> > On Mon, Sep 6, 2010 at 1:38 PM, J Chris Anderson <jc...@apache.org>
> wrote:
> >
> >>
> >> On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
> >>
> >>> On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
> >>>
> >>>> Also it is worth noting that CouchDB has a builtin authentication
> system
> >> that gets this right, and you might just be able to piggyback on it,
> >> depending on your application:
> >>>>
> >>>>
> >>
> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
> >>>
> >>> So the security model is:
> >>> - Admins can do everything on all local databases
> >>> - Readers can read the entire database
> >>> - Writes can have any model you like with validation functions
> >>>
> >>> So if you want to segment your database readers you have to segment
> your
> >> databases.
> >>>
> >>
> >> Yes.
> >>
> >>> Furthermore, if you would like to use LDAP authentication, you'd have
> to
> >> use an LDAP-to-OAuth server.
> >>>
> >>
> >> It should be a very simple patch to add new Erlang authentication
> handlers
> >> for things like LDAP, Kerberos, etc. That might be simpler than adding a
> >> bunch of glue to speak OAuth.
> >>
> >>> Correct?
> >>>
> >>> Wout.
> >>
> >>
> >
> >
> > --
> > -----
> > Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
>
>
--
-----
Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
Re: Best performing login implementation?
Posted by Wout Mertens <wo...@gmail.com>.
If you store confidential information, they can be in 2 categories
1. data the user has to be able to read
2. data only you have to be able to read
So if it is category 1, simply add a database for that data (remember, many databases per couchdb server) and add only the user to the readers.
If it is category 2, put all that confidential data in a database and add only your server user to the readers.
If it's a mix, implement 2 and expose some of the info through your server scripts for the user to use. I wonder if you can use the CouchDB authentication in that case though :-/
Wout.
On Sep 6, 2010, at 19:15 , Tiago Freire wrote:
> 'Users can read the entire database' is a big no-no for our design. We store
> confidential information from our clients an they cannot see each others'
> stuff.
> Now, the 'everyone-can-read' model is all the CouchDB authentication system
> offers, or it is just a default, and I can restrict reading using the
> default authentication scheme?
>
>
> On Mon, Sep 6, 2010 at 1:38 PM, J Chris Anderson <jc...@apache.org> wrote:
>
>>
>> On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
>>
>>> On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
>>>
>>>> Also it is worth noting that CouchDB has a builtin authentication system
>> that gets this right, and you might just be able to piggyback on it,
>> depending on your application:
>>>>
>>>>
>> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
>>>
>>> So the security model is:
>>> - Admins can do everything on all local databases
>>> - Readers can read the entire database
>>> - Writes can have any model you like with validation functions
>>>
>>> So if you want to segment your database readers you have to segment your
>> databases.
>>>
>>
>> Yes.
>>
>>> Furthermore, if you would like to use LDAP authentication, you'd have to
>> use an LDAP-to-OAuth server.
>>>
>>
>> It should be a very simple patch to add new Erlang authentication handlers
>> for things like LDAP, Kerberos, etc. That might be simpler than adding a
>> bunch of glue to speak OAuth.
>>
>>> Correct?
>>>
>>> Wout.
>>
>>
>
>
> --
> -----
> Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
Re: Best performing login implementation?
Posted by Tiago Freire <ti...@gmail.com>.
'Users can read the entire database' is a big no-no for our design. We store
confidential information from our clients an they cannot see each others'
stuff.
Now, the 'everyone-can-read' model is all the CouchDB authentication system
offers, or it is just a default, and I can restrict reading using the
default authentication scheme?
On Mon, Sep 6, 2010 at 1:38 PM, J Chris Anderson <jc...@apache.org> wrote:
>
> On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
>
> > On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
> >
> >> Also it is worth noting that CouchDB has a builtin authentication system
> that gets this right, and you might just be able to piggyback on it,
> depending on your application:
> >>
> >>
> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
> >
> > So the security model is:
> > - Admins can do everything on all local databases
> > - Readers can read the entire database
> > - Writes can have any model you like with validation functions
> >
> > So if you want to segment your database readers you have to segment your
> databases.
> >
>
> Yes.
>
> > Furthermore, if you would like to use LDAP authentication, you'd have to
> use an LDAP-to-OAuth server.
> >
>
> It should be a very simple patch to add new Erlang authentication handlers
> for things like LDAP, Kerberos, etc. That might be simpler than adding a
> bunch of glue to speak OAuth.
>
> > Correct?
> >
> > Wout.
>
>
--
-----
Tiago Mikhael Pastorello Freire a.k.a. Brazilian Joe
Re: Best performing login implementation?
Posted by J Chris Anderson <jc...@apache.org>.
On Sep 6, 2010, at 8:50 AM, Wout Mertens wrote:
> On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
>
>> Also it is worth noting that CouchDB has a builtin authentication system that gets this right, and you might just be able to piggyback on it, depending on your application:
>>
>> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
>
> So the security model is:
> - Admins can do everything on all local databases
> - Readers can read the entire database
> - Writes can have any model you like with validation functions
>
> So if you want to segment your database readers you have to segment your databases.
>
Yes.
> Furthermore, if you would like to use LDAP authentication, you'd have to use an LDAP-to-OAuth server.
>
It should be a very simple patch to add new Erlang authentication handlers for things like LDAP, Kerberos, etc. That might be simpler than adding a bunch of glue to speak OAuth.
> Correct?
>
> Wout.
Re: Best performing login implementation?
Posted by Wout Mertens <wo...@gmail.com>.
On Sep 6, 2010, at 17:24 , J Chris Anderson wrote:
> Also it is worth noting that CouchDB has a builtin authentication system that gets this right, and you might just be able to piggyback on it, depending on your application:
>
> http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
So the security model is:
- Admins can do everything on all local databases
- Readers can read the entire database
- Writes can have any model you like with validation functions
So if you want to segment your database readers you have to segment your databases.
Furthermore, if you would like to use LDAP authentication, you'd have to use an LDAP-to-OAuth server.
Correct?
Wout.
Re: Best performing login implementation?
Posted by J Chris Anderson <jc...@apache.org>.
On Sep 6, 2010, at 8:10 AM, Matt Goodall wrote:
> On 6 September 2010 15:18, Wout Mertens <wo...@gmail.com> wrote:
>
>>
>> On Sep 6, 2010, at 15:39 , Tiago Freire wrote:
>>
>>> I am wondering about the best method for
>>> implementing this.
>>>
>>> 1) Each username+login in a document.
>>> 2) One document for username+logins, each one in a separate property.
>>> {username:password}
>>> 3) One document for username+logins, all in a single 'logins' array.
>>> {logins: [{username:foo, password: bar}]}
>>
>> From general principle, 1) is the one you want. I haven't set up user auth
>> myself, but in document-oriented databases you want to keep your data
>> together in logical units that have a practical maximum size.
>>
>> So while, in a way, all your logins are a logical unit, there is no limit
>> on how large that array will get so that is not a good way to store that
>> information.
>>
>>
> I'd go for one document per username+login. Don't be shy about throwing in
> lots of other information about the user unless it really doesn't make sense
> to store it in the same document for some reason. Your view can emit just
> the username and password to keep the authentication request fast:
>
> function(doc) {
> if(doc.type == 'user') {
> emit(doc.username, doc.password);
> }
> }
>
Also, please do not store plain text passwords. Read this:
http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Also it is worth noting that CouchDB has a builtin authentication system that gets this right, and you might just be able to piggyback on it, depending on your application:
http://blog.couch.io/post/1027100082/whats-new-in-couchdb-1-0-part-4-securityn-stuff
If you decide to roll your own, I agree that a document-per-user is a good approach.
Chris
> The other thing to consider when designing your documents is who will be
> updating them and how often. Ideally, you only want updates to come from one
> person to avoid conflicts. If you put all username+password in a single
> document then as the number of users grows you're increasingly likely to get
> conflicts, e.g. whenever someone tries to change their password.
>
> - Matt
Re: Best performing login implementation?
Posted by Matt Goodall <ma...@gmail.com>.
On 6 September 2010 15:18, Wout Mertens <wo...@gmail.com> wrote:
>
> On Sep 6, 2010, at 15:39 , Tiago Freire wrote:
>
> > I am wondering about the best method for
> > implementing this.
> >
> > 1) Each username+login in a document.
> > 2) One document for username+logins, each one in a separate property.
> > {username:password}
> > 3) One document for username+logins, all in a single 'logins' array.
> > {logins: [{username:foo, password: bar}]}
>
> From general principle, 1) is the one you want. I haven't set up user auth
> myself, but in document-oriented databases you want to keep your data
> together in logical units that have a practical maximum size.
>
> So while, in a way, all your logins are a logical unit, there is no limit
> on how large that array will get so that is not a good way to store that
> information.
>
>
I'd go for one document per username+login. Don't be shy about throwing in
lots of other information about the user unless it really doesn't make sense
to store it in the same document for some reason. Your view can emit just
the username and password to keep the authentication request fast:
function(doc) {
if(doc.type == 'user') {
emit(doc.username, doc.password);
}
}
The other thing to consider when designing your documents is who will be
updating them and how often. Ideally, you only want updates to come from one
person to avoid conflicts. If you put all username+password in a single
document then as the number of users grows you're increasingly likely to get
conflicts, e.g. whenever someone tries to change their password.
- Matt
Re: Best performing login implementation?
Posted by Wout Mertens <wo...@gmail.com>.
On Sep 6, 2010, at 15:39 , Tiago Freire wrote:
> I am wondering about the best method for
> implementing this.
>
> 1) Each username+login in a document.
> 2) One document for username+logins, each one in a separate property.
> {username:password}
> 3) One document for username+logins, all in a single 'logins' array.
> {logins: [{username:foo, password: bar}]}
From general principle, 1) is the one you want. I haven't set up user auth myself, but in document-oriented databases you want to keep your data together in logical units that have a practical maximum size.
So while, in a way, all your logins are a logical unit, there is no limit on how large that array will get so that is not a good way to store that information.
Wout.