[SERVER-1105] access control per collection Created: 08/May/10  Updated: 30/Oct/15  Resolved: 11/Oct/13

Status: Closed
Project: Core Server
Component/s: Security
Affects Version/s: None
Fix Version/s: 2.5.3

Type: New Feature Priority: Major - P3
Reporter: derlok epsilon Assignee: Andy Schwerin
Resolution: Done Votes: 61
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-8580 User defined roles Closed
is depended on by SERVER-8942 readWrite users can delete privilege ... Closed
Related
related to SERVER-8372 Insert only or write once access to a... Closed
related to SERVER-8582 Extend document expression language i... Closed
is related to SERVER-648 document level access control Backlog
Backwards Compatibility: Fully Compatible
Participants:

 Description   

I recently started using mongodb in depth and I was surprised to find that this does not have an access control per collection. from the security point of view this point is of great importance and is an impediment to migrate from sql to nosql in production. I really believe that this feature should be included as soon as possible or at least have a higher priority.

thank you very much



 Comments   
Comment by Andy Schwerin [ 11/Oct/13 ]

Documentation in conjunction with User Defined Roles (SERVER-8580).

Comment by auto [ 26/Sep/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-1105 Fix tool tests with auth.

Once we've created appropriate system roles for dump and restore, we can revisit
the choice in the test to assign the __system role to a restore user. For now,
it's the only way to do a restore with auth.
Branch: master
https://github.com/mongodb/mongo/commit/74c0439725e525689f04ad64a906a824ec8dd49c

Comment by auto [ 26/Sep/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-1105 Update AuthorizationSession's logic for collection-level access control.

Also requires changing the privileges of the built-in roles. This patch takes the opportunity to remove the 2.2-style read-only roles in favor of the 2.4-style "read" and "readAnyDatabase" roles, and renames the 2.2-style read-write roles "dbOwner" and "root". The "root" name, at least, is subject to change prior to the next unstable release.

Test harnesses are updated as needed to use the correct builtin roles.
Branch: master
https://github.com/mongodb/mongo/commit/3bc344db791e74f378880fd4ccd2ea045ba238f9

Comment by auto [ 23/Sep/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-1105 Fix logical error in authorization_session_test.cpp.
Branch: master
https://github.com/mongodb/mongo/commit/e9e6effc6bdd4e1e64baff266fb93515367e9db7

Comment by auto [ 23/Sep/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-1105 Use ResourcePattern type when identifying the resource component of required privileges.

This patch has two principal components. First, it changes the interface to Privilege and
AuthorizationSession to use ResourcePattern in place of std::string for identifying resources.
Second, it examines all call sites of the authorization session interface in commands and
other code to ensure that the correct resource requirements are conveyed to the authorization_session.
Branch: master
https://github.com/mongodb/mongo/commit/a7f7c028c4cdda1ab0939c6c7788bb39bd94cc5f

Comment by auto [ 20/Sep/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-1105 Introduce ResourcePattern type, for matching against resources in access control checks.
Branch: master
https://github.com/mongodb/mongo/commit/508b3bbaf866eb3ac4eaa5e415da25a29ad0fc58

Comment by auto [ 20/Sep/13 ]

Author:

{u'username': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}

Message: SERVER-1105 Do not test role->privilege mappings in authorization_manager_test.

Also, beef up privilege_document_parser_test, instead of testing role parsing in
authorization_manager_test.

The role->privilege mapping belongs to the RoleGraph, and the authorization of actions
to the AuthorizationSession. Actual parsing belongs in privilege_document_parser_test.
Branch: master
https://github.com/mongodb/mongo/commit/13e8f783b5f1fa695514158e0a8fbd7ba9be48f6

Comment by Daniel Pasette (Inactive) [ 25/Jul/13 ]

justanyone, as indicated by the fixVersion of 2.5.2, per-collection access control is also planned for the 2.6 release along with some other nice security enhancements like user-defined roles (SERVER-8580).

Comment by Tahir [ 19/Jul/13 ]

Good to hear that Dan.
@Kevin : if you have field level perms, it means that you can have higher level perms quite easily as well I believe.

Comment by Kevin J. Rice [ 19/Jul/13 ]

1. Let's solve basic problems before moving on to advanced features like permissions per field.

2. None/Read-only/Read-Write perms per database is a basic feature, methinks.

3. Per-Collection is next, that's table-level control, and it pretty basic as well.

4. Field level seems pretty advanced to me. Yes, Oracle has it (and probably all the majors - DB2, Sybase, Postgres, etc.). But, see #1 above.

Notes from the 'competition' (Oracle docs):

"You can grant privileges to use the DELETE, INSERT, SELECT, and UPDATE DML operations on a table or view. Grant these privileges only to users and roles that need to query or manipulate data in a table.

You can restrict INSERT and UPDATE privileges for a table to specific columns of the table. With selective INSERT, a privileged user can insert a row with values for the selected columns. All other columns receive NULL or the default value of the column. With selective UPDATE, a user can update only specific column values of a row. Selective INSERT and UPDATE privileges are used to restrict user access to sensitive data.

For example, if you do not want data entry users to alter the salary column of the employees table, then selective INSERT or UPDATE privileges can be granted that exclude the salary column. Alternatively, a view that excludes the salary column could satisfy this need for additional security."

Comment by Daniel Pasette (Inactive) [ 18/Jul/13 ]

noobcodeur, we are planning on adding a feature to the aggregation framework in 2.6 (SERVER-8582) which will allow some field-level access control functionality when querying the database.

Comment by Tahir [ 18/Jul/13 ]

Yes, for writes... but it's not flexible enough.. in a general fashion I might want to send only the readable fields from the dB object as JSON response without much intricacies for instance. read access restrictions at the field level would facilitate that without much hassle. And I think it would be faster if implemented as an option for instance than if done at the application level.

Comment by Artem [ 17/Jul/13 ]

@Tahir I think you can do that at application level. You can check field by $exists operator. If not exists then write, otherwise don't

Comment by Tahir [ 16/Jul/13 ]

@Artem yes that is what I was thinking about.

Comment by Artem [ 16/Jul/13 ]

@Tahir maybe you want read-only field? I mean to be possible write once.

Comment by Tahir [ 16/Jul/13 ]

I don't. And I meant it as an option. Just like you would not index every field. Someone might want to restrict access to a particular field. But honestly I don't know what it would imply in terms of performance. Do you ?

Comment by Alex Mcauley [ 16/Jul/13 ]

@Tahir: Field level is the MOST idiotic idea ever, do you know how much performance the DB would lose to achieve that?

Comment by Tahir [ 15/Jul/13 ]

Why restrict to collection level ? I would like to be even more granular, field level.

Comment by derlok epsilon [ 14/Jan/13 ]

Esto es vergonzoso. 3 años y un pedido de seguridad importante sigue sin tener respuesta. Esta claro que esta solución no esta preparada para ambiente productivos serios.

gracias por nada.

Comment by bad ninja [ 17/Dec/12 ]

Sounds like database-level access control is not granular enough. I'm in the same boat. +1

Also, prioritizing on # of votes is not a good metric to use to drive your release cycles.

Instead, you should talk about it internally and see if it makes sense as a business strategy. If the answer is no, then that's fine - just tell us that and we'll look at other solutions. However, relying on a magical number to be hit before starting a discussion doesn't take in account the number of people who want the feature and didn't vote (for whatever reason - maybe they don't want to create a login, etc.), and the other way around - it may falsely represent a large number of requests if someone is determined to create a bunch of different logins and masquerade as different users to get what they want.

Thx.

Comment by ken eucker [ 16/Jul/12 ]

Jumping in on the conversation here:

I have started a project that hinges on micro level security for users and really need options with Mongo in order to implement it. Being able to set security on stored javascript, collections, and fields would allow me to move my project further with Mongo. Until then, I can't use it like I need to.

Comment by sam king [ 29/May/12 ]

I have a startup which focuses on secure messaging from within social networks in which I added the per collection role base access control. But I haven't had the time to have it reviewed and check back to the source, I hope to find some time to give it back that next month.

Comment by derlok epsilon [ 29/May/12 ]

C'mon guys, when are you going to consider this request?

Comment by David Hoyt [ 25/Feb/12 ]

+1 to what everyone else has said.

Comment by Eliot Horowitz (Inactive) [ 09/Feb/12 ]

read vs read/write per database exists today.
this is ticket is specifically for per collection

Comment by Jon Rista [ 09/Feb/12 ]

My team has recently started using MongoDB. The issue of security did not enter our minds until we started to run our projects through QA, who wanted direct query access to validate data. I think its essential to security and reliability of data that ACL's be added per-database and per-collection, with the ability to restrict access to read-only, read/write, read/write/delete, etc. A fine grain of control will greatly expand the viability of MondoDB in the enterprise.

Comment by Andrew Morrow (Inactive) [ 12/Jan/12 ]

My team as well would like per-database / per-collection level ACLs. We have separate project teams that handle sensitive data, and we would like to be able to ensure that different teams cannot view or delete each others data on a shared mongodb installation. Creating multiple independent mongodb installations is not realistic.

Comment by Wim Wisselink [ 23/Dec/11 ]

As a webdevelopment company we developed a CMS which has MongoDB as it's main DB. Now serving a lot of website it's unfeasible to use the same username and password to authenticate with the db.

I really hope this feature passes.

Comment by Soumyajit Bhattacharjee [ 02/Nov/11 ]

Kindly implement this feature as soon as you can because its very important for security-critical use cases. Since a model based on one db per user will unnecessarily waste space in preallocation..

I'm working on a system where the data stored by users shud not be accessible to developers and admins. currently using a single db with a single user, but to implement the security requirement we need a user-to-collection authentication framework...

Thanks

Comment by kursion [ 16/Sep/11 ]

Yeah that would be nice. Imagine you have multiple websites on ONE server... you actually need to run multiple instance of Mongo to separate every architecture.

Would be nice to have some "folder" where you put every db that are link to a website (with an access/permissions for it).

MySQL does for example but it's not noSQL

Comment by Nick Daugherty [ 06/May/11 ]

This feature would be extremely useful and I think it's a must have for many companies before they get behind Mongo.

Comment by Colin Watson [ 26/Jul/10 ]

Lack of highly granular access controls will limit adoption. We were hoping to use MongoDB, but as a minimum would need multiple roles (e.g. public, authenticated user, system, logging, administrator) so we could partition access to the data based on what we know about the user. These roles would then have different abilities to add, edit, delete data in various collections.

Comment by Justin Dearing [ 05/Jul/10 ]

@shimon,

Your suggestions are good, but probably belong in a separate ticket.

Comment by Shimon Doodkin [ 05/Jul/10 ]

i want to give paritial access to the data in a table

like let read only with a query of owner_user=i_define_it_ statically_or_dynamically _on_logon_or_else
like add auto where restrictions to queries per user
defined by a javascript function

or another model is to make a permissions function per user that will check every query and return ok or kind of like this.

or define a structure of restrictions some of them static some of them dynamic- function
like:

settings={
collections:
{
my_list:

{userid:['==',ObjectID(12341abcfda0000000000da2)]}

,
my_other_list:

{userid:['!=',ObjectID(12341abcfda0000000000da2)]}

,
my_third_list:{userid:['bool',function(collection,col,user,op,where)

{ if(where['userid']) return true else return false}

]},
my_4th_list:{function match(data)

{return data['col']?true:false;}

:['onupdate',function(collection,col,user,op,where,data)

{ if(data['userid']==false) return false; else return true}

]},
my_4th_list:{'':['onupdate',function(collection,col,user,op,where,data)

{ if(date[itemid]=db.collections.items.findOne('userid').exists) return true; else return false }

]},
}
commands: { delete:true, update:function(user)

{return user.name.indexOf('admin')}

} }
}

or a function that returns this and generates this dynamically.

Comment by derlok epsilon [ 09/May/10 ]

The ideal would add this feature to the existing mongodb's authentication . Currently we can define authorized users and giving them rw or read-only permissions. In my opinion, if this same feature gives us a higher level of specification, if we could defined write access or read-only users permission per collection this would allow to set users roles access for the proper segregation of duties.

[sorry for my english]

Comment by Justin Dearing [ 08/May/10 ]

A more robust security model for mongo would make it useful for direct querying.

This should be carefully planned before implementing. A few things to think about:

What about stored javascript? In SQL server, if you have permission to execute a stored proc, but not the tables it manipulates, the stored proc will run. In postgres this is not the case, unless you explicitly declare a "sudo user" for the stored proc to run as.

Since stored javascript is stored in a system collection, then it might make sense to add document level permissions.

Comment by Eliot Horowitz (Inactive) [ 08/May/10 ]

This is the first request we've gotten for this.
We'll prioritize up based on # of votes.

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