[pubcookie-users] Pubcookie virtual host support

[Maurizio Marini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Surfing Pubcookie-Dev list, i fnd this post of Larry; maybe this  helps :)

From: 
Lawrence Greenfield <leg+ at andrew.cmu.edu>


To: 
"Pubcookie Developers List" <pubcookie-dev at u.washington.edu>


Date: 
Mon, 22 Jul 2002 15:00:40 -0400


Virtual domains don't work well with the head of CVS right now. This
is largely or entirely my fault. When I was making decisions about how
to make keyclient work and simplify setup of the application servers,
I didn't think through the virtual domain case thoroughly.

Issues:

. The pubcookie code (and the pubcookie config file) assume that
there's one "ssl_cert_file" and "ssl_key_file". This effects how
keyclient runs and how the session cookies are integrity protected.

. mod_pubcookie currently has no way of overriding these config
options inside of the httpd.conf. (This is strictly my fault: I broke
it and haven't fixed it.)

. security_legacy caches the key/cert used for session integrity in
memory. This is largely a good thing, since it means that we read the
key/cert at startup and not later (when we might not have privs to do
so). This complicates switching from one key to another for different
virtual domains.

Results:

. This means that no matter how many virtual domains a single server
runs, it integrity protects cookies using only a single SSL
keypair. 

. Since different administrative entities may control the different
SSL keypairs on the one physical machine, it gives the lucky SSL
keypair owner "power" over the other virtual domains.

. It complicates load balancing/fault tolerance.

My vision:

. I believe using ssl keypairs for session integrity is a Good
Thing. It means that no additional keys need be generated by
application servers.

. Using ssl keypairs also means load balanced application servers work
more easily (since they share the ssl keypair, they can read/write
keys written by their sibling servers).

. It's annoying to have to configure the SSL paths in two different
locations (both the mod_ssl section and the mod_pubcookie
section). Ideally we'd be able to find out what keys mod_ssl is using
for a connection and use the identical keys to secure the
cookie. (This may be impractical.)

. security.h needs to have a better idea that one process may have
multiple ideas of who "I" am, depending on the call. This probably
calls for a security context that can be initialized multiple times.

. It would be nice to be able to distribute a single pubcookie config
file for an entire site that lists the login server locations,
etc. All applications would need to do is install mod_pubcookie, the
config file, and run keyclient. This too might be impractical.

Comments? I'd also like to know how widely UW uses virtual domains
(where two different domains on the same machine both use Pubcookie
auth). My apologies for breaking this in CVS---as soon as we have a
good solution I'll fix it, I promise.

thanks,
Larry

- -- 
Maurizio Marini			GSM +39-335-8259739  +39-340-0841640
Pesaro: +39-0721-855285	Fax +39-0721-859609
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+Lua74Q/49nIJTlwRAhQ5AJ9XMPrpPE2faaSNF1Okycso8xLFFgCfUMDT
43/6Yhz4z7l/SmhjcsbdL+k=
=n3du
-----END PGP SIGNATURE-----