[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:
Depends
Related
related to SERVER-1105 access control per collection Closed
Assigned Teams:
Server Security
Participants:
Case:

 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 SERVER-142 (Read-only views) provides this capability. It is possible to create a view exposing documents according to an aggregation pipeline, and give specific authorizations to that view.

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:

 

“{ resource: { db: "myDatabase", collection: "myCollection" },  actions: [ "find" ] }”.

 

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:

  • User's should have a security token or belong to a group that has a security token. This token defines what documents a user is allowed to access.
  • A security token is a representation of all the security groups to which the user belongs.
  • A given user's token should be compared with the at the document and subdocument level (and potentially at the filed level) in each document automatically when a crud operation is performed. Only those documents/subdocuments/fields that a user has access to will be affected by the operation.
  • The framework must allow for security groups to inherit the permissions of other security groups. For instance, if a document is tagged with the "HR" security group and "HR" is not inherited by any other defined security groups, then only users with the "HR" group will be able to perform CRUD operations on the document/subdocument/field. However, If the "Executive" group inherits the "HR" group, then user's with either the "Executive" or "HR" security groups will be able to perform CRUD on the data.
  • The evaluation of a document's security label rules should allow for 'AND' and 'OR' operations, such as "User is in security group A and B" or "User is in group A or B or C".
  • A user's security token and a data security label should allow for various compartments to be used in the evaluation, such as "Department Context: "User is in department security group A or B, Function Context: User is in functional group B or C".
  • Document level access control should be able to be enabled or disabled at the collection level. Some collections should enforce access control while others do not.
  • Both top level and embedded documents should be able to have their own access control label. If an embedded document has a more restrictive access control than it's parent and a user does not have the permissions necessary to perform a crud operation at the embedded access level, the embedded document should be omitted from the operation.
  • A user should be able to run a CRUD operation that is more restrictive than their permissions allow. For instance, if a user has security groups "Accounting" and "Engineering" wants to perform a find operation on documents that have the "Engineering" document label, he or she should be able to do so.
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.
That is, each document can possibly have different authorisations (read, write) to different users

Comment by Neville Dipale [ 17/Oct/13 ]

I think this is solved by SERVER-1105. Maybe we should get the MongoDB team and the community to spend 1-2 days going through open issues that might have been resolved over time. I'm personally tired of those people who blog about how MongoDB is focusing on benchmarks and unsafe writes blah blah, and they go point out very old issues that haven't been, or won't be resolved/worked on.

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,
-Nestor

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:
http://groups.google.com/group/mongodb-user/browse_thread/thread/72fc46873b5be14e

Generated at Thu Feb 08 02:54:46 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.