Re: [Gnue-dev] Appserver/Common Issues

[Stanley A. Klein]

At 03:05 PM 11/23/2002 +0100, Reinhard Mueller wrote:
>Stan,
>
>Am Fre, 2002-11-22 um 19.00 schrieb Stanley A. Klein:
>> >Consider we have the "final" GNUe Application, where we have about 20
>> >forms and 50 reports showing the purchase price. I install that to a
>> >customer and the customer tells me to make purchase prices invisible to
>> >certain users. So i would have to change 20 GFD's and 50 GRD's.
>> >The next update then would probably break it again.
>> 
>> I see the issue you are raising.  I took it to use as one of the examples
>> in the document I'm writing (which I hope to finish the current revision of
>> soon).  :-)
>> 
>> If the number of gfd's and grd's is limited, the strategy I described would
>> work.  For a lot of gfd's and grd's you are right that we would need to do
>> something else.
>
>Agree.
>
>> I think there are some database systems that provide access control by
>> field.  If such a database system is available, I would recommend using it
>> to provide control of the price field. The implication for GNUe and
>> appserver is that the field would need to be traceable from the client side
>> through appserver to the database side.  I don't think that was guaranteed
>> in the old GEAS.  I hope it can be provided in appserver.
>
>This could work if Appserver logged into the database using the user's
>username. However, our strategy will more probably be Appserver using
>it's own logname to log into the database, and therefore having more
>access rights to the database than the user would have when accessing
>the database directly.
>

Actually, the critical issue is not the login name.  The critical issue is
the mapping of the data item from SQL, gcd, gsd, or whatever other schema
format on the client side to whatever is stored in the database.  In the
old GEAS, as I understand it, the mapping was some kind of "black box" that
was impossible to clearly trace.  That meant it was impossible for a system
administrator to know exactly where anything was being stored so the
security could be set up to match an enterprise's security policy.

It also helps to be able to trace the user names to database login names,
but that is probably much easier.


>Example: Appserver could automatically (by using bound procedures)
>maintain some redundant fields in the database, like total invoice
>value. These fields would be read-write for Appserver, but they would be
>read-only for user's SQL access.
>

Not a problem if we know on the database side how the fields relate to the
user client side.

>> Otherwise, the only way to provide the control is to do it by GNUe
>> functionality, recognizing (and telling prospective users) that the
>> security assurance of such an approach is likely to be less than in other
>> approaches.
>
>If we want to remain portable and database independent, we don't have
>another choice IMHO than doing access control within Appserver. Whether
>this is secure or not only depends on the quality of our own code.

Actually, my vision of security, if we can do the mapping I talked about
above, would be to offer multiple options.  Essentially, while GNUe itself
is operating system and database independent, the security wouldn't be
completely operating system or database independent.  The system
administrator would have the option of increasing security and implementing
particular enterprise security policies by configuring the system to make
the operating system or database responsible for providing the
authentication, access control, and security logging.

This might still require code in Appserver or Common to essentially do
Python system calls or database interface calls to security-related
functions.  Here are some simple examples:

1.  Right now, we have a login screen that asks for user ID and password
and passes them as parameters to the database (or perhaps the operating
system).  If the database or operating system supports RBAC and we are
using that capability, we would need to change the screen and the passed
parameters to include user ID, *role*, and password. 

2.  If a user is allowed to change roles during a session, we would need a
screen and calls to the database or operating system role-change function.

3.  We would probably need exceptions (if they aren't already there) to
handle cases in which the operating system or database disallows an access
(as distinct from appserver disallowing the access).  

4.  We may need administration tools to set and change permissions on files
and database objects where we know the mapping of names and the operating
system or database provides calls to set and change the permissions.

The way to accomplish these kinds of things is probably in the database
adapter and in something like a collection of operating system security
adapters.  Then what we need is a collection of how-to's that explain how
to implement particular kinds of security policies using the native
facilities of common and appserver (if the risk is acceptable to the user)
or how to get improved levels of security on particular database systems
and operating systems using the interfaces provided by the adapters.

The security framework document I'm working on discusses security in
general and has some general kinds of things leading to the how-to's.  

These discussions are very useful.  I can't say much more about the
operating system security adapters and the structures of the how-to's
because I just thought about them in writing the previous paragraphs.  :-)


Stan