1

I'm trying to implement a claims-based authorization setup using Web API/OWIN/OAuth and I'm trying to find out the best way to manage a more fine-grained type of authorization.

I don't like the idea of using just roles, as there needs to be lots of fine-grained authorization in the application I'm working on. I was thinking a roles+permissions approach made more sense (where a role simply maps to a subset of permissions). The permissions would be based on an action+resource pair (e.g. CanViewEmployee, CanEditEmployee, etc.). Nothing out of the ordinary here.

However, I'm wondering how this should be implemented using OWIN/OAuth, possibly using Thinktecture IdentityServer. I am trying to avoid hard coding the permissions in the custom AuthorizationManager I have as they need to be easily changed without a rebuild. I know it is an option to put these as policies in the web.config (mapping a resource+action to a claim type and value), but if we are talking about dozens, maybe even hundreds of permissions, this seems like it could get out of hand pretty quickly as well.

I guess the third option would be to drive it all from the database, but managing it from there would also need some kind of front-end to do so, which is more effort than just changing a config/XML file.

Am I missing some other options/best practices here when it comes to large numbers of claims/permissions, or perhaps some other utility or package I could use to help manage this when the numbers get out of hand?

pepo
  • 8,644
  • 2
  • 27
  • 42
ChrisC
  • 1,161
  • 12
  • 26

1 Answers1

0

Decoupling these permissions into a separate authorization manager class is a good first step. In that code you could then hard code the rules for your permissions (such as "Admin" role can do action X, Y and Z, but only "Manager" role can do X or Y). But you can also have the code in the authorization manager perform dynamic look ups to check permissions that have been set in in a database (for example).

The additional benefit of doing this in code is that you can unit test it all to prove your permissions logic is implemented correctly (and thus will be properly enforced at runtime). This will be useful if your permissions do change frequently.

Also, the decoupling will help if you need to redeploy frequently (because of the frequent changes), since the code can be isolated into its own assembly.

Brock Allen
  • 7,385
  • 19
  • 24
  • Right, I understand that, but I'm trying to figure out if this is the best way to manage LOTS of permissions. I want to avoid doing it in code to avoid code churn and rebuilds when the permissions (inevitably) change, and to avoid having hundreds of lines of code with rules, so I've been leaning toward doing it in the DB so that we could change them dynamically via a management screen. I just wanted to make sure I wasn't missing something, and that there wasn't a better option out there. – ChrisC Oct 17 '14 at 15:40
  • Updated to add benefit of unit testing and isolation for frequent updates. As for the permissions changing frequently -- hard to say. Perhaps those should be flags in a DB rather than in code. – Brock Allen Oct 17 '14 at 16:58
  • Yeah, I'm certainly leaning more toward DB. Thanks for the info! – ChrisC Oct 17 '14 at 17:54