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: Thu, 28 Nov 2002 08:35:57

At 06:39 AM 11/26/2002 -0500, Reinhard Mueller <address@hidden> wrote:
>
>Am Mon, 2002-11-25 um 01.46 schrieb Neil Tiffin:
>> I made various changes please see if this is more accurate now.
>> http://www.gnuenterprise.org/~neilt/GNUeNewGEASArchitecture201.png
>
>I'm not sure if forms would directly access the authentication
>interface. Other than that, I think the drawing is perfect.


I did some checking on PAM, that Reinhard has suggested as the
authentication mechanism.  I think that for *nix systems he is right.  

If I understand what I saw, PAM is a *nix operating system service for
modularly integrating authentication methods and applications.  It can
handle a wide variety of authentication methods, including Kerberos (a
network authentication protocol), LDAP (that implements an X.500 directory
with authentication included), Secure-ID (which provides user devices and
host hardware that synchronously and unpredictably change a value every
minute on the user device and thereby implement a dynamic password), and
others, and a variety of applications including Postgresql, Mysql and
others.  To do the integration, you need a module for the authentication
method and a module for the application.  PAM avoids the need for
reprogramming the interfaces for each combination of authentication method
and application.

It doesn't work with Windows, but Windows has its own authentication
interfaces (which reportedly use modified versions of Kerberos).

As posted on the list by Neil Tiffin, the Python PAM module is somewhat
dated (it is described on its download page as "buggy and insecure") and
will probably need to be fixed.

However, PAM is an operating system function and can also supply the same
authentication to the database.  So users who want greater security
assurance can configure their systems to have the operating system or
database provide some or all of the access control.  The implication is
that there may be a dotted interface to forms and to the database from the
authentication system.

On another issue, one security related aspect appears to be the
traceability of the data from the database through appserver to the form.
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?


Stan Klein






reply via email to

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