we are evaluating MongoDB 5.0 using a standalone instance of community edition.
We are considering how to setup the database security model (users and roles) for a new application. Having spent some time working with the product our developers have the following two requirements which they would like to meet using the database security model.
Allow the application user to perform CRUD operations on critical collections AND prevent the same collections from being dropped. They want to safeguard against accidental collection drops in the database for these critical collections.
Allow the application user to create and drop “temporary” collections. This appears to be a more efficient creating “permanent” collections and having to use delete commands.
This can be mitigated with good operational practice and other measures etc … but can we meet these two requirements with the MongoDB authorization. We use other database technologies but are new to MongoDB so let us know if the wrong way to approach the design of a MongoDB application.
Hello Karl @VIT, welcome to the MongoDB Community forum!
An application user group can have access to multiple databases and collections. You can setup database security to control this access - for example, the group members cannot delete a collection within a database. Different members can have different privileges.
You can create users and assign standard built-in roles. You can also create custom user-defined roles and assign them to users. This aspect can address your needs.
This means you need to setup MongoDB security - the authentication and authorization. By default, when you install MongoDB Community as a standalone, for example on your computer, the security is not enabled.
The second point about creating and dropping “temporary” collections can be addressed based upon the application user needs.
May be a database created by that user can hold collections to be created and dropped by that user only and for her or his usage only. Another option is to setup a “temporary” database where anyone can create or drop their own collections. You can think in those lines. You can fine tune using these custom roles.
Please note that application level security is different from database security. You can benefit from asking questions like what is it that the users want to do with these temporary collections - the requirements. In case you are not sure how a particular aspect will work now, keep option to change the security setup for this aspect later on as you develop your database and the application.
thank you for responding and offering your advice.
The idea to creating a separate database for “temporary” collections is interesting and hadn’t occurred to me. You could use a { db: “tempdb”, collection: “” } resource in the role definition and that could eliminate the need for a lot of object level permissions. I can see it would add a limitation in joining data between the “permanent” and “temporary” objects as they would be in separate databases.