Data driven authorization rules

PStanev posted on Tuesday, October 24, 2006

Hello,

 

I’m trying to have a data driven authorization rules for 16 different roles, 14 different types, 6 different stages, 10 different status and about 50 business object properties. (The business objects Inherits Csla.BusinessBase.) So, authorization rules (Edit Enable, Required, Blank, Visible) for each of the 50 object properties has to be different and depend on the role, type, stage and status.

 

So I created a few tables with many to many relationships and one table with rules for each of the 50 object properties for the different roles, types, stages and status. I’m planning to read this rules table for each property, passing the current role, type, stage and status.

My question is:

Is this the right way of doing this? Is adding authorization rules in the business object code (AuthorizationRules.AllowWrite("Name", "ProjectManager")) the right way?

 

Please advice which is the better way in my case!

PStanev replied on Friday, October 27, 2006

The reason I put all the numbers in the question is, to show that I have multi dimensional truth table with a lot of authorization rules. Will be hard to enter that many rules in the, business object code.

So, what is the best approach for this case? Please help.

Bayu replied on Friday, October 27, 2006

Hey PStaney,

Your approach sounds quite right to me. My guess is that you get all the rules that apply to a particular object with your dp_create and dp_fetch methods (make sure you remove the RunLocal attribute from dp_create).

I think I would manage all the actual implementations in a separate singleton class (SecurityManager or so) where a particular rule from your database gets its programmatic implementation.

If you want to be smart, then exploit the capabilities of reflection as much as possible, but I guess that this was your intent already.. .

One thing I don't immediately understand is what you mean by 'stage' and 'status'. In my (perhaps simplistic ;-) ) perception you would only have objects and properties on one side and your security roles on the other, which would imply only 2 mapping tables (i,e, many-to-many relations). What do 'stage' and 'status' mean in your case?

Also, how come you have 16 roles? That's quite a lot, I never managed to come up with more than 5. What kind of application are you building? Just curious.

Kind regards,
Bayu

PStanev replied on Friday, October 27, 2006

Hey Bayu,

 

Thank you, for the reply. I'll try to implement getting the rules from  DB with SequrityManager. Status and stages are different dimensions which reflect on the rules. They are different stages and status of the process we are tracking data for.

16 roles are because there is a long approval process and different roles can contribute to the entire process.

 

Regards,

P Stanev

Bayu replied on Friday, October 27, 2006

Hey,

It sounds like you are merely in need of decent workflow control than advanced rule management. Although the two will probably yield the same end-result.

Maybe it simplifies things for you when you look upon your use cases from a workflow perspective. Your terminology with roles, stages and statuses may fit more naturally. I have no ready answer how the workflow paradigm would be made explicit in CSLA, never had to deal with that, but it is an interesting case. .

Good luck,
Bayu

RockfordLhotka replied on Tuesday, November 07, 2006

What you propose seems reasonable - though relatively complex.

If you are, in fact, doing a workflow, then you might consider that each step in the workflow is its own use case. As such, you should apply OO design to each step in the workflow, designing a set of objects for each use case (step).

Only after you've done that design work should you decide whether you can consolidate some of those objects across use cases.

What you appear to be doing is creating a singular object that spans all your workflow steps. That is leading to a lot of complexity, at least in terms of authorization - but I'm guessing elsewhere too. And that is exactly what good OO design should help you avoid!

PStanev replied on Tuesday, November 07, 2006

Hello Rocky,

 

You are right about the workflow. I was originally thinking about using singular business object to address all the authorization rules for each step in the process. My idea was to put all the rules in the database and then get a set of rules in to the business object, depending on the step in the process, and the role which is interacting with the object. It’s getting so complex. From the numbers I mention, earlier in the thread I end up with about million and a half records in the DB represent each field at each role, stage, status etc. Not big dill for SQL server, but populating and managing the rules would be a significant task.

What do you think about “Windows Workflow Foundation”? Can it help me in my case of workflow? Can it be used together with CSLA framework? Are there any examples of doing this?

 

Regards,

PStanev

ajj3085 replied on Wednesday, November 08, 2006

WWF is pretty new, I'm not sure many of us have a lot of experience to help guide you.  There was some dicussion around it on the forum, just do a little searching and it should turn up. 

RockfordLhotka replied on Wednesday, November 08, 2006

PStanev:

What do you think about “Windows Workflow Foundation”? Can it help me in my case of workflow? Can it be used together with CSLA framework? Are there any examples of doing this?

I don't know of any examples. Certainly you can create WF activities that use CSLA .NET objects within the implementation, and that makes a lot of sense. You can also use a CommandBase-derived object to launch a workflow, and that too makes a lot of sense.

Technically you can also do things like expose a CSLA object as a property of an activity, thus making the business object subject to serialization if the workflow is suspended. In my discussions with the WF team on how this works, I think it is a very bad idea to do such a thing, and so my recommendation at this point is to keep CSLA objects private within activities.

(in fact, they use the BinaryFormatter to serialize the workflow - and as a side-effect, if you change the assembly for any type exposed as a public property from an activity you may be unable to rehydrate the workflow when you want it to resume - this is due to the versioning sensitivity of the BinaryFormatter, and is a problem not unique to WF, but they incur this limitation by using that formatter to dehyrdate the workflows on suspend)

jcbodine replied on Wednesday, November 08, 2006

i am very interested in this subject as i also have an application requiring workflow.  i understand rocky's statement that separate bo's should be used for each step, however, many of these bo's have a one to one relationship.  so, is it better to build 1 big bo, and only use parts of it for each workflow step or use many bo's and have a "parent" bo that has many 1-1 children?

RockfordLhotka replied on Wednesday, November 08, 2006

Remember that the idea behind workflow is that each activity is atomic. A business analyst (or someone) can, at any time, rearrange your workflow, changing the order of activities, or adding and removing activities in the middle. That's the whole point.

So you can't intrinsically link your activities to each other behind the scenes, or you pretty much entirely undermine the whole value of workflow. In reality this means that each activity must be treated as a singular use case - and thus should have its own set of objects.

As always, once you've designed the objects for all your use cases, you can examine them to see if there are exact duplicates between use cases (in terms of responsibility and behaviors), and if so then you can reuse that object across use cases.

So no, I would not start into a workflow project with the idea of building one object graph for the whole workflow. Each activity must be treated as an atomic, independent entity to achieve the real goals of workflow.