Re: Newbie security architecture question

From: Robert Zurer (
Date: 01/18/03

From: "Robert Zurer" <>
Date: Sat, 18 Jan 2003 13:39:03 -0500

"Joe Kaplan" <> wrote in message
> You might consider a layered approach where you factor the role-based
> security requirements into a separate assembly and call into that through
> your web application. Your business objects would trust this outer layer
> and rely on it for authorization of activities. With that, you could use
> the role-based mechanism that ASP.NET offers.

If I understand you correctly, all calls to the business layer would be
routed through this separate assembly. It would, based on the role passed
in, decide whether the call should be allowed and then take some action. I
like this because the business layer would then be security-agnostic.

However, wouldn't this imply that this 'security assembly' maintain an
elaborate 'method dictionary' of sorts, i.e.

Employee.get_Name() can be called by All Roles
Employee.set_Name() can be called by Roles 'Manager' and 'Clerk' but not by
Role 'Accountant
Employee.get_Salary() can be called by Roles 'Manager' and 'Accountant' but
not by Role 'Clerk'
Employee.set_Salary() can be called by Roles 'Manager' but not by Role
'Accountant' etc.

If the number of classes and methods were small, this would be maintainable
but not if there were 250 classes each with 50 methods/access methods and

Instead what if each method of each class had a CustomAttibute which had a
'key' property, unique across the enterprise, similar to a GUID, then using
CAS, any code which wanted to call this method and supplied this key in the
form of evidence would be allowed to do so?

As I say, I think this would work with a series of console apps. But how
could this be implemented in a web application?

Robert Zurer