Access Control Logic – Better Ways to Handle Instead of in the UI

Architecturecdatabase-designSecuritywinforms

Through most of my dev experience, I've never had to deal with much variety of access control architectures.

They've all been pretty straight forward:

Group [Create, Update, Delete]
    - User 1
    - User 2

Group [Update, Delete]
    - User 2

Which, for all intents and purposes, works well. The problem I have is the actual implementation of it. All the solutions I've worked on either grant/deny the visibility of a menu link, or disable a button etc. This is all controlled via the top-most layer of the app, whether it be a WebApp or WinForms UI.

I'm in the early stages of designing a rather large WinForms system so I'd like to get the security architecture right from the beginning.

Although I don't see myself getting away from visually limiting the user from performing certain actions (by disabling restricted controls etc), I'm sure there are better solutions available then doing most of the work in the UI.

As I understand it (and these might be limited by my ignorance), these are my options:

  • Put the logic to return and verify user rights in the business layer
  • On the form_load event, get these rules and enable/disabled UI elements
  • Leave the UI elements in tact and halt the operation from within the business layer if the user doesn't have permission for the action (dirty!)

Surely there must be more elegant solutions than this.
Could someone please provide me with alternatives or improvements to the aforementioned ideas?

Am I thinking about it incorrectly? Should I re-evaluate my database design while I'm at it?

Best Answer

WPF strongly encourages using the Command pattern, which encapsulates the logic for a given button press or menu item into an ICommand object, rather than as a code-behind event handler. The interesting part of these objects is that, in addition to the standard Execute method, also has a standard CanExecute method, which determines whether the button is enabled or not. This method can be used both by validation logic and by the permissions layer to determine whether the UI element is active.

This allows the permission logic to be "server-side", as part of the business logic, and have the UI element's visibility, "enabled-ness" and functionality linked to it using data binding, rather than manually going over the UI elements and enabling/disabling them.

This fits in with WPF's general philosphy of using the MVVM pattern, using data-bindings between the UI and the back-end view models to hide all that ugly "check the permission level and set the button's property accordingly" boilerplate logic.

Related Topic