Design Issue: Separating Application Security Model from the Application (Custom or User) Controls

E

Earl Teigrob

Background:
When I create a ASP.NET control (User or custom), it often requires security to be set for certain functionality with the control. For example, a news release user control that is comprised of a DataGrid may have separate permissions for adding, deleting and updating a news item.

Problem
Up until now, I have been implementing security directly inside the control. I will test directly against the security model to see if permission is granted for each control permission. For example, the control may use something like

if (Page.User.IsInRole("fld")) {...}


The problem with this is that if I decide to use this control in another application that implements a different security model or want to change the security model, I need to change ever control I have built.

Goal
I would like to create my controls such that they are independent of any security model, yet implement security.

Some Thoughts
When I first thought about this issue, I figured I would just create a Boolean property for each control permission and set that property using the security model. However, many of my controls are dynamically loaded and I do not know what permissions to set at run time. I could create a security wrapper around each control, but this would add another level of abstraction that is cumbersome and results in almost the same problem.the security model being dispersed throughout all my code.

Proposed Solution
Here are some ideas on implementing a universal security model for all my own controls.

What if all controls where passed a standard .NET data structure such as a Sorted List that contained all of the current user permissions for all controls. The control itself would then check to see if the permission in the Sorted List exists for each of its own set of permissions, granting or denying permissions appropriately.

The job of the security model would simply be to create this Sorted List for the user. This list could be stored in a session cache (I created a custom class for session cache) and retrieved on demand.

To get a little elaborate, each custom control (or user control) could inherit from a base class that contains a "set permissions" method that receives the Sorted List of permissions and sets them for that control. In order for the "set permissions" method to know how to access the permissions of the control, each control could contain a sub-class with the same name (such as "permissionsclass") that contains a property for each permission in the control. (see pseudo code below) The "set permissions" method would then use class reflection to iterate through the permission properties of the permissionclass sub-class and set their permission properties based on whether or not the permission of the same name exists in the permissions Sorted List.

The permissions of the control could still be set manually, if that is necessary, by using dot access such as

controlclass1.permissionsclass.EditPermission=(true|false)





//Pseudo code for control class permission structure
class controlclass //control class
{
class permissionsclass //permissions sub-class
{

public EditPermission //permission
{
Set{.}
Get{.}
}

public DeletePermission
{
Set{.}
Get{.}
}

public UpdatePermission
{
Set{.}
Get{.}
}
}

}

This model would completely separate the security model from the control itself. The bridge between the security model and the control would be a standard .NET data structure, and therefore the control could be implemented in any application, regardless of the underlying security model. Since the permission could be set explicitly or via the Sorted List data structure, it gives the user of the control complete flexibility to how to set its permissions.

Does anyone have any thoughts on this, what's good and what's not, and any alternative solutions that might work better. I am just in the thinking phase and want to get on the right track from the beginning, if there is such a thing.

Thanks for your input

Earl
 
B

bruce barker

a better solution would be the factory pattern. basically define an security interface your controls use. then use the factory pattern for the application to supply the security object (easy to have a default).

-- bruce (sqlwork.com)

Background:
When I create a ASP.NET control (User or custom), it often requires security to be set for certain functionality with the control. For example, a news release user control that is comprised of a DataGrid may have separate permissions for adding, deleting and updating a news item.

Problem
Up until now, I have been implementing security directly inside the control. I will test directly against the security model to see if permission is granted for each control permission. For example, the control may use something like

if (Page.User.IsInRole("fld")) {...}


The problem with this is that if I decide to use this control in another application that implements a different security model or want to change the security model, I need to change ever control I have built.

Goal
I would like to create my controls such that they are independent of any security model, yet implement security.

Some Thoughts
When I first thought about this issue, I figured I would just create a Boolean property for each control permission and set that property using the security model. However, many of my controls are dynamically loaded and I do not know what permissions to set at run time. I could create a security wrapper around each control, but this would add another level of abstraction that is cumbersome and results in almost the same problem.the security model being dispersed throughout all my code.

Proposed Solution
Here are some ideas on implementing a universal security model for all my own controls.

What if all controls where passed a standard .NET data structure such as a Sorted List that contained all of the current user permissions for all controls. The control itself would then check to see if the permission in the Sorted List exists for each of its own set of permissions, granting or denying permissions appropriately.

The job of the security model would simply be to create this Sorted List for the user. This list could be stored in a session cache (I created a custom class for session cache) and retrieved on demand.

To get a little elaborate, each custom control (or user control) could inherit from a base class that contains a "set permissions" method that receives the Sorted List of permissions and sets them for that control. In order for the "set permissions" method to know how to access the permissions of the control, each control could contain a sub-class with the same name (such as "permissionsclass") that contains a property for each permission in the control. (see pseudo code below) The "set permissions" method would then use class reflection to iterate through the permission properties of the permissionclass sub-class and set their permission properties based on whether or not the permission of the same name exists in the permissions Sorted List.

The permissions of the control could still be set manually, if that is necessary, by using dot access such as

controlclass1.permissionsclass.EditPermission=(true|false)





//Pseudo code for control class permission structure
class controlclass //control class
{
class permissionsclass //permissions sub-class
{

public EditPermission //permission
{
Set{.}
Get{.}
}

public DeletePermission
{
Set{.}
Get{.}
}

public UpdatePermission
{
Set{.}
Get{.}
}
}

}

This model would completely separate the security model from the control itself. The bridge between the security model and the control would be a standard .NET data structure, and therefore the control could be implemented in any application, regardless of the underlying security model. Since the permission could be set explicitly or via the Sorted List data structure, it gives the user of the control complete flexibility to how to set its permissions.

Does anyone have any thoughts on this, what's good and what's not, and any alternative solutions that might work better. I am just in the thinking phase and want to get on the right track from the beginning, if there is such a thing.

Thanks for your input

Earl
 
E

Earl Teigrob

Thanks, Bruce, but I am a little lost trying to understand how this actually works. Do you know of a resource that could explain this in concept in more detail? I do understand class factories to some degree, but fail to see how they are used in developing a security solution.

Thanks

Earl
a better solution would be the factory pattern. basically define an security interface your controls use. then use the factory pattern for the application to supply the security object (easy to have a default).

-- bruce (sqlwork.com)

Background:
When I create a ASP.NET control (User or custom), it often requires security to be set for certain functionality with the control. For example, a news release user control that is comprised of a DataGrid may have separate permissions for adding, deleting and updating a news item.

Problem
Up until now, I have been implementing security directly inside the control. I will test directly against the security model to see if permission is granted for each control permission. For example, the control may use something like

if (Page.User.IsInRole("fld")) {...}


The problem with this is that if I decide to use this control in another application that implements a different security model or want to change the security model, I need to change ever control I have built.

Goal
I would like to create my controls such that they are independent of any security model, yet implement security.

Some Thoughts
When I first thought about this issue, I figured I would just create a Boolean property for each control permission and set that property using the security model. However, many of my controls are dynamically loaded and I do not know what permissions to set at run time. I could create a security wrapper around each control, but this would add another level of abstraction that is cumbersome and results in almost the same problem.the security model being dispersed throughout all my code.

Proposed Solution
Here are some ideas on implementing a universal security model for all my own controls.

What if all controls where passed a standard .NET data structure such as a Sorted List that contained all of the current user permissions for all controls. The control itself would then check to see if the permission in the Sorted List exists for each of its own set of permissions, granting or denying permissions appropriately.

The job of the security model would simply be to create this Sorted List for the user. This list could be stored in a session cache (I created a custom class for session cache) and retrieved on demand.

To get a little elaborate, each custom control (or user control) could inherit from a base class that contains a "set permissions" method that receives the Sorted List of permissions and sets them for that control. In order for the "set permissions" method to know how to access the permissions of the control, each control could contain a sub-class with the same name (such as "permissionsclass") that contains a property for each permission in the control. (see pseudo code below) The "set permissions" method would then use class reflection to iterate through the permission properties of the permissionclass sub-class and set their permission properties based on whether or not the permission of the same name exists in the permissions Sorted List.

The permissions of the control could still be set manually, if that is necessary, by using dot access such as

controlclass1.permissionsclass.EditPermission=(true|false)





//Pseudo code for control class permission structure
class controlclass //control class
{
class permissionsclass //permissions sub-class
{

public EditPermission //permission
{
Set{.}
Get{.}
}

public DeletePermission
{
Set{.}
Get{.}
}

public UpdatePermission
{
Set{.}
Get{.}
}
}

}

This model would completely separate the security model from the control itself. The bridge between the security model and the control would be a standard .NET data structure, and therefore the control could be implemented in any application, regardless of the underlying security model. Since the permission could be set explicitly or via the Sorted List data structure, it gives the user of the control complete flexibility to how to set its permissions.

Does anyone have any thoughts on this, what's good and what's not, and any alternative solutions that might work better. I am just in the thinking phase and want to get on the right track from the beginning, if there is such a thing.

Thanks for your input

Earl
 
J

John Saunders

Background:
When I create a ASP.NET control (User or custom), it often requires security to be set for certain functionality with the control. For example, a news release user control that is comprised of a DataGrid may have separate permissions for adding, deleting and updating a news item.

Problem
Up until now, I have been implementing security directly inside the control. I will test directly against the security model to see if permission is granted for each control permission. For example, the control may use something like

if (Page.User.IsInRole("fld")) {...}


The problem with this is that if I decide to use this control in another application that implements a different security model or want to change the security model, I need to change ever control I have built.

Goal
I would like to create my controls such that they are independent of any security model, yet implement security.

Ed, you might want to look at the way Windows does object security as a model. Different objects can have different meanings for the "Read" access bit, yet it's the same bit across all objects. They can also have object-specific access bits, yet the same security monitor is used to confirm whether access is possible.

Any OS object may have an Access Control List, which is a data type shared by all OS objects. Each object implements various operations. For each operation, it can decide what access is required to perform it. It can then call the OS security monitor to find out whether the current user, given the current ACL, has access to perform the particular operation.

It's all quite general.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top