tags:

views:

173

answers:

4

I'm writing a GUI application that will have a user log in feature. Each user will belong to (at least one, possibly more than one) group and each group will have attributes indicating if certain rights are allowed or not allowed. The list of rights will cover things like editing things from the past, printing, deleting data, etc. Lots of different actions can be handled by the same right (printing can be initiated both from the menu and from the toolbar, for example).

My question is: what is the best way to implement this security system? Should every action have a Boolean isSecurable attribute and list of rights required? How should the checking be done, by a central structure, or should each action check for the required rights itself?

I'm aiming for correctness here. I know I can hack together a working system quickly but I'd like to have something that won't cause problems down the road. I'm sorry for the verbose explanation but I'm not even sure what to call what I'm looking for.

Edit: This isn't really GUI-specific, I think, but I've researched quite a bit for info on this and most of the stuff I find is for web applications, or general "secure programming" tips.

+1  A: 

I'd go with something like an MVC system and put none of the security stuff in the GUI code. Make it a part of the model so that it doesn't mater how the user triggers an action, the same security code path gets run.

I've never done much GUI and even less security stuff but one approach would be to have a secure proxy object that keeps track of who is logged in and only forwards requests that are permitted in the current context.

If you want a fun project, that proxy object would be a good candidate for generated code:

Given an interface with security annotations, generate a class that implements that interface and blocks/forwards calls based on the security context passed to it.

BCS
+1  A: 

If you will be writing a .NET application you could consider using the membership provider infrastructure. You can even use this approach to implement authentication for both web and desktop clients as described in this MSDN magazine article.

Yordan Pavlov
Security Rule #1: Don't role your own.
BCS
+3  A: 

"BCS" is correct that the security checks should not be tied to the GUI, that should be tied to the underlying actions/operations/methods you're invoking. In an MVC framework, that would be in the Model, or elsewhere, in the actions invoked by the Model.

If the dispatching of your actions is certain to pass through some common mechanism (e.g. all share a certain base class), then putting the security checks there is a good way to cover all the bases.

One additional thought: What you describe as groups may or may not be "roles" in security terminology.

Liudvikas Bukys
How would you handle a right such as "View user rights"? If a user is not allowed to view user rights, the dialog should not even open. Should the dialog attempt to open the security settings, and display an error message on failure?
rmw1985
No simple answer to whether have a right to enumerate rights.
Liudvikas Bukys
For disabling menu options that a user doesn't have rights for, then you are back to attaching lists of rights to UI actions as you originally suggested. Go ahead, but that information is scattered around, and tends to "fail open", so don't depend on that for enforcement.
Liudvikas Bukys
Do enforcement in a small clean interface layer to ensure that all code paths are covered.
Liudvikas Bukys
Thanks for your help. I have a lot to learn about this, but you've got me down the right path.
rmw1985
A: 

Your problem sounds like the State Pattern. Each group that the user belongs to is a different State Object. Attach each applicable State Object to the user. Then, when the user tries to do something that requires a right, ask the state object.

Since a user can be in multiple groups, you might also benefit from the Decorator Pattern.

geowa4