Let's quickly review some techniques of securing domain objects with user access control.
First there are two different approaches:
1) Resource based : Individual resources are secured using windows ACLs
2) Role based : Users are partitioned into roles, members of a particular role share the same privilege within the application.
It used to be that role based access was preferred over resource based because the latter didn't scale and worked better for resources that can leverage the builtin RBAC access control out of underlying systems such as windows. Further role based access enables connection pooling and so on. However with AD integrations and improvements to database server, administrators and developers alike want individual user access to different resources.
For simplicity, let's take a base table for an entity that we want to secure and say we have a relational mapping to a control table with IDs for privileges. ID 0 means access to none, ID 1 means access to everyone etc. and intermediate groups in between. And the controls table may be a view in itself with multiple tables just like the base table can be a view where only the records visible to the user are available for insert, update and delete.
Then we perform security at each level of the stack in this way:
Authenticate users within your front end application
Map users to role
Authorize access to operations (not directly to resources) based on role membership
Access the necessary backend resources by using fixed service identities and privileges.
Access can be granted and revoked to data tables as a whole but if row level security is desired, one could add row level labels that are classified based on control table.
First there are two different approaches:
1) Resource based : Individual resources are secured using windows ACLs
2) Role based : Users are partitioned into roles, members of a particular role share the same privilege within the application.
It used to be that role based access was preferred over resource based because the latter didn't scale and worked better for resources that can leverage the builtin RBAC access control out of underlying systems such as windows. Further role based access enables connection pooling and so on. However with AD integrations and improvements to database server, administrators and developers alike want individual user access to different resources.
For simplicity, let's take a base table for an entity that we want to secure and say we have a relational mapping to a control table with IDs for privileges. ID 0 means access to none, ID 1 means access to everyone etc. and intermediate groups in between. And the controls table may be a view in itself with multiple tables just like the base table can be a view where only the records visible to the user are available for insert, update and delete.
Then we perform security at each level of the stack in this way:
Authenticate users within your front end application
Map users to role
Authorize access to operations (not directly to resources) based on role membership
Access the necessary backend resources by using fixed service identities and privileges.
Access can be granted and revoked to data tables as a whole but if row level security is desired, one could add row level labels that are classified based on control table.
No comments:
Post a Comment