Chaining authorization rules?

ajj3085 posted on Tuesday, March 10, 2015

Is there a supported way to chain authorization rules?  There's no GetChainedContext method, and I'm ending up having to write a new class for each unique set of permissions I need.

JonnyBee replied on Tuesday, March 10, 2015

Hi,

No, you cannot chain but you may subclass authorization rules or call other rules/logic from within the Execute method.

There's only one purpose for an authorization rule and that is to set context.HasPermission so there is no need for a GetChainedContext. 

ajj3085 replied on Tuesday, March 10, 2015

I though chaining was required to be able to call other rules but if that's not the case i'll go that route.  It might be nice to have Csla offer some auth rules to combine other rules (like and / or rules).

JonnyBee replied on Wednesday, March 11, 2015

Hi,

I believe it was a design that was built in to CSLA to ensure that authorization rules should be considered singeltons and be quick. Especially for propery level rules the rules will be called many times during databinding.

I find my preferences to be:

• use the builtin authz rules for role based authorization (only called once and then cached)
• override CanReadProperty / CanWriteProperty / CanExecuteMethod for the property level rules where I have business logic that dictates whether a field should be read/write or a method may be called. 
• use custom authz rules for Create / Get /Edit / Delete actions when needed.

ajj3085 replied on Wednesday, March 11, 2015

I understand the design decisions but sometimes authorization is complex.  The current project I'm working the caching is actually an issue because a users permissions can change based on the organization they are currently in. 

I also much prefer classes to represent auth rules over putting the code in CanRead/Write/Execute methods.  Code in the CanXYZ methods tends to end up a giant switch statement and the logic can easily become convoluted and hard to maintain.  Its possible to avoid that if everyone involved has a high level of discipline, but I've found that's often not the case including for me.  We have some pretty complex auth rules which often take into account the current state of the object they are applied to.

Pulling the code into classes helps with this a lot and makes unit testing the auth rules much simpler.  In the project I'm working on we just moved from Csla 3.8 to 4.5 and the business rules (including auth) becoming classes to me is by far one of the biggest benefits of Csla 4 and the first thing I always point to when talking about Csla.