+972 52-548-6969
Designing a document databaseAuthorization
This is actually a topic that I haven’t considered upfront. Now that I do, it looks like it is a bit of a hornet nest.
In order to have authorization we must first support authentication. And that bring a whole bunch of questions on its own. For example, which auth mechanism to support? Windows auth? Custom auth? If we have auth, don’t we need to also support sessions? But sessions are expansive to create, so do we really want that?
For that matter, would we need to support SSL?
I am not sure how to implement this, so for now I am going to assume that magic happened and it got done. Because once we have authorization, the rest is very easy.
By default, we assume that any user can access any document. We also support only two operations: Read & Write.
Therefore, we have two pre-defined attributes on the document, read & write. Those attributes may contain a list of users that may read/write to the document. If either read/write permission is set, then only the authorized users may view it.
The owner of the document (the creator) is the only one allowed to set permissions on a document. Note that write permission implies read permission.
In addition to that, an administrator may not view/write to documents that they do not own, but he is allowed to change the owner of a document to the administrator account, at which point he can change the permissions. Note that there is no facility to assign ownership away from a user, only to take ownership if you are the admin.
There is a somewhat interesting problem here related to views. What sort of permissions should we apply there? What about views which are aggregated over multiple documents with different security requirements? I am not sure how to handle this yet, and I would appreciate any comments you have in the matter.
More posts in "Designing a document database" series:
- (17 Mar 2009) What next?
- (16 Mar 2009) Remote API & Public API
- (16 Mar 2009) Looking at views
- (15 Mar 2009) View syntax
- (14 Mar 2009) Aggregation Recalculating
- (13 Mar 2009) Aggregation
- (12 Mar 2009) Views
- (11 Mar 2009) Replication
- (11 Mar 2009) Attachments
- (10 Mar 2009) Authorization
- (10 Mar 2009) Concurrency
- (10 Mar 2009) Scale
- (10 Mar 2009) Storage
Comments
What about DELETE?
I suggest to assign permissions to Role(s) (that can contain other Roles/Users) and/or Users.
I suggest to create functional/application Roles, like "Take Ownership" and if you're member of that Role you can take ownership of a document.
and about authorization, manual and windows authentication should be minimal
1) "Note that write permission implies write permission. " -> should be "Note that write permission implies read permission.", right?
2) Views can be handled in several ways:
a) they can have completely separate permissions from documents (View author assigns View permissions to users, which are completely separate from document permissions)
b) they can be tied to document Read permissions, i.e. all users who have Read permissions for a document are automatically assigned Read permissions for all Views using that document.
If there are multiple documents combined in one View, only users who have Read permissions for all underlying documents used by a View are automatically assigned Read permissions for that View.
Now, a) is very simple to implement, and requires some extra effort for manual permission assignment, while b) is more user-friendly at a cost of more application logic. Note that they are not exclusive, since even in b) maybe we want to be able to assign some permissions manually...
I guess this depends on the exact definition of View and the role you want them to play -> are they just a special category of documents, which uses other documents as data sources? Or are they conceptually completely separated from documents, and what is their basic idea then?
Can you consider standards like XACML (there is an open source version for it XACML.NET)
You may also want to consider another permission -- Control. It would permit the manipulation of the Access Control List.
You might also consider a mechanism whereby a user can automatically elevate his or her access under certain controlled conditions (with appropriate auditing and notifications).
Maybe you should consider adding users and groups as documents ('entities'), too? (and create some special document for the 'database engine' system account)
These documents would naturally appear as profiles and ACL lists at the same time, and you can include links to 'parent' groups/roles as fields in the 'user' document
*** i may be a bit unclear, so feel free to re-ask :)
Doesn't CouchDB address this? Might be useful to see what they did.. read something about a reader list, which makes me assume there must be a writer list too. dunno. trying to stick to my todo list for today.
abel,
the spec for that is 141 pages long, fail
One of the interesting things about CouchDB is because the API is REST based, you do not necessarily need a heavyweight authorization and authentication system. You can proxy access through IIS or Apache and let rewrites handle your authorization.
If you wan't maybe i've a solution for you, In my application i use microsoft acl with a database and nhibernate. We have made some extension in nhibernate but i would like to implement this into nhibernate contrib. We also have extend system.security.accesscontrol to manage acl and communicate with nhibernate.
This solution is very nice and very scalable, we manage 95000 secure entities and use it in tables with 2 millions row.
If you wan't more explain, contact me.
I think that the Doc Database should just have basic database wide authorization built in so that it should be very fast and the code base shouldn't be to complex and let the developer that needs all this add what they need in the layer above this.
sbia,
I do want to see more, yes.
Comment preview