I would like to add the following to the previous posts on the security application:
1) object access control list
2) object lifetime management
3) object permissions view
I have looked at the security application block. That is helpful to authenticate and authorize users, retrieve role and cache caching user profile. It solves a lot of the application security and is extensible to add security providers.
However, domain objects are not required to have security access control or are controlled via business logic that typically is pushed down to the database server as stored procedures. Stored procedures are helpful in enterprise cases where the prepared plans can be very helpful. Besides, object persistence requires data store. And data store comes with security.
So it may seem like that there is no custom security modules required out of the data store. However with business logic sometimes spread across backend, middle-tier, and front end, there is no one layer in which the security can be consolidated. Consequently, validations may be spread out.
Moreover, some checks are done upfront where data is either hidden or rendered readonly from the user's view. Often the control states are based on what the view models allow and they pull their data from the models and in turn data store. Since the check happens as fast and as early as possible, the objects are expected to carry the security information with them at the time the viewmodels are initialized. The objects are instantiated and disposed for the duration of the view model only and this typically is so short lived that there is no need for object based security. Security is already declared and available from the data store.
However, let us view the case where we could do things a little differently. We want to have a security admin selectively make certain data as readonly for a certain downtime so that users using the database cannot modify these data during this downtime even though they have access. The security admin is not interested in making permanent changes. Further the scoping is not at schema level but to domain objects often referred to with their names or ids as values.
Let us look at how the security admin would selectively disable some objects from all users with existing tools. First, they could apply different labels to select records across the schema to disable these and revoke the same changes. These changes could be executed with a stored procedure giving all the benefits of security control and audit. The changes are also in one place and very easily managed across clients and applications since they are as close to the data as possible.
However, let's look at services and applications that use more than one data store and integrate across a variety of data providers. These services or applications could keep their own databases that they read data from the downstream data providers and that way we could revert to the previous method where we apply security labels to a single data store.
That said, let's consider the case where we implement a truly middle tier SOA service based security where the object turned on or off without necessarily reaching the database. Further let's say we don't want hard on or off to the objects that prevent user from read write but merely tag them with labels so that we can decide to take appropriate action on these objects on a graded scale.
So we are really looking for an object tagger that we can visualize to study such things as usages and access patterns. Then how do we build an object tagger that can be non-invasive to the object ?
1) object access control list
2) object lifetime management
3) object permissions view
I have looked at the security application block. That is helpful to authenticate and authorize users, retrieve role and cache caching user profile. It solves a lot of the application security and is extensible to add security providers.
However, domain objects are not required to have security access control or are controlled via business logic that typically is pushed down to the database server as stored procedures. Stored procedures are helpful in enterprise cases where the prepared plans can be very helpful. Besides, object persistence requires data store. And data store comes with security.
So it may seem like that there is no custom security modules required out of the data store. However with business logic sometimes spread across backend, middle-tier, and front end, there is no one layer in which the security can be consolidated. Consequently, validations may be spread out.
Moreover, some checks are done upfront where data is either hidden or rendered readonly from the user's view. Often the control states are based on what the view models allow and they pull their data from the models and in turn data store. Since the check happens as fast and as early as possible, the objects are expected to carry the security information with them at the time the viewmodels are initialized. The objects are instantiated and disposed for the duration of the view model only and this typically is so short lived that there is no need for object based security. Security is already declared and available from the data store.
However, let us view the case where we could do things a little differently. We want to have a security admin selectively make certain data as readonly for a certain downtime so that users using the database cannot modify these data during this downtime even though they have access. The security admin is not interested in making permanent changes. Further the scoping is not at schema level but to domain objects often referred to with their names or ids as values.
Let us look at how the security admin would selectively disable some objects from all users with existing tools. First, they could apply different labels to select records across the schema to disable these and revoke the same changes. These changes could be executed with a stored procedure giving all the benefits of security control and audit. The changes are also in one place and very easily managed across clients and applications since they are as close to the data as possible.
However, let's look at services and applications that use more than one data store and integrate across a variety of data providers. These services or applications could keep their own databases that they read data from the downstream data providers and that way we could revert to the previous method where we apply security labels to a single data store.
That said, let's consider the case where we implement a truly middle tier SOA service based security where the object turned on or off without necessarily reaching the database. Further let's say we don't want hard on or off to the objects that prevent user from read write but merely tag them with labels so that we can decide to take appropriate action on these objects on a graded scale.
So we are really looking for an object tagger that we can visualize to study such things as usages and access patterns. Then how do we build an object tagger that can be non-invasive to the object ?
No comments:
Post a Comment