Re: Security framework issues

[Reinhard Mueller]

Stan,

sorry for this late answer, but I was buried in work and just got my
head above water again.

IMHO, we have to regard the security topic as a set of separate issues
that even don't relate too much to each other.

(I'm talking n tier here)

1. How appserver connects to the database, and whether we let normal
users send direct SQL over _that_ connection. Whether we have a separate
user for the appserver in the database, and where we store that user's
password.
Must be handled in appserver.

2. How secure the connection between appserver and database is, e.g.
whether the connection is encrypted, tunneled through a VPN, etc. How
secure the database port on the db backend machine is, how it is
protected against denial of service etc.
Can and probably will be handled by database and/or operating system.

3. How the user authentificates to the application server, how we safely
transmit the password over the network, how application server checks
whether the password is correct, where the user passwords are stored.
Must be handled in appserver. However, it might be possible to use PAM
for this.

4. How secure the connection between the client and the appserver is
(same issue as 2. basicall).
Can and probably will be handled by the operating system and/or the
transport layer (GNU RPC). Some points might have to be addressed in
appserver.

5. Once the user has logged into appserver, what access he/she has. What
data he/she can se, and what data he/she can change. What procedures
he/she can call.
This must be done by appserver 100%.

Point 5 could be a system which defines
class/condition/property/user/access tuples.
For example:
* employee/NULL/NULL/fred/read would mean that fred has read-only access
to the employee table.
* employee/NULL/salary/NULL/none would mean that all users except
defined exceptions do not see the salary property. To those users, the
appserver behaves as if the salary property wasn't defined.
* employee/NULL/salary/joe/write would mean that joe may read and write
the salary of all employees.
* employee/department="10"/salary/jim/write would mean that jim can only
read and write the salary of all employees that work in department 10.
* employee/department.leader=$USER/salary/NULL/write would mean that
every department leader can only change the salary of employees working
in his department.

Of course this is not a proposal for a specific syntax. But I think you
get the idea.

If I understood correctly, Jan had the idea of implementing exactly this
using "views" on business objects, that means the actual business object
definition looks different depending on who looks at it.

Thanks,
Reinhard

-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil