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

[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=(tru e|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

[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)

"Earl Teigrob" <ea******@hotmail.com> wrote in message news:eE*************@TK2MSFTNGP12.phx.gbl...
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=(tru e|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