You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Camille Harang <ma...@yooook.net> on 2011/07/18 15:23:20 UTC
OAuth for authorization (not authentication)
Hi all, as discussed yesterday on IRC, it seems that the OAuth layer of
CouchDB only covers the authentication mechanisms of OAuth, but not the
authorization mechanisms (if I understood correctly, tell me if I'm
wrong). However, the authorization layer is IMHO the most interesting
part of OAuth:
http://tools.ietf.org/html/draft-ietf-oauth-v2-18 :
Abstract
The OAuth 2.0 authorization protocol enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.
But, as it's closely related to read access limitations (in time and
scope), it doesn't fit well in the all-or-nothing ready access policy
for a given database in CouchDB. After discussion, it seems that the
proper way to do this with CouchDB is to set a DB per user and per
permission. Following the example given in the OAuth RFC, where a user
wants to grant access to his/her pictures (and only his/her pictures) to
a printing shop for a limited time (time to print), it seems that in
CouchDB we would need to set up a DB for the user's private data, and a
for the the user's pictures (and for the user's bookmarks, and so on for
each right's scope). Then we just need to grant or not read access to
this or that DB, regarding the credentials of the third party request,
but I don't know how to do this with the current ACL policy wich doesn't
seems to match the OAuth's token system (the third party request must
show a token, but how/where can I check it? How/where can I handle
token's expiration time?).
Do you think there is anyway to handle this? Or should I fallback to the
"smart proxy" solution?
Thanks,
Regards,
Camille.
--
The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
Re: OAuth for authorization (not authentication)
Posted by Camille Harang <ma...@yooook.net>.
Hi Jan, thanks a lot for your answer, even if that's what I dread :-/ I
hope I can find another way to make Couch match my needs (smart proxy
maybe). Otherwise I'll keep Couch in mind for my next project, hoping it
won't have the same requirements or if other solutions appears until
then, because Couch is such a good piece of software! I want to use it.
Thanks!
Cheers,
Camille.
Le 19/07/2011 11:20, Jan Lehnardt a écrit :
> Hi Camille,
>
> The OAuth implementation in CouchDB is very limited (due
> to constraints in the original development phase). The
> implementation does not allow fine-grained token-based
> access to specific contents of one or more databases
> inside CouchDB, but only the authentication against a
> CouchDB user in the CouchDB authentication layer. Once
> a request is auth'd, there is no more OAuth machinery
> inside CouchDB and you are left with CouchDB's security
> mechanics:
>
> http://wiki.apache.org/couchdb/Security_Features_Overview
> http://blog.couchbase.com/whats-new-in-couchdb-1-0-part-4-securityn-stuff
>
> Cheers
> Jan
--
The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
Re: OAuth for authorization (not authentication)
Posted by Jan Lehnardt <ja...@apache.org>.
Hi Camille,
The OAuth implementation in CouchDB is very limited (due
to constraints in the original development phase). The
implementation does not allow fine-grained token-based
access to specific contents of one or more databases
inside CouchDB, but only the authentication against a
CouchDB user in the CouchDB authentication layer. Once
a request is auth'd, there is no more OAuth machinery
inside CouchDB and you are left with CouchDB's security
mechanics:
http://wiki.apache.org/couchdb/Security_Features_Overview
http://blog.couchbase.com/whats-new-in-couchdb-1-0-part-4-securityn-stuff
Cheers
Jan
--
On 19 Jul 2011, at 11:07, Camille Harang wrote:
> Hi again,
>
> Le 18/07/2011 15:44, Robert Newson a écrit :
>> As also noted on IRC, you are indeed wrong,
>
> I hope I am, I really tried to find the proper way to fully implement
> OAuth authorization layer (tokens, ad hoc grant access in time and
> scope: the very essence of OAuth) within the CouchDB intrinsic
> techniques and philosophy, but I keep failing.
>
>> you just don't like the
>> granularity
>
> I don't dislike or like it, but wherever I look it just appears to me
> that there is just not enough of it to match the requirements of a
> proper implementation of OAuth. But I believe being wrong, I'm sure I
> am, I want to use Couch, can anyone point me the right direction? Once I
> know it, I will like it.
>
> Thanks,
>
> Cheers,
>
> Camille.
>
>
>> of the operation you are authorized to perform after
>> successfully authenticating. :)
>>
>> B.
>
> --
> The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
>
Re: OAuth for authorization (not authentication)
Posted by Camille Harang <ma...@yooook.net>.
Hi again,
Le 18/07/2011 15:44, Robert Newson a écrit :
> As also noted on IRC, you are indeed wrong,
I hope I am, I really tried to find the proper way to fully implement
OAuth authorization layer (tokens, ad hoc grant access in time and
scope: the very essence of OAuth) within the CouchDB intrinsic
techniques and philosophy, but I keep failing.
> you just don't like the
> granularity
I don't dislike or like it, but wherever I look it just appears to me
that there is just not enough of it to match the requirements of a
proper implementation of OAuth. But I believe being wrong, I'm sure I
am, I want to use Couch, can anyone point me the right direction? Once I
know it, I will like it.
Thanks,
Cheers,
Camille.
> of the operation you are authorized to perform after
> successfully authenticating. :)
>
> B.
--
The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
Re: OAuth for authorization (not authentication)
Posted by Camille Harang <ma...@yooook.net>.
Le 18/07/2011 15:44, Robert Newson a écrit :
> As also noted on IRC, you are indeed wrong, you just don't like the
> granularity of the operation you are authorized to perform after
> successfully authenticating. :)
Ha, I'm not sure not liking it, I might just not understand how it's
supposed to work :-/ What am I supposed to do after authentication to
let a view grant or not read access? Should I reflect the rights
associated to a OAuth token somewhere, during the authentication
process? If yes, where? In the ACLs?
Thank you,
Camille.
> B.
--
The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
Re: OAuth for authorization (not authentication)
Posted by Robert Newson <rn...@apache.org>.
As also noted on IRC, you are indeed wrong, you just don't like the
granularity of the operation you are authorized to perform after
successfully authenticating. :)
B.
On 18 July 2011 14:23, Camille Harang <ma...@yooook.net> wrote:
> Hi all, as discussed yesterday on IRC, it seems that the OAuth layer of
> CouchDB only covers the authentication mechanisms of OAuth, but not the
> authorization mechanisms (if I understood correctly, tell me if I'm
> wrong). However, the authorization layer is IMHO the most interesting
> part of OAuth:
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-18 :
>
> Abstract
>
> The OAuth 2.0 authorization protocol enables a third-party
> application to obtain limited access to an HTTP service, either on
> behalf of a resource owner by orchestrating an approval interaction
> between the resource owner and the HTTP service, or by allowing the
> third-party application to obtain access on its own behalf.
>
> But, as it's closely related to read access limitations (in time and
> scope), it doesn't fit well in the all-or-nothing ready access policy
> for a given database in CouchDB. After discussion, it seems that the
> proper way to do this with CouchDB is to set a DB per user and per
> permission. Following the example given in the OAuth RFC, where a user
> wants to grant access to his/her pictures (and only his/her pictures) to
> a printing shop for a limited time (time to print), it seems that in
> CouchDB we would need to set up a DB for the user's private data, and a
> for the the user's pictures (and for the user's bookmarks, and so on for
> each right's scope). Then we just need to grant or not read access to
> this or that DB, regarding the credentials of the third party request,
> but I don't know how to do this with the current ACL policy wich doesn't
> seems to match the OAuth's token system (the third party request must
> show a token, but how/where can I check it? How/where can I handle
> token's expiration time?).
>
> Do you think there is anyway to handle this? Or should I fallback to the
> "smart proxy" solution?
>
> Thanks,
>
> Regards,
>
> Camille.
>
> --
> The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
>
>