You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jason Smith <jh...@couch.io> on 2010/07/07 09:01:55 UTC

Proper use of _users for authentication module

When is it appropriate for an authentication module to use the _users
database (or whatever it is configured to be)?

I am investigating OpenID 2.0 support. A requirent is to store a nonce
to protect against replay attacks. I am evaluating using a database to
store the nonce. (Another option is an ets table but that has it's own
issues.)

The built-in design document IIRC rejects all non-user documents. So
storing a nonce as a new document type would require changing that
policy in an unclear way.

Would it be better to create a whole new _openid database for the task?

Suggestions welcome. Thanks!

-- 
Jason Smith
Couchio Hosting

Re: Proper use of _users for authentication module

Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Jul 7, 2010 at 9:01 AM, Jason Smith <jh...@couch.io> wrote:
> When is it appropriate for an authentication module to use the _users
> database (or whatever it is configured to be)?
>
> I am investigating OpenID 2.0 support. A requirent is to store a nonce
> to protect against replay attacks. I am evaluating using a database to
> store the nonce. (Another option is an ets table but that has it's own
> issues.)
>
> The built-in design document IIRC rejects all non-user documents. So
> storing a nonce as a new document type would require changing that
> policy in an unclear way.
>
> Would it be better to create a whole new _openid database for the task?
>
> Suggestions welcome. Thanks!
>
> --
> Jason Smith
> Couchio Hosting
>

You don't need to store the nonce per user, just need to make sure
it's unique, if I remember. Why not storing it in another db ?

- benoit

Re: Proper use of _users for authentication module

Posted by Paul Bonser <mi...@gmail.com>.
On Wed, Jul 7, 2010 at 12:32 PM, J Chris Anderson <jc...@gmail.com> wrote:
>
> On Jul 7, 2010, at 12:01 AM, Jason Smith wrote:
>
>> When is it appropriate for an authentication module to use the _users
>> database (or whatever it is configured to be)?
>>
>> I am investigating OpenID 2.0 support. A requirent is to store a nonce
>> to protect against replay attacks. I am evaluating using a database to
>> store the nonce. (Another option is an ets table but that has it's own
>> issues.)
>>
>> The built-in design document IIRC rejects all non-user documents. So
>> storing a nonce as a new document type would require changing that
>> policy in an unclear way.
>
> Does it make sense to add the nonce to the existing user document? That will allow a single lookup instead of multiple lookups.

The only potential snag is that you need to store all nonces from the
last X minutes (and reject any nonces with a timestamp longer than X
minutes ago, as well as nonces which have already been used), so it
would need to maintain and trim the list as it goes.

>
>>
>> Would it be better to create a whole new _openid database for the task?
>>
>> Suggestions welcome. Thanks!
>>
>> --
>> Jason Smith
>> Couchio Hosting
>
>



-- 
Paul Bonser
http://probablyprogramming.com

Re: Proper use of _users for authentication module

Posted by J Chris Anderson <jc...@gmail.com>.
On Jul 7, 2010, at 12:01 AM, Jason Smith wrote:

> When is it appropriate for an authentication module to use the _users
> database (or whatever it is configured to be)?
> 
> I am investigating OpenID 2.0 support. A requirent is to store a nonce
> to protect against replay attacks. I am evaluating using a database to
> store the nonce. (Another option is an ets table but that has it's own
> issues.)
> 
> The built-in design document IIRC rejects all non-user documents. So
> storing a nonce as a new document type would require changing that
> policy in an unclear way.

Does it make sense to add the nonce to the existing user document? That will allow a single lookup instead of multiple lookups.

> 
> Would it be better to create a whole new _openid database for the task?
> 
> Suggestions welcome. Thanks!
> 
> -- 
> Jason Smith
> Couchio Hosting