Allow views with programmatic role based access control rather than just declarative
Often Views, defined by an aggregation pipeline, are used to filter out certain fields, certain records and obfuscate parts of certain values to enable users with a specific restricted role to only see a subset of 'less sensitive' data from a collection. Views can be assigned to a role declaratively, but in some use cases it is also useful to allow the aggregation pipeline logic to be able to access the context of the current session's roles (e.g. $$ROLES) or user id (e.g. $$USER) to be able to make some programmatic decisions of what to show in the view based on current user & role (i.e. to perform programmatic role based access control).
In some examples, this aggregation pipeline may even want to use $$ROLES or $$USER to then perform a $lookup on a different 'metadata' collection, to influence what it decides to return as the output of the view.
Paul
shared this idea
MongoDB 7.0 provides variable USER_ROLES that can be used in the view definition pipeline!
-
Paul
commented
Fantastic - thank you Katya and team!
-
Eluízio
commented
I just got a customer request regarding this feature! It would be fantastic if we could get Data Masking based on User privileges without having to use views or aggregation pipeline. That would help us to address some local data privacy regulations such as LGPD (similar to GDPR but for Brazil).
-
Paul
commented
In theory, $listLocalSessions: {allUsers: false} can sort of be used to be able to understand current user context in an aggregation pipeline but this can only be run against a 'db' and not against a 'collection' so doesn't help here.