Use wildcard databases in user role privileges (like collections)
Use wildcard databases in user role privileges (like collections)
![](https://secure.gravatar.com/avatar/5dad957fdc94923d604713f2e9d53110?size=40&default=https%3A%2F%2Fassets.uvcdn.com%2Fpkg%2Fadmin%2Ficons%2Fuser_70-6bcf9e08938533adb9bac95c3e487cb2a6d4a32f890ca6fdc82e3072e0ea0368.png)
-
AdminSalman (Admin, MongoDB) commented
Thanks, Shanjeef for your idea.
If there was a way to define a database role which forces application to pass an application-specific specific tenant ID in every query, could that meet your needs?
Example:
1 Create a database read-only role for the application database user. This role requires a mandatory query parameter (appSpecificTenantId) which must be supplied on every query. The value of appSpecificTenantId parameter will need to be provided by the application on each query.
db.createRole(
{
role: "appSpecificDBRole",
privileges: [{
resource: {
db: "mydb",
collection: "mycol" },
actions: [ "find"],
mandatory_query_parameters: [ "appSpecificTenantId" ] //<-- does not exist today
}],
},
{ w: "majority" , wtimeout: 5000 }
)Then, application issues a query such as the following where it always supply a value for "appSpecificTenantId" . Application may also add other filter parameters (cityName in this case)
2. db.users.find({ appSpecificTenantId: '1234', cityName: 'foo' })
-
Shanjeef Satchi commented
Upvoting this! I work on a multi-tenanted application where data segregation is enforced at the application (db driver shim) level. Our collections store documents that span across all tenants, but when queries are applied through app code, we enforce tenant segregation. https://www.mongodb.com/docs/manual/core/views/ allow us to control which users have access to specific documents within a collection. It'd be great for us to have wildcard matching when defining resource access through roles. We have a pattern for creating our views (by tenant), but right now when a new collection (and view) is created, we have to manually update the role's privileges list. It would be nice to avoid this step!