Re: Newbie security architecture question
From: Joe Kaplan (ilearnedthisthehardway@noway.com)
Date: 01/18/03
- Next message: Robert Zurer: "Re: Newbie security architecture question"
- Previous message: Robert Zurer: "Re: Newbie security architecture question"
- In reply to: Robert Zurer: "Re: Newbie security architecture question"
- Next in thread: Robert Zurer: "Re: Newbie security architecture question"
- Reply: Robert Zurer: "Re: Newbie security architecture question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Joe Kaplan" <ilearnedthisthehardway@noway.com> Date: Sat, 18 Jan 2003 11:05:50 -0600
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.
For callers that actually access your business objects, you might consider
using Strong-name permissions to authorize callers. Basically, a
strong-name permission will require that the calling assembly be signed with
a strong name key that you would presumably control and distribute.
Combining these two things might give you the flexibility to do exactly what
you want, but you will probably need to spend some careful consideration in
your design.
For what it's worth, I am doing something similar with a set of business
objects that are called from both ASP.NET apps and also from some
"batch-style" console apps and services. It seems to be working out pretty
well so far.
Good luck,
Joe K.
"Robert Zurer" <robert@zurer.com> wrote in message
news:e8sgLewvCHA.1640@TK2MSFTNGP09...
>
> "Shawn Farkas [MS]" <shawnfa@online.microsoft.com> wrote in message
> news:#rfFM3nvCHA.2668@TK2MSFTNGP09...
> > Hi Robert,
> >
> > Joe is correct, you do want to use role based security.
>
> Thank you both for your kind input.
>
> One of the issues I didn't mention is that I intend to use the same
business
> objects for many different applications. In one application the method
> Foo.Bar() may be available to all users and in another only to some,
making
> hardcoded security attributes unworkable, (or am I wrong?).
>
> My idea was to have each class and method have an CustomAttribute
specifying
> the evidence necessary to call it successfully. Each 'UserSecurityObject'
> would be supplied with a list of these 'pieces of evidence' when the
session
> starts. Then, and here is the problem, the server would somehow call the
> methods of this object using a new AppDomain, passing into the AppDomain
the
> evidence supplied by the client session.
>
> To use a non-real-world example, if I were using not using a web
> application, but instead a series of console apps, the console apps could
be
> identical except that each application's assembly would contain specific
> evidence based on what code the app is allowed to call.
>
> Can I do this from within a web application?
>
> Robert Zurer
>
>
>
>
- Next message: Robert Zurer: "Re: Newbie security architecture question"
- Previous message: Robert Zurer: "Re: Newbie security architecture question"
- In reply to: Robert Zurer: "Re: Newbie security architecture question"
- Next in thread: Robert Zurer: "Re: Newbie security architecture question"
- Reply: Robert Zurer: "Re: Newbie security architecture question"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|