Rocky,
I am working on my authorization logic for my project with CSLA 4 (fresh beta 2 bits downloaded this morning). The authorization framework is a (more or less) a claims-based framework. A CRUD operation may be authorized based upon a combination of items. Most of these items are drawn from database tables based on user identity but some are based upon the current context. Moving from one part of the object hierarchy to another turns things on and off.
My original cut at working through all of this was to create a single authorization object that was aware of all of this complexity. This has not worked because the context passed into the rule does not specify the type that triggered the rule execution. My common rule cannot figure out the type of the object that is to be authorized.
The framework knows the type and uses it to look up the rules for the type. My request is that the triggering type be passed in as part of the context. That way I could use a single object that could be type sensitive.
If I have understood what is going on, without this change, I would have to create four different rule objects per type (CRUD). I could obviously include a reference in each of these objects to a common object that would do all of the heavy lifting. Composition and delegation are your friends! But it would be more elegant in my mind to have the framework let the rule in on all of the details of the rule invocation, including the object type.
Any possibility that such a thing could be done? Or perhaps a learned explanation of why my brain. after 10 hours banging away at this, is fried and should be re-booted?
Jon Stonecash
That is an oversight on my part - I totally agree that the type should be provided via the context - I'm surprised I didn't do that - I'll add that value in the next release.
Rocky,
Thanks! Just to clarify things, I am looking at the CanRead, CanEdit, etc. functionality. Although I have not gotten to it yet, I am assuming that the rules for properties and methods will pass the target object from which I can derive the type.
Jon Stonecash
The context already had a Target property, which is set to the actual business object whenever possible. So per-property rules get that, and per-type rules might get that value (like for update scenarios), but sometimes it just isn't available (like with cancreate scenarios).
The context will now have TargetType as a property, which will always be set to the type of the business class/object - this will be true for per-type and per-property rules.
Thank you for that.
I spent some time digging into the CSLA code related to authorization. I am confused by a couple of things. Each rule must implement IAuthorizationRule. This means that the rule must have properties for the Element and the Action. Each time that the rule must be applied, Csla uses the object type to find the AuthorizationManager for that type. The AuthorizationManager, in turn, uses the element and action to find the relevant rule within that object type. It then constructs a context that includes the element and the action and passes that to the Execute method.
But, isn't it the case that CSLA is telling the rule two things that the rule already knows? There does not seem to be a scenario in which the rule would be invoked for a different action or different element. Am I missing something important here?
Jon Stonecash
I'm not sure I follow you. The AuthorizationContext has Target, TargetType and HasPermission properties. It does not include the element or action, because those are already part of the rule.
My bad. I said I was confused. Boy, was I confused.
In any case, I have my object and property authorization logic working. Just starting on the method authorization, which should be a fairly simple variation on the property authorization.
Copyright (c) Marimer LLC