[SERVER-648] document level access control Created: 19/Feb/10 Updated: 22/Mar/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 1.3.2 |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Mark Waschkowski | Assignee: | Backlog - Security Team |
| Resolution: | Unresolved | Votes: | 27 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Server Security
|
||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
Access control to the documents in the system would be very helpful. What is done on my current project is to implement an interface that is called during all database operations and returns a boolean to indicate whether or not the document should be included in the result set. We have added some attributes/fields to the document to specify who should be able to access it, and we run through some business rules (ie. admin vs normal user, group belonged to etc.) to determine access. The backend that we use currently provided the hook for us via the java interface for us to implement, and it is simple and effective. I can't see an application layer where munging of the queries or doing sub queries to be as clean or error free. |
| Comments |
| Comment by Charles Little [ 22/Mar/23 ] | |
|
Views are not sufficient unless there are only a handful of roles. Defining filter predicates that can be parameterized (and possibly use session roles in the filters) can provide a more flexible way to do document level ACL. Look at ElasticSearch doc-level access control as an example. | |
| Comment by Geert Bosch [ 19/Mar/23 ] | |
|
I think that effectively | |
| Comment by Russell Claxton [ 18/Mar/19 ] | |
|
I was wondering how this would be implemented and whether it would be similar to how access control is performed at the collection level (That being: via the use of user-defined roles). Here “By creating a role with privileges that are scoped to a specific collection in a particular database, administrators can provision users with roles that grant privileges on a collection level”. For example, the following privilege definition for a user role allows the find action on the “myCollection” collection:
I think this method could be difficult for Documents. Collections are named and therefore actions can be mapped to collection names (“find” on myCollection). Documents does not have such a naming system by default. (AKA - I can’t see here how to map specific documents to perhaps a user-defined role) Therefore, would the implementation differ and perhaps revolve around a tagging system as shown in “[Implement Field Level Redaction|https://docs.mongodb.com/manual/tutorial/implement-field-level-redaction/]”? Such an approach would be similar to what @Matthew Rummel has described above in the sense that a user has a token and documents would have tags containing matching token(s), giving the user access to that document (correct me if my interpretation is wrong here)
| |
| Comment by Matthew Rummel [ 24/May/17 ] | |
|
A few thoughts on implementing document label security:
| |
| Comment by Neville Dipale [ 19/Oct/13 ] | |
|
Ah, I didn't notice that part. Thanks | |
| Comment by Gianfranco Palumbo [ 19/Oct/13 ] | |
|
Neville, the SERVER ticket you mention talks about collection access level control, not document. | |
| Comment by Neville Dipale [ 17/Oct/13 ] | |
|
I think this is solved by Would also give MongoDB perspective on how things are going | |
| Comment by Mike Loll [ 05/Apr/13 ] | |
|
I have been working on a proof of concept for this on and off for the past month. I take an approach similar to how Accumulo handles column visibility - arbitrary boolean expressions like 'manager && engineer' indicate access restrictions on a document (its label if you are familiar with Oracle's label security). Clients send a list of their rights (['manager', 'engineer', 'readable']) which are then used to prune out documents which may satisfy the query predicate but don't satisfy the access restriction. If I can get it up on github I'll post a link, but it is not something that is really ready for prime time. Mike | |
| Comment by Nestor Urquiza [ 04/Oct/11 ] | |
|
I totally agree. Managing ACL in Service or any other layer ends up pretty soon in a mess. In the JPA world we have a project like jpasecurity which is a wrapper on top of the JPA provider that intercepts all queries and apply rules defined either in XML or with annotations. I think something like that should be included as part of MongoDB. I vote then for this feature. Best regards, | |
| Comment by Mark Waschkowski [ 19/Feb/10 ] | |
|
In summary, AC is a global type restriction, and should be treated as such at the database level, which is the gatekeeper of the data. can also see discussion here: |