We are trying to come up with a permissions/security implementation on our MongoDB backend/Angular front-end environment that accomplishes what we need it to, without being over-bearing or too difficult to build-out/adjust in the future. And, to clarify, I'm referring to the permissions that apply to the end-user of data provided by the API and being displayed in the front-end Angular app. I'm not referring to our back-end admin privileges that apply among our DBAs.

One approach would be to make the permissions schema/model-based. That way, because this would be granular enough to be defined on each property within each model, only the properties that a front-end consumer should be able to read and/or write to -- based on their role permissions -- are returned when a request is made.

The advantage to this implementation is that the front-end Angular app can consume documents agnostically (i.e., the document has been vetted before it is returned, so there's no checking to do on the front-end).

In terms of best practices, is this the way to do this -- handle all permissions on the API rather than on the front-end consuming app? And does it make sense to do this at the model/property level?

A drawback to this approach would be that we'd have to impact all documents when it came time to change permissions. Maybe there's a way to link the models to a central permissions object?

Or, is there a different way to approach this that's considered more common in terms of following best practices? Knowing that other organizations have all faced these same questions, we want to make sure we're following best practices, and not unnecessarily re-inventing the wheel.

We are trying to come up with a permissions/security implementation on our MongoDB backend/Angular front-end environment that accomplishes what we need it to, without being over-bearing or too difficult to build-out/adjust in the future. And, to clarify, I'm referring to the permissions that apply to the end-user of data provided by the API and being displayed in the front-end Angular app. I'm not referring to our back-end admin privileges that apply among our DBAs.

One approach would be to make the permissions schema/model-based, using a plugin such as this (https://www.npmjs.com/package/mongoose-authorization). That way, because this would be granular enough to be defined on each property within each model, only the properties that a front-end consumer should be able to read and/or write to -- based on their role permissions -- are returned when a request is made.

The advantage to this implementation is that the front-end Angular app can consume documents agnostically (i.e., the document has been vetted before it is returned, so there's no checking to do on the front-end).

In terms of best practices, is this the way to do this -- handle all permissions on the API rather than on the front-end consuming app? And does it make sense to do this at the model/property level?

A drawback to this approach would be that we'd have to impact all documents when it came time to change permissions. Maybe there's a way to link the models to a central permissions object?

Or, is there a different way to approach this that's considered more common in terms of following best practices? Knowing that other organizations have all faced these same questions, we want to make sure we're following best practices, and not unnecessarily re-inventing the wheel.

We are trying to come up with a permissions/security implementation on our MongoDB backend/Angular front-end environment that accomplishes what we need it to, without being over-bearing or too difficult to build-out/adjust in the future.

One approach would be to make the permissions model-based. That way, because this would be granular enough to be defined on each property within each model, only the properties that a front-end consumer should be able to read and/or write to -- based on their role permissions -- are returned when a request is made.

The advantage to this implementation is that the front-end Angular app can consume documents agnostically (i.e., the document has been vetted before it is returned, so there's no checking to do on the front-end).

In terms of best practices, is this the way to do this -- handle all permissions on the API rather than on the front-end consuming app? And does it make sense to do this at the model/property level?

A drawback to this approach would be that we'd have to impact all documents when it came time to change permissions. Maybe there's a way to link the models to a central permissions object?

Or, is there a different way to approach this that's considered more common in terms of following best practices? Knowing that other organizations have all faced these same questions, we want to make sure we're following best practices, and not unnecessarily re-inventing the wheel.

We are trying to come up with a permissions/security implementation on our MongoDB backend/Angular front-end environment that accomplishes what we need it to, without being over-bearing or too difficult to build-out/adjust in the future. And, to clarify, I'm referring to the permissions that apply to the end-user of data provided by the API and being displayed in the front-end Angular app. I'm not referring to our back-end admin privileges that apply among our DBAs.

One approach would be to make the permissions schema/model-based. That way, because this would be granular enough to be defined on each property within each model, only the properties that a front-end consumer should be able to read and/or write to -- based on their role permissions -- are returned when a request is made.

The advantage to this implementation is that the front-end Angular app can consume documents agnostically (i.e., the document has been vetted before it is returned, so there's no checking to do on the front-end).

In terms of best practices, is this the way to do this -- handle all permissions on the API rather than on the front-end consuming app? And does it make sense to do this at the model/property level?

A drawback to this approach would be that we'd have to impact all documents when it came time to change permissions. Maybe there's a way to link the models to a central permissions object?

Or, is there a different way to approach this that's considered more common in terms of following best practices? Knowing that other organizations have all faced these same questions, we want to make sure we're following best practices, and not unnecessarily re-inventing the wheel.