Access Controls

[Derek Atkins]

It is unclear that the security server and the engine need to be on
the same machine; so long as the security server is associated with
the datastore, it should suffice.  E.g., if you don't have access to
data, you wont be able to retreive it from the datastore in the first
place.  From a security standpoint, you want the access control checks
to be as close to the "object" as possible.

I'm not convinced you want the "engine" to be across the network from
the UI.  I've always seen the engine to be a data cache and
manipulation tool, talking across the network to the datastore.
Perhaps I have a slanted view of the engine's role in a distributed
system?

-derek

cbbrowne@ntlug.org writes:

> Derek Atkins writes:
> > David Merrill <dmerrill@lupercalia.net> writes:
> > > From *my* perspective (me, the database, that is), it is all based on
> > > the user_name under which you are logged on. The database doesn't know
> > > anything else on which it can base things. So the calling layer has to
> > > translate from URL or virtual home or whatever into a user_name in the
> > > database.
> > > 
> > > Providing for multiple everythings is decidedly nontrivial, but I'll
> > > start on it.
> > 
> > Would it be possible, if we do go the gnc_server/gnc_client route, to
> > allow the gnc_server to login to the database and have _that_ do
> > access control on the data?
> 
> Ah, yes, this is indeed a Pretty Appropriate Approach.  Further, it's
> something that CORBA would support _really_ nicely; effectively, you
> set up a "Security Server," which has access to the authentication
> info, and use that as a "gatekeeper" that permits or denies access
> to the data.  
> 
> The Engine and the Security Server sit on the same host, so latency
> is very low [thinking in advance of the immediate objection!]; in the
> more paranoid approach to this, the Engine asks the Security Server,
> for each request, "Should I pass this information on?"
> 
> This is elliptically discussed in the book "Professional Linux
> Programming" [Wrox Press] in the chapters on CORBA.  [Guess the
> author?]  :-)
> 
> I will immediately acknowledge that this sort of approach 
> introduces an extra server, and excellent opportunity for new
> deadlocks and some slowdowns.  So long as Engine and Security
> Server are on the same host, the costs should be not _too_ 
> excessive.  And by localizing security control to one process,
> there can be quite spectacular control over what is permitted
> and forbidden.
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available