replacement for 3.8.x 'deny' auth rules in 4.x?

replacement for 3.8.x 'deny' auth rules in 4.x?

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


vschaak posted on Friday, October 07, 2011

Hi,

I'm updating an older 3.8 CSLA project to CSLA 4 which uses deny... authorization rules used beside allow-rules.

Unfortunatly actually I'm unable to find something comparable in 4, where all auth-actions are allowing, none denying. (and IsInRole used beside IsNotInRole results in an exception...)

Is there any chance to save this part of logic?

Thx for answering

Volker

JonnyBee replied on Friday, October 07, 2011

Hi,

One of the requirements for CSLA 4 Authz rules is that there can be only one rule per AuthorizationAction and Object/Property/Method.

IE: there is no provision for having Deny rules taking priority over Allow rules. There can be only one rule.  Hence there is no Deny actions.

 

vschaak replied on Saturday, October 08, 2011

Hi Jonny,

 thanks for your answer.

Unfortunatly this means to rewrite our auth-logic, where permitting and denying elements existSad

Our business case is to mostly assign permissions to users by giving them certain roles which incorporate permissions. But if the security-admin want's to deny a certain functionality for a specific user, otherwise incorporated into a role that he is in, without creating a specific role for this case ('User A should have all the rights members of role 'manager' have, except doing this specific thing'), the admin can 'give' the user a certain denying permission, which leads to the user not beeing allowed to perform the excluded functionality.

That was exactly the reason we used deny... security actions. My workaround now will be to exclude the "denied permission" as I fetch the list of permissions for the specific user from my security repository.

Kind regards

Volker

P.S.: Will you please have a look at the thread concerning localization/accessing ressources again, since Rocky says, you're the one with the best knowledge on that? Thx

Copyright (c) Marimer LLC