Re: [Gnue-dev] New Architecture Drawing based on Whitepaper.

[Stanley A. Klein]

At 07:34 PM 1/16/2003 -0500, Daniel E Baumann <address@hidden> wrote:

>On Sat, Dec 07, 2002 at 01:39:00PM +0000, Stanley A. Klein wrote:

>> BTW, I think this would be quite different from the old GEAS, which to the
>> extent I understood it, mapped an object paradigm onto a relational
>> database with all the attendant complexities.
>
>I have to disagree what made the old GEAS sucked because it was a poor
>implementationa and it tried to do too much. I personally like OO
>appserver with a relational mapping (and we have code that
>does this in appserver/src/_featuretest). 

>Also, things
>like access control and security should be done in common to the whole
>project and for the bebefit of the overall project with all tool
>author's input, imho. 


First, let me say that I didn't say that the complexity was what made GEAS
suck.  I'm sure there were a lot of other issues.  However, I do remember
having discussions with the GEAS folks who said that you couldn't trace an
item of data from one side of GEAS to the other.

What security does is to provide the enterprise assurance of the
enforcement of business process rules, organizational policies of the
enterprise, and legal obligations of the enterprise.  There are also some
derived requirements, such as the implied requirement that the system that
protects the enforcement of rules, policies, and obligations itself be
protected.  

There is an issue of how much assurance is provided.  GNUe itself is a low
assurance system.  It probably isn't feasible to go much higher with GNUe
itself.  If medium or high assurance are needed by the enterprise, they
will have to use an operating system and/or a database system that provide
those levels of assurance and to configure their use of GNUe to use those
higher assurance platforms to provide the needed protection.

In the case of Appserver, that requires the ability to map data items so
the user can identify on the database side what the data item is on the
application side.  The mapping is needed so the database and operating
system can be configured to enforce the rules at medium/high assurance.  I
think objects can map reasonably well to objects and relational can map
reasonably well to relational.  The problem is with mapping objects on the
application side to relational structures on the database side.  I haven't
looked at the standard you cited, but every other attempt I've seen results
in too much complexity for the user to clearly see what is going on.

Whether it is even feasible to provide a high level of assurance will
likely depend on both the nature of the particular application and the
details of the business rules being enforced.  If the application and rules
are simple enough, high assurance may be feasible.  Make the rules complex
enough and the range of users (in terms of trust) wide enough, and there
might not be any system (GNUe or otherwise) capable of providing medium or
high assurance that the rules are being enforced.

It is desirable to make GNUe look as nearly the same as possible from a
user perspective regardless of whether the application is 2-tier or
multi-tier.  That may or may not be possible, but I think it is less
possible if Appserver maps objects onto a relational database model.  The
implication would be that medium or high assurance could not be obtained
with GNUe in a multi-tier system.  If Appserver offers alternatives (such
as object-to-object and relational-to-relational), then the implication
would be that a user desiring medium or high assurance would need to pick
one of those alternatives.

I made a presentation proposal for the egovos March conference on the
challenges and lessons involved in addressing GNUe security.  From what
I've seen, I think we are pushing the bleeding edge of technology in what
we are trying to do.  And I think the security area may be one of the areas
where some significant challenges show up.


Stan Klein