gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stanley A. Klein
Subject: Re: [Gnue-dev] New Architecture Drawing based on Whitepaper.
Date: Wed, 04 Dec 2002 20:16:33

Reinhard -

First, I assume you meant to "reply to all" and to document our discussion,
so I'm cc:'ing the list.

What I mean by "traceability of the data" is that it is possible, given the
way a data item is defined on one side of appserver, to identify the data
item on the other side of appserver.  A simple example would be that if the
schema is in SQL and a field is identified as "price" on one side of
appserver it will be in an SQL schema on the other side also identified as
"price."  An example of not being traceable is if appserver combines the
field with other fields, executes some kind of strange algorithm, and
stores the result as a binary blob that appserver can understand but the
system administrator can't.

Here is an example of why traceability is important.  Suppose an enterprise
wants to do a simple version of role based access control where "price" can
be accessed by users with a role of "manager" but can't be accessed by
users with a role of "clerk."  If the enterprise is satisfied with low
assurance security, it might be enough to let appserver do all the access
control with appserver code.  

However, suppose the limiting of price access to managers is a legal or
contractual obligation where the enterprise believes it must be able to
demonstrate a "standard of care" that corresponds to having medium
assurance security.  So instead of picking any operating system or database
available, they limit themselves to operating systems that have facilities
for users to log in with roles and to databases that have role based access
control by field, both at a medium assurance level of security.  

Then, the users log into the operating system with a user ID, role, and
password.  The operating system authenticates the validity of the
combination and passes the authentication information (e.g., via pam,
kerberos, or whatever else might be involved) to both appserver and the
database.  The system administrator, knowing that "price" on one side of
appserver is the same as "price" on the other side, goes into the database
(or databases) and sets the access permission for the price field to the
role of "manager."  

Then, even if a malicious user is able to break the protection provided by
the (low assurance) appserver code the data is still protected by the
(medium assurance) operating system and database.  That satisfies the
enterprise's need to have medium assurance security protecting the data.

Note that there might be some kind of GNUe security adapters for the
operating system and database doing some things that make it easier for
some of this to happen, but in principle it could happen without them.

I hope this helps clarify what I'm trying to say.


Stan


At 04:06 PM 12/4/2002 +0100, you wrote:
>Stan,
>
>sorry for late answer.
>
>Am Don, 2002-11-28 um 09.35 schrieb Stanley A. Klein:
>> On another issue, one security related aspect appears to be the
>> traceability of the data from the database through appserver to the form.
>
>I think I don't understand what you mean with "traceability of the
>data". Can you please try to explain with other words?
>
>> This seems to relate to the role of the Class Repository.  If the schema at
>> the form is expressed in SQL or equivalent gsd, I think the data will be
>> traceable and can be protected by access rules either at the form (gfd
>> files) or at the database server (if the rules match the capabilities of
>> the database), or in the appserver (if the rules involve more complex
>> business logic not supported by the database).  If the schema is expressed
>> as gcd (or classes), the translation from objects to SQL will be much more
>> complex and less easy to trace.  In that case, the user will need to depend
>> on the appserver business rules to provide the access control.
>> 
>> Question for the appserver experts:  Is my assumption about the schema
>> being expressable in either SQL/gsd or gcd correct?
>
>If schema == the definition of "tables" and "fields" (really classes and
>properties), then the schema is defined at appserver level.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]