Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com May 13 '13 at 20:16

This question came from our site for professional and enthusiast programmers.

1  
Separate the Admin Role as soon as you can. personally i would put it into a completely separate class because an Admin has a completely different Role. also i just kind of realized - separating this out also makes your view files easier to maintain. as soon as your view files are trying to serve two different audiences - with a lot of security implications - you greatly increase the time required to test any small change to the view files. –  cartalot May 13 '13 at 20:41
add comment

3 Answers

up vote 3 down vote accepted

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.

share|improve this answer
add comment

What you've described is pretty much what you'll need to use. (Sorry)

Consider treating each major section of your UI as modules / separate forms. Then have a parent form that can be used to control whether or not particular children forms will be loaded based upon your business logic.

This would allow you to keep the access control logic within the business logic layers and only minimally rely upon code-behind. This layer of authorization checking could be limited to coarse grained show | disable | no-show type decisions.

As the winform app will run on a system outside of your control, you'll need to have additional degrees of checks within your business logic that provides an interface to your database layer. This is where you would apply finer grained authorization checks.

Finally, consider using WPF instead of Winforms, if you can. WPF is better structured to facilitate your presentation pattern of choice (MVC, MVVM, MVP, etc...) than what winforms natively provides. You can still write a secure app with winforms, it just takes a bit more effort.

share|improve this answer
add comment

I think you're looking for the Model View Controller pattern, or some slight variation of it. As far as security goes, there is more information here: http://stackoverflow.com/questions/2543639/design-patterns-for-security-and-data-access-control

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.