couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "PerDocumentAuthorization" by BramNeijt
Date Mon, 15 Nov 2010 12:59:39 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "PerDocumentAuthorization" page has been changed by BramNeijt.
The comment on this change is: Add: Document encryption.
http://wiki.apache.org/couchdb/PerDocumentAuthorization?action=diff&rev1=1&rev2=2

--------------------------------------------------

  ||<#8080FF> This page forms a summary of the problem and possible solutions, it does
not reflect current CouchDB features. ||
  
- == The problem ==
-   For a given user, allow only specific access to a given document in the database.
- The user is authenticated using any kind of authentication method (HTTP basic auth, or otherwise)
and is considered to be identified by a single identifying string. Under the term "specific
access", this document considers three types: being able to verify existance, being able to
read the document, and being able to update the document (deleting the document is considered
an update of the document).
+ <<TableOfContents(2)>>
+ = Introduction =
+ CouchDB has a good HTTP API which encourages you to put your client applications in direct
contact with your database. However, most dynamic systems require some kind of authentication
and authorization. Per database there is the possibility of using [[Authentication and Authorization]].
This wiki page tries to summarize the possible solutions to using per document authentication
and authorization.
  
+   '''The problem:''' For a given user, allow only specific access to a given document in
the database.
  
+ The user is authenticated using any kind of authentication method (HTTP basic auth, or otherwise)
and is considered to be identified by a single identifying string. Under the term "specific
access", this document considers three types: being able to verify existence, being able to
read the document, and being able to update the document (deleting the document is considered
an update of the document)
  
+ = Possible solutions =
+ == Document encryption on a per user basis ==
+ This solution is described in [[https://docs.google.com/document/pub?id=1NWZ9xhsQvUL24IDa4erYcEZwkoNH6m13fizn8_og0gY|a
google document]] which was mentioned on the development mailinglist. The goal of this solution
is to create a P2P like system, where you can replicate data to nodes which you don't trust.
+ 
+ Access protection this solution implements:
+  * Update: partially, delete is still possible but the encrypted part can not be corrupted.
+  * Verify existence: It is still possible to verify the existence of a document.
+  * Read: protected by the strength of the encryption.
+ 
+ Limitations:
+  * As soon as you have encrypted data on the database end, queries become a problem.
+  * There is often no real-world need to freely distribute encrypted data. Therefore this
approach is considered to P2P centric.
+ 
- == See also ==
+ = See also =
   * http://wiki.apache.org/couchdb/Authentication_and_Authorization
   * http://wiki.apache.org/couchdb/Frequently_asked_questions#When_will_CouchDB_add_per-document_auth.3F
   * http://mail-archives.apache.org/mod_mbox/couchdb-dev/201010.mbox/%3cC4B01815-5A28-4E5F-975D-70344B7570EC@apache.org%3e

Mime
View raw message