I'm currently developing a Csla solution using 3.8.2 and was wondering if authorization was more flexible/customizable in Csla 4.0.x. I have to work with complex auth/validation logic and the line between what is considered authorization or validation is blurry.
I started by reading this post http://forums.lhotka.net/forums/p/8011/38573.aspx#38573 but I don't think my scenario was addressed very well.
The basic scenario is that we have multiple levels of authorization to manipulate this one particular business entity. All levels can view the object but varying levels can edit varying properties. What makes it more complex is that certain levels can edit a property up to a certain range and another level can edit the same property a different range. So at which point is editing the property an authorization issue or validation issue. I would like to be able to display a validation error if the user changes the property outside her range (so that's validation right???).
Has anyone ever written authorization rules in validation rules? It can be done but is this an "ideal" solution?
On top of that, after the object is instantiated, the application should be able to "promote" credentials which should reset the authorization for each property. How can you do that after the AddAuth method has been called?
I'm starting to think that I will need a custom solution to meet my needs. I was thinking about creating or hooking into an event that would fire if the principal changed. The business object would handle that event and then call a method to resync the auth rules based on the new roles. We expose public properties to the UI that define the before mentioned allowable ranges for the current user (MaxValue, MinValue) and these properties are bound on the UI which would need to update automatically.
Before creating a solution that accomplished this I was curious if someone else out there has a similar need and solved it using the existing framework.
Thanks,
Brett
We are using CSLA 4 on my current project. Our requirements are very similar to yours. To illustrate these requirements, let's say that I have business objects for Widgets. Each Widget has several properties. The data for a given Widget may come from different sources. We have a process, WidgetCrunch, that needs all of this data to perform its calculations, but we want to restrict the access to the data. Data about Widgets that originates from local sources may be edited fully. Data that comes from some external sources may be viewed in a read only mode. Other data may come from sources that, although the data is stored locally, we never want the user to see. To make things more interesting, the local application may have different user logins that each have a authorization that allows different types of access.
For example, Abe may be able to edit his own data, see the data from Private Stuff, Inc. but not see the data supplied by Secrets, Inc. Bill might be allowed to edit the data from Private Stuff, Inc. and to see the data from Secrets, Inc. but not make any changes to it. Carl may be allowed to edit the data from Secrets, Inc. but only see the data from all other sources.
To make this work, we have created a desktop application that contains what we call the "execution context". This holds a variety of indicators and values that come from the login and from actions taken within the application. We have also created an authorization rule that supports the "can read property" and "can write property" functions. We apply this rule to each property in AddBusinessRules method. We also override the CanReadProperties and CanWriteProperties; this is needed prevent CSLA from caching the status for the class as a whole (something that we do not want to happen). In the rule, we examine the target Widget object that is passed into the rule and the state of the execution context to determine if the user can read or write the individual property value.
A similar tack can be taken for the validation rules. I would argue that the validation rules should be wholly separate from the authorization rules. The validation rules can also be applied to the properties of the object and can take into account the "execution context".
While this is not trivial, CSLA 4 will definitely allow you to handle this situation, given the approach that I have outlined.
Jon Stonecash
It sounds like your scenario is slightly different in that if the user can edit a property they can edit it to anything they want as long as it doesn't break a generic validation rule.
My problem is that the user can edit the property however their role determines what they can edit the value to.
For example Abe can edit the property Price but can only set it to values that his role allows ($1 - $100), if he tries to change it over $100 then the system will prompt for an override user to login, that user should be able to edit the property from ($1 - $500) and so on. So it's not as simple as "this role can edit this property" which is why it's hard for us to clearly separate validation logic and authorization logic.
The validation rules can certainly take into account data about the user to determine what is valid and what is not. That is, a user at one level can do something that would be invalid done by a user at another level. We are doing something similar.
The one place that you might have some problems is that CSLA takes the approach is that the user can store anything they want into the object. At any point in time, the object is either valid or not valid. That is, the contents of the object satisfy the validation rules or they do not. An object that is not valid cannot be saved.
There are a number of ways that you could handle the invalid state. The most common is to return an error message as a part of the rule evaluation. This message can be presented to the user as a part of the UI. That message could alert the user that a different login (or whatever) was needed. You could add a property to the business object that indicated that the object was not valid because the user level was wrong. The UI could detect this problem and bring up an appropriate dialogue. If the user then changed the execution context (additional log in, magic incantation, etc.), the validation logic would then return a (possibly) different result.
Note that the CheckRules would have to be re-run for each object in question. This does not happen automatically.
I think that you will find that CSLA 4 can handle your situation.
Jon Stonecash
Copyright (c) Marimer LLC