Have any of you come up with a nice scheme to document the security in your objects? For example, I'd like to be able to be able to detail the security rights for "Controller", "Accounting Clerk", etc - listing by object which properties they have read/write access to, as well as the general 'CanGet/Add/Edit/DeleteObject' routines.
On small projects, it's not that hard to keep up with, but on larger projects, it's fairly time-consuming to do it by hand (and keep it up-to-date). The project I'm working on now has over 300 objects (and climbing) with 20+ roles.
Another way to look at this is to consider that AddAuthorizationRules can be data driven. So you could put the auth rules in a table or config file of some sort, and then load the values when the object is created.
Then you could just run your report against that table, because it would be the same auth rules as used by the object.
I think I might explore the data-driven approach. Haven't sat down and put much thought into it (yet), but I'm thinking I'd probably want a SecurityManager class that would cache all the security-related data from the database. That would prevent repetitive data-access calls during object creation. The individual objects would then talk to the SecurityManager instead of the DB directly.
From: Mark [mailto:cslanet@lhotka.net]
I think I might explore the data-driven approach. Haven't sat down and put much thought into it (yet), but I'm thinking I'd probably want a SecurityManager class that would cache all the security-related data from the database. That would prevent repetitive data-access calls during object creation. The individual objects would then talk to the SecurityManager instead of the DB directly.
Your sample code looks almost identical to what I've quickly thrown together as a proof-of-concept. :-)
The only gotcha with your sample - in the static CanGet/Add/Edit/DeleteObject methods, you can't reference 'this' (Me), so I'm passing in the object name instead. Already had a const defined in each class with the object name, so it worked out well.
This looks very promising - I especially like the idea that I'll be able to adjust the security behavior of the application on-the-fly without having to recompile.
Mark,
Search on Object Security on www.searchcsla.com. I have created something like this for CSLA 1.x and have been using this method on all my projects. Others have converted this to use database instead of xml.
This implementation works pretty good for company that I work here where security some times is an after tought and requesting global group could take weeks.
The design should be applicable to CSLA 2.0 version.
HTH,
Ricky
![Smile [:)]](/emoticons/emotion-1.gif)
.Regardless of how the list of rules is created, one thing to consider is to have your rules authorization method allow a rule to remain defined but be disabled at run-time (via a screen in your application).
This is very handy when doing demonstrations of your pre-alpha, alpha or beta code to your users and you discover that one of your custom validation rules has been coded incorrectly.
Pop up the screen, turn the rule off, and continue with your demo!
It's much better than having your users twiddle their thumbs waiting for you to recompile/re-install - particularly if you have to get a slow, lazy sysadmin to do the installation due to your company's security policies.
I'm new to C#. Currently using C# for my new application. I was told I could not use "this" in static method when I implemented the following.
RockfordLhotka:
....Public Shared Function CanGetObject() As BooleanReturn SecurityManager.GetSecurityInfo(Me).CanGetObject()' return SecurityManager.GetSecurityInfo(this).CanGetObject();End Function...
From: Mark [mailto:cslanet@lhotka.net]
I think I might explore the data-driven approach. Haven't sat down and put much thought into it (yet), but I'm thinking I'd probably want a SecurityManager class that would cache all the security-related data from the database. That would prevent repetitive data-access calls during object creation. The individual objects would then talk to the SecurityManager instead of the DB directly.
That's correct - you can't (you'd typically pass in the object type instead). Rocky's pretty much eliminated the need for this SecurityManager class by introducing class-level ValidationRules and AuthorizationRules in the forthcoming 2.1 release of CSLA.
However, remaining consistent with the concept of collaboration used within CSLA and throughout the .NET Framework, creating a SecurityManager class would allow additional features and functions not provided by the object-level methods presented in 2.1.
We've used this approach previously and are in the process of implementing again in the new version because we use many configuration settings to drive security, such as a master enable/disable flag and the ability to use "integrated" security on our apps, etc. Under this approach, as Rocky has shown, our objects delegate the security checks to the SecurityManager which encapsulates all of the logic for the requested operations. Of course, this can always be overriden when desired in our business classes.
I would only recommend this if there is some valued added by a separate SecurityManager class; otherwise, as you've said, the 'built-in' object-level features do the job well.
Copyright (c) Marimer LLC