Obviously from the title, I am planning on implementing a role based security for our accounting application. I was just wondering if anyone here uses this type of security system?

I found this article on MSDN:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconintroductiontorole-basedsecurity.asp

It uses principal and identity objects to achieve this. Does anyone take advantage of these classes? Where do you implement the security check? I was thinking about adding a Security Facade before the BL (flow would look like this: PL -> Webservice -> WS Facade - > Security Facade -> BL) Any ideas? Comments? Thanks!

We use Role based security extensively, I personally don't see how you could create a layer that was just security that didn't violate seperation of business and gui layers, but maybe someone smarter than me here has an idea.

What we do:

We created our roles within Active Directory and placed users in groups, then using a security class I wrote we test if they are in a particular group before enabling or disabling various features of our application.

The security object that has all hmm 200ish roles in our company defined, and has 2 different modes, one for the actual current user (using Principal/Identity) and one for impersonating a user (Active Directory calls) used for developers and support to be able to test 'as' a user without having their actual logins.

A developer only needs to change one static variable on the security class and define the user he wishes to impersonate, and the class switches from Principal to ActiveDirectory behind the scenes.

We use the security object primarily in our business layer to limit columns, update, read etc. privildges of our business objects, it is also called from our GUI to enable/disable menu options or to make a form read only etc.

John

I was just unsure how ASP.NET handles threads. The BLL is on a webserver, so all the Principal/Security info is on the server. I wanted to pass in a username/password, and have the server create all the security info, and assign it to a thread on the SERVER. Just not sure if other clients will cause the thread to switch roles or users, or if ASP.NET creates different threads for different instances. I hope that makes sense.

Well thats a bit more complicated, you could use something like what I use and pass the username and do Active Directory lookups in your business layer if you are wanting to enforce roles.

On the other hand if you are wanting to enforce it in the DAL layer, i.e. tables permissions, token passing can be tricky.

If say the web server and sql server on the same machine (should be shot if so) it all works out of the box.

But if they are different servers (as should be =) then you must turn on an active directory feature for all servers involved to 'trust' security tokens, I forget the exact location etc where to set it up, but by default a security token passed from one server to another is not trusted unless this feature is turned on.

This is a common problem of executing sql code from asp.net using Windows Identification and using SSPI connections.

John

Skeeterbug wrote:

I was just unsure how ASP.NET handles threads. The BLL is on a webserver, so all the Principal/Security info is on the server. I wanted to pass in a username/password, and have the server create all the security info, and assign it to a thread on the SERVER. Just not sure if other clients will cause the thread to switch roles or users, or if ASP.NET creates different threads for different instances. I hope that makes sense.

Hey, there. I haven't personally implemented a security system in a web context before, but I've think you should consider AOP (Aspect Oriented Programming) for your security system.

The concept is that security is an independent service to be applied irrespective of the tier it's needed. Thus, security could/should be managed independently of the method calls that require its services - the methods themselves may not even need to know about security.

The AOP implementation in this case would consist of methods being decorated with a specific attribute that let the security system know that the method's activity is subject to security restrictions. Then, via interception, the security system is given a chance to act before the method is called and block if necessary, or after the call and perhaps encrypt the data stream. No more "If principal.IsInRole("Admin") Then..." in every method call...

I'm definitely not a guru on the subject (although I'm excited about AOP and I'll be implementing a similar system soon), but I figured it'd be good for you to at least know about it before you got started so you can make an informed choice.

Here's some links on the topic:

http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/ Osherove's Interception Framework

Hope this helps.

Jeff...

This seems like it would work OK in an enviornment without a huge number of roles, i.e. Admin, Supervisor, User, but in a real world environment I don't see how this would help you in the GUI, or in applying different rules to different groups of users within the same method, if as in their example you used COM objects we would have over one million COM objects to statisfy our rules.

Marking a procedure as to who can call it is one thing, but lets say in the same procedure the validation rules a value for maximum discount a user can use, a telemarketer might be able to apply a 10% discount, his supervisor might be able to select 12.5% and his supervisor 15% and the head of sales can use any arbitrary value that is not greater than the cost of goods and this is just one rule for a method, given our average 30ish rules per method, AoP would get very cumbersome imo.

