Re: Newbie security architecture question

From: Joe Kaplan (ilearnedthisthehardway@noway.com)
Date: 01/18/03


From: "Joe Kaplan" <ilearnedthisthehardway@noway.com>
Date: Sat, 18 Jan 2003 15:00:28 -0600


The strong name permission sounds a lot like what you are trying to do
already. The calling assembly would need to be signed with a particular
strong name key and then the business components would use the
strongnamepermission attribute to do the authorization. It seems to me to
be much easier to do something like this than to create your own schema or
doing nearly the same thing. Still, I guess I don't see what stopping you
from building something custom too.

I think you will need a role-based access layer for your web application
interface though and use PrincipalPermissionAttribute decorations.

You might be able to do some kind of inheritance scheme instead of a method
dictionary approach. This still sounds like a lot of work to create
overrides on all of the different methods that require security in different
contexts, but it sounds like you have a lot of work to do anyway.

Good luck. It sounds like quite an undertaking. If you want some more
input on the custom attribute/evidence approach, I probably can't help you
with that.

Joe K.

"Robert Zurer" <robert@zurer.com> wrote in message
news:OuYxVDyvCHA.2476@TK2MSFTNGP10...
>
> "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.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.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)