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

Discussion in 'ASP .Net' started by Earl Teigrob, Jun 9, 2004.

  1. Earl Teigrob

    Earl Teigrob Guest

    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
     
    Earl Teigrob, Jun 9, 2004
    #1
    1. Advertising

  2. Earl Teigrob

    bruce barker Guest

    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" <> wrote in message news:...
    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
     
    bruce barker, Jun 9, 2004
    #2
    1. Advertising

  3. Earl Teigrob

    Earl Teigrob Guest

    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
    "bruce barker" <> wrote in message news:...
    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" <> wrote in message news:...
    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
     
    Earl Teigrob, Jun 9, 2004
    #3
  4. "Earl Teigrob" <> wrote in message news:...
    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.
    --
    John Saunders
    johnwsaundersiii at hotmail
     
    John Saunders, Jun 10, 2004
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chad Z. Hower aka Kudzu

    Separating code from design

    Chad Z. Hower aka Kudzu, Jan 23, 2004, in forum: ASP .Net
    Replies:
    6
    Views:
    440
    Chad Z. Hower aka Kudzu
    Jan 24, 2004
  2. =?Utf-8?B?R3JlZw==?=
    Replies:
    1
    Views:
    348
    =?Utf-8?B?Q3VydF9DIFtNVlBd?=
    Sep 9, 2005
  3. =?Utf-8?B?UmFjaGVs?=

    Provider Model : modular application design issue

    =?Utf-8?B?UmFjaGVs?=, Feb 9, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    398
    Karl Seguin [MVP]
    Feb 9, 2006
  4. lord0
    Replies:
    6
    Views:
    427
    Michiel Konstapel
    Dec 20, 2003
  5. Íéêüëáïò Êïýñáò

    Separating design from code

    Íéêüëáïò Êïýñáò, Mar 22, 2011, in forum: Python
    Replies:
    0
    Views:
    200
    Íéêüëáïò Êïýñáò
    Mar 22, 2011
Loading...

Share This Page