The application in question is a fairly extensive with many different types of access roles (read Customer Service, HR, Admins, etc etc). Tiered access, so each role inherits the access below it, so HR has Read Only, CS has edit abilities, Admins full control. Menu bars and buttons enable/visible attributes are controlled by an outside an outside library that handles all role-based access via reflection. The man who wrote this was an evil genius.
That being said, I'd like eventually to remove it. The knowledge base on how it works left with him years ago, and development on this application is starting to stagnate since the documentation on the security 'suite' is awful. Everything is stored within a database, down to label visibility for each label. It's a bit overboard and not refactor-friendly.
I've spent a solid amount of time looking into windows forms security. We're running our own user/roles for this app rather than Active Directory. I'd like to use User/Principal, since that looks like the best option. If there's another option, I'm open to advice, I'd like to see this done the right way since we're considering a full rewrite (unrelated to this).
All the searching I've done through MSDN and other websites has led me to believe that I can only control flow through methods and classes based on roles, not as granular as "enable this button" or "hide this menu bar."
Is there a better way than doing something along the lines of:
btnA.Visible = Thread.CurrentPrincipal.IsInRole("HR");
btnA.Enabled = Thread.CurrentPrincipal.IsInRole("CS") ||
Thread.CurrentPrincipal.IsInRole("ADMIN");
Is there a better way in general? What's the best way to handle this?