3-Tier

I'm working on what I presume to be a standard n-tier configuration, but
after searching the web and Usenet I still can't figure out a good way
to implement it.
The middle tier (henceforth "the server") handles persistence for the
business objects, and can do a few other things with them. 90% of the
presentation layer is standard insert/view/edit/delete. What the clients
are allowed to do is limited depending upon their credentials (i.e. the
operator and operator's group).
I'm doing this in C#/.NET; compatibility with other platforms is not an
issue (that's final as far as the boss/client are concerned, please
don't try to enlighten me). I'm assuming that the best way for the
presentation tier to access the business objects is marshal-by-reference
from the server, but I'm happy to be corrected if wrong. How should
security be implemented? Each object has to somehow know which operator
is accessing it. How can this be done in a way which prevents clients
from masquerading? How should the creation of new objects be handled?
I'm trying not to clutter the business classes with excessive
implementation-specific security code. In my preliminary implementation,
each property evaluates
bool f(Object subject, FieldInfo aspect, Operator op, Operation
operation)
passing a reference to the relevant object and field, the operator, and
insert/edit/view/append/delete. I'm still at the stage where this could
be easily changes for a better implementation.
I would be very grateful for any thoughts on the subject.

Hi Fred,
One option you have is COM+ (AKA Component Services). If your componenent
is registered with COM+, you can assign role base security to certain
components or even to certain methods of components. A search for serviced
component should get you some good info...

Jason


"Fred" <no@spam.com> wrote in message
news:csg3ub$7ot$1@news.freedom2surf.net...
> I'm working on what I presume to be a standard n-tier configuration, but
> after searching the web and Usenet I still can't figure out a good way
> to implement it.
> The middle tier (henceforth "the server") handles persistence for the
> business objects, and can do a few other things with them. 90% of the
> presentation layer is standard insert/view/edit/delete. What the clients
> are allowed to do is limited depending upon their credentials (i.e. the
> operator and operator's group).
> I'm doing this in C#/.NET; compatibility with other platforms is not an
> issue (that's final as far as the boss/client are concerned, please
> don't try to enlighten me). I'm assuming that the best way for the
> presentation tier to access the business objects is marshal-by-reference
> from the server, but I'm happy to be corrected if wrong. How should
> security be implemented? Each object has to somehow know which operator
> is accessing it. How can this be done in a way which prevents clients
> from masquerading? How should the creation of new objects be handled?
> I'm trying not to clutter the business classes with excessive
> implementation-specific security code. In my preliminary implementation,
> each property evaluates
> bool f(Object subject, FieldInfo aspect, Operator op, Operation
> operation)
> passing a reference to the relevant object and field, the operator, and
> insert/edit/view/append/delete. I'm still at the stage where this could
> be easily changes for a better implementation.
> I would be very grateful for any thoughts on the subject.
>
>
>

Fred <no@spam.com> confessed in news:csg3ub$7ot$1@news.freedom2surf.net:

> I'm working on what I presume to be a standard n-tier configuration, but
> after searching the web and Usenet I still can't figure out a good way
> to implement it.
> The middle tier (henceforth "the server") handles persistence for the
> business objects, and can do a few other things with them. 90% of the
> presentation layer is standard insert/view/edit/delete. What the clients
> are allowed to do is limited depending upon their credentials (i.e. the
> operator and operator's group).
> I'm doing this in C#/.NET; compatibility with other platforms is not an
> issue (that's final as far as the boss/client are concerned, please
> don't try to enlighten me). I'm assuming that the best way for the
> presentation tier to access the business objects is marshal-by-reference
> from the server, but I'm happy to be corrected if wrong. How should
> security be implemented? Each object has to somehow know which operator
> is accessing it. How can this be done in a way which prevents clients
> from masquerading? How should the creation of new objects be handled?
> I'm trying not to clutter the business classes with excessive
> implementation-specific security code. In my preliminary implementation,
> each property evaluates
> bool f(Object subject, FieldInfo aspect, Operator op, Operation
> operation)
> passing a reference to the relevant object and field, the operator, and
> insert/edit/view/append/delete. I'm still at the stage where this could
> be easily changes for a better implementation.
> I would be very grateful for any thoughts on the subject.
>
>
>

Fred,

A simple suggestion.

Have you looked at the Patterns & Practices website?

http://www.microsoft.com/resources/p...s/default.mspx

Lots of architectural info. There is an excellent book on ASP.NET security
that includes advice on implementing distrubted apps, etc.

regards,

-- ipgrunt

IPGrunt wrote:
> Fred,
>
> A simple suggestion.
>
> Have you looked at the Patterns & Practices website?
>
> http://www.microsoft.com/resources/p...s/default.mspx
>
> Lots of architectural info. There is an excellent book on ASP.NET security
> that includes advice on implementing distrubted apps, etc.

Good site - tx