any way to make deny... stronger than allow... Permissions?

any way to make deny... stronger than allow... Permissions?

Old forum URL: forums.lhotka.net/forums/t/8379.aspx


vschaak posted on Tuesday, January 19, 2010

Hi,

in my security model, which is permission-based (but somehow "wrapped" in a role-based manner, so IsInRole retrieves whether a user has certain permsissions), I manage allow AND deny permissions.
So one can assign a user to certain roles (which have defined permissions), but deny a certain permission explicitly. By that my app-admins have a high level of flexibility.
Now I'm struggling with making the denyGet stronger than allowGet. Unfortunalty CSLA seems to favour allow over deny in CanGetObject. Is this right?
So, what to do?

Thanks for any hints.

Greetings

Volker

triplea replied on Tuesday, January 19, 2010

Hi

In one of my quite large apps I had similar requirements (I think). I mainly wanted everything to be denied (CanRead/Insert etc as well as edit properties). The steps i took were:

1. Use custom Identity with a bool HasPermission(string permissionName) method (although you can use IsInRole or extension methods as explained by Rocky and other forum members respectively).
2. In all my objects I have placed my hooks (e.g. Customer.CanRead() would just return the result of passing the parameter "ReadCustomer" to the above method).
3. Any logic of what the user can read is implimented in the custom identity (or rather a seperate class injected to my custom identity).

I am not sure what your question is though. Are you not sure how to implement the deny/allow conflicts or do you want to avoid placing calls to your security model on all your objects? Or something else?

vschaak replied on Tuesday, January 19, 2010

Hi,

thx for answering.
Let me explain it a bit more:
My Identity-object has a list of roles, which is in fact a list of permissions. In that list a specific Identity can have the 'roles' denyViewThis AND ViewThis, which allows/denies the user to view(get) objects of a certain type (This). As long as users only have DenyGetThis OR GetThis all works as expected. But if a user has both of them, I just want the deny-permission to take effect, not the allow-permission.

The reason is that my security model allows admins to assign users to certain roles, but also to drop certain permissions (otherweise granted mainly by the role assignment) by adding deny-permissions.
In other words: all functionality that could be granted could also be denied. And no grant should take effect on a specific user if there is a deny-assignment for that functionality.
AllowGet and DenyGet (in conjunction with CangetObject) work that way in both cases , but only until not BOTH apply to the same user. In that case it seems that allways the Allow-permission takes effect.

Hope I made my case somewhat more transparent!?

Thanks for your time

Volker

triplea replied on Tuesday, January 19, 2010

Assuming that it is possible to distinguish that permissions DenyViewThis and ViewThis are related (opposites in fact) isn't the solution to your problem as doing the following:

  1. Load your permissions (presumably from a database, XML or whatever)
  2. Load all allowing permissions (including ViewThis)
  3. Loop through the denying permissions (including DenyViewThis). For each one of these, remove the opposite (e.g. when encountering DenyViewThis in your loop, remove ViewThis). 

The bottom line is that if someone should be allowed or not to view something is just business logic. You can implement all this logic in your custom identity/identity provider.

Also, take a look at this: http://www.lhotka.net/weblog/PermissionbasedAuthorizationVsRolebasedAuthorization.aspx

Might be of help.

vschaak replied on Tuesday, January 19, 2010

Hi,

indeed your approach would be a solution. It could be done in the DP.fetch method. Another one could be to load only the "not-denied" permissions from the DB, which would cause some refinement to the sprocs...

I read the blog entry and yes it was of some help!

Thanks again

Volker

Copyright (c) Marimer LLC