[ZODB-Dev] CHAP with ZEO

[Monty Taylor]

Jeremy Hylton <jeremy@digicool.com> writes:

>   MP> CHAP is sub-standard weak authentication?
> 
> There is no question here.  People have been using Kerberos since the
> last millenium :-).  For the kind of environment that Toby described,
> it seems like a good solution.

I'd love to see a kerberized ZEO. For that matter, why wouldn't
ssh/stunnel work just as well. We're talking about system-level
authentication to determine if _you_ as a person/system user have
rights to connect as a ZEO client. Not if you as a Zope user have
internal Zope access rights. Those are irrelevant. 

If, for example, you have a zope user on your box that Zope runs as,
when you start that Zope process in a non-ZEO environment, you are
trusting that the operating system as authenticated the zope user as
having access rights to run on top of the ZODB (which is stored with
permissions for only they zope user, hopefully) To run a similar ZEO
client, you should have to go through similar
authentication/authorization. More would be silly, less would be
harmful. 

Of course, with standalone ZODB, the Zope user permissions are
irrelevant, but the application may also have a user system defined. 

Once it has been determined that the ZEO client has permission to make
a connection, authentication to the Zope (or whatever) user system
still has to take place. You could implement a ZODB/ZEO user system to
decide who can make a ZEO connecting (duplicating work the OS already
does) but you're STILL open to a attack from an application faking
individual user credentials, because these clients are in Python, and
the byte-codes can be hacked. For the ZEO system to work, the server
has to trust the client, because ALL processing happens client
side. The only ZEO has to do with is handing the client processing
system a bunch of pickles. 

All that being said, you can use CHAP, HTTP Auth, Kerberos or
SSH/STunnel all you want. (I would personally vote for ssh keypairs, due to
simplicity of set up) to control ZEO client connection. There is no
way, without the ZEO server processing served out requests and pickles
that you can ensure that the ZEO client hasn't lied about the fact
that a 'Zope User' actually has authenticated. At least not in a
general way. 

Of course, you can always extend ZEO on a per-installation basis, but
you'd have to provide ZEO with all of the knowledge about whatever
authentication mechanism your using in the application. 

Remember, ZEO is designed as a clustering/concurrent database access
product. It is, and should be, a transparent piece in the storage
picture that shouldn't know anything about the application. ZODB file
storage doesn't. If you have file system access, you have access to
user data. Same with DCOracleStorage. If you can connect to Oracle as
the Zope Oracle user, you have access to any users data. Same with
ZEO.  If you need distributed client access, you're going to need to
use something like SOAP, which was actually designed for it.

I'm sorry, that turned into a rant of sorts. I really didn't mean it
that way.  So I would argue for adding nothing to ZEO and using a
wraper like stunnel. It keeps ZEO simple, and doesn't lead people to
think a level of security is there that is not, and should not be
there.

Monty