It's kind of like Model View Controller, on the surface it looks nice but once you get into what I consider a real application it creates so much overhead and complexity that you could of gotten it done in 1/10th the time for even the smallest change using any other method, I think the same thing about many of the MS Framework examples, so over engineered and reliant on the config file that any moron with a text editor can crash your application or so complex and bloated that features you don't need get in the way of what you are really trying to accomplish.

To use our business as an example, our database is run on 3 8-Way clustered SQL Servers with aprox. 8 terabytes of storage, supporting HR, Accounting, IT, IS, Telemarketing, Sales, Installation, Purchasing, Credit, Marketing, Warehouses and a department per product line, which comes out to about 2500ish employees. We support this with a total of 8 developers (4 on our in house app, 2 for telemarketing and 2 for accounting) and 2 report writers.

We have a big corporate style budget but we respond like a small hungry company, i.e. we don't live for meetings, scoping projects, and playing the cover your ass game, we get requests and bug fixes in on a daily basis and only large projects are actually scheduled, most users get near instant response on issues for their department and their ever changing rules and god do I mean ever changing =P that not only vary by department and user but by region of the country a given sale is happening in.

There is something to be said for the KISS method of programming =)

As in life no one solution solves any problem no matter how much you try to abstract it i.e. AoP, MVC, etc. Even my favorite tool LLBLGen isn't a tool that meets every need, I am constantly working on little hacks to create a new predicate or jump through a hoop to get something done, but in the end it's code generation to provide the DAL saves me time, but may not save someone else time.

John

Hmm kind of miss posted that, it was meant for another person on the same topic i.e. AoP programming, but I guess it applies here too, guess I should watch which window I am posting too /grin.

John

Hi, John. I actually agree with you and disagree with you at the same time.

One of the problems with AOP is communicating context. Exception handling is a good example. When people just start hearing about AOP they hear how great it is for exception handling - and it sounds great. The problem is that handling exceptions properly depends highly on the context in which the exception is thrown. It can be harder/more cumbersome/messier to communicate context in an AOP solution than not.

That being said, in terms of implementing AOP for security, assuming your public interface members are mapped well to business processes, the methods themselves should give enough context as to what is trying to be accomplished. In other words, if your interface members have names like ".DoStuff()", then AOP probably won't work for you. But, if your members have names like ".PlaceOrder()" then I would think theoretically there's enough information in the method name and the arguments themselves to test properly for authorization.

I don't think using AOP for validation or rules is a good idea because, like you said, you can have multiple rules/contexts inside a given method - something that would make it very difficult for AOP to handle. However, in places where the service/advice/aspect is purely, or nearly purely orthagonal to the business logic contained within a method, AOP can be a great solution.

But, I'm willing to be wrong here. I haven't the experience in AOP to be able to properly defend the viewpoint, just a theory. I'd like for it to work, but only experience will show that.

Jeff...

<Edit> After rereading everything again, I think the key point is the orthagonality (nice word, huh) of AOP. It's meant for cases that are truly orthagonal to the runtime requirements of the object being handled. Logging is a good example. If your purpose is to mark the entry and exit of any given method, AOP works very well. Perhaps security/authorization/encryption is as well.

For your example with the discount rules, this is really a situational/contextual problem that doesn't have a crosscutting solution. In this case I would think that AOP is misapplied; "principal.IsInRole()" is probably the best/only option here.

Thanks for all the great replies you guys. I will research AOP a bit more and decide which will be best for my app.

Just to add 1 thing, I've been looking into AOP, and indeed most examples appear to be related to orthoganal functionality. I picked up Applying Domain-Driven Design and Patterns based on Frans' endorsement, and they actually suggest that using AOP for business rules helps increase the configurability of your system. That is the only benefit, and for many systems, that may not be a requirement anyway, but if you have 1 system with a lot of different customers, each w/ their own ways of doing things, it might be easier to use AOP to configure some of the business rules rather than trying to make all of your stakeholders come to the table and agree.