none
Field Level Security RRS feed

  • Question

  • Hello Friends.

     

    Can anyone tell me how to provide Field Level Security in asp.net 2.0?

    and how to implement it on different asp controls?

     

    Thanks

    Monday, February 25, 2008 10:42 AM

Answers

  • You could use role based permissions on the methods that the controls call, but this would have to be fairly specific to your situation.  You would have to handle the situation then to inform the user that they don't have permissions to perform the operation.

     

    You could check the roles before you render and disable controls based on that functionality, again specific to the situation, and possibly quite hard to test.

     

    Hope this helps,

     

    Martin Platt.

     

     

     

    Thursday, February 28, 2008 12:55 AM
  • Basically you can leverage the ASP.NET SQL role provider. You can additional tables where you can have fields / functions for which you want to contol the permissions.

     

    The table can have following fields : RoleId | Permission/Field ID | Allowed

     

    Here you can have map permissions through the boolean values in the allowed column.

     

    In the ASP.NET page, you can use the IsInRole method at the time of page loading and accordingly enable assigne true or false for the fields or you can assign visible true or false as required.

     

    For the function level, you can follow the same approach to visible true or false the function (Submit) buttons

     

    Thursday, February 28, 2008 1:24 PM
  • I'd add that I'd put the IsInRole or HasAccess style API in the business layer not just "in the control".

    Wednesday, March 5, 2008 1:01 AM

All replies

  • Do mean some way of enforcing that some users can edit or view some data in a record but not other data?  I suppose you are using some database backend?
    Monday, February 25, 2008 12:21 PM
  • Hi Den ,

     

    Yes you are right.

    i want to make access to every asp control based on user identity.

    can you tell me how to achieve this?

     

    Thanks.

    Tuesday, February 26, 2008 5:58 AM
  • There is no out of the box solution for this and there are many ways to implement this.   How are your users stored?  Is it all in AD or in a database or a combination of both? This will affect your path.  If all users are in the database, then you simply create security tables that contain which fields a user can view or edit.  This table would have a column for userID, the field name or ID, and 2 booleans for if they can view and edit the value.  Then on your form you would check for the permission on each field and restrict it accordingly.  You may mark a field as readonly if they have no edit permissions.  If they have no view permissions you may decide to not even show the field.

     

    Tuesday, February 26, 2008 11:44 AM
  • You could use role based permissions on the methods that the controls call, but this would have to be fairly specific to your situation.  You would have to handle the situation then to inform the user that they don't have permissions to perform the operation.

     

    You could check the roles before you render and disable controls based on that functionality, again specific to the situation, and possibly quite hard to test.

     

    Hope this helps,

     

    Martin Platt.

     

     

     

    Thursday, February 28, 2008 12:55 AM
  • Basically you can leverage the ASP.NET SQL role provider. You can additional tables where you can have fields / functions for which you want to contol the permissions.

     

    The table can have following fields : RoleId | Permission/Field ID | Allowed

     

    Here you can have map permissions through the boolean values in the allowed column.

     

    In the ASP.NET page, you can use the IsInRole method at the time of page loading and accordingly enable assigne true or false for the fields or you can assign visible true or false as required.

     

    For the function level, you can follow the same approach to visible true or false the function (Submit) buttons

     

    Thursday, February 28, 2008 1:24 PM
  • I'd add that I'd put the IsInRole or HasAccess style API in the business layer not just "in the control".

    Wednesday, March 5, 2008 1:01 AM
  • I actually just did this. But I wrote my security module from the ground up. To sum up what I did regarding object level security, I have a table that contains which controls a group has access to. On pre-render I retrieve the list of controls and the level of access the user has based on his/her associated group(s). I have a distinct list and I always return the highest access level for a control. 2 = enabled, 1 = disabled and 0 = invisible. I then recursively scan for all controls on the page and compare their object type to a list of known object types and add them to a dictionary (of string, object). The key is the ClassID (for uniqueness) and the value is a reference to the actual control. I then return my collection of controls and iterate over my list of accesses. As I iterate, i do a find() against my dictionary collection and when I find the control, I then set the controls level of access. It is actually quite simple. It only took a day to write.

     

    I will say that the toughest controls to manage are gridviews, menus and tabs. I use a third party provider, so my experience may be different than yours. But, when I want to secure an item within a menu or tab, I use a format like classid.item_name and I mark the control type as menuitem or tabpage. When I am iterating over my list of accesses, I check the control type to decide how to handle it. I handle tabs, menus, and all other controls differently. Menus require me to split the control name off of the dot and find the control by the classid. Then I scan the menu control recursively to find the menu sub item. Tabs are different in that you do not need to recursively locate a tabpage, but you do need to split the name up as well. All other controls can be accessed directly from the dictionary value and directly maniputated.

     

    I hope I didn't over complicate this.

     

    Hope this helps!

     

    Chris.

    Thursday, January 8, 2009 4:50 AM
  • IMO you might want to consider the security to the data rather than the controls themselves. If the control has no access to the data then it might not be shown but it is a subtle difference.

     

    Thursday, January 8, 2009 10:47 AM