Re: Newbie security architecture question

From: Robert Zurer (robert@zurer.com)
Date: 01/18/03


From: "Robert Zurer" <robert@zurer.com>
Date: Sat, 18 Jan 2003 13:39:03 -0500


"Joe Kaplan" <ilearnedthisthehardway@noway.com> wrote in message
news:ue$LQRxvCHA.2292@TK2MSFTNGP10...
> 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
growing?

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



Relevant Pages

  • Re: Newbie security architecture question
    ... overrides on all of the different methods that require security in different ... > like this because the business layer would then be security-agnostic. ... > Employee.set_Namecan be called by Roles 'Manager' and 'Clerk' but not ... > Employee.get_Salarycan be called by Roles 'Manager' and 'Accountant' ...
    (microsoft.public.dotnet.security)
  • Re: Newbie security architecture question
    ... overrides on all of the different methods that require security in different ... > like this because the business layer would then be security-agnostic. ... > Employee.set_Namecan be called by Roles 'Manager' and 'Clerk' but not ... > Employee.get_Salarycan be called by Roles 'Manager' and 'Accountant' ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Newbie security architecture question
    ... > security requirements into a separate assembly and call into that through ... all calls to the business layer would be ... Employee.set_Namecan be called by Roles 'Manager' and 'Clerk' but not by ... Role 'Accountant ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • [security bulletin] HPSBPV02918 rev.2 - HP ProCurve Manager (PCM), HP PCM+ and HP Identity Drive
    ... SUPPORT COMMUNICATION - SECURITY BULLETIN ... Manager (PCM), HP PCM+ and HP Identity Driven Manager. ... J9174A HP ProCurve Manager Plus 3.0 software with 50 device license ...
    (Bugtraq)
  • [security bulletin] HPSBPV02918 rev.1 - HP ProCurve Manager (PCM), HP PCM+ and HP Identity Drive
    ... SUPPORT COMMUNICATION - SECURITY BULLETIN ... The information in this Security Bulletin should be acted upon as ... Manager (PCM), HP PCM+ and HP Identity Driven Manager. ...
    (Bugtraq)