The mailing list for listmasters using Sympa

[David Verdin <address@concealed>]

Hi,

Le 20/11/13 18:02, Peter Schober a écrit :

address@concealed">

* Dick Visser <address@concealed> [2013-11-20 16:50]:

I'd like to be able to run Sympa lists for a number of domains.
From the docs at http://www.sympa.org/manual_6.2/virtual-hosts it
looks like every mail domain needs a different HTTP vhost as well,
which is not very convenient. Especially when hosting lots of domains,
if you name the vhosts inside that domain, then we'd have to renew the
HTTPS certificate every time.

My thought exactly after the workshop yesterday :)
Esp when you consider offering hosting of lists to other institutions
who would then need to provide you with certificate + private key for
their vhosts (which in turn would necessitate use of SNI or IP-based
vhosts, both impractical and unwanted today).

Actually, using TCS, we can generate the CSR on the lists server and ask for the certificate on behalf of the organization, as soon as the local certificate authority in the organization allows us to do so.
that way, they don't have to provide us with the certificate/key pair and, which is still better, WE will be warned that the certificate is about to expire.

address@concealed">

If you planned on exposing those vhosts via SAML (to allow federated
logins to those virtual instances) you'd also have to constantly amend
the SAML metadata for each and every vhost (or even worse, have
seperate SAML metadata for each vhost).

Well, that's what we do here in RENATER. The thing is: we provide our groupware infrastructure (from which sympa is a part) in SaaS mode. That means our users expect to be "at home", which implies having their own domain (for web also). So the have separate certificates, web domains AND federation metadata. they would not accept their groupware tool to appear as RENATER URL.

Now Lukas Haemmerle just explained me that you can just add a new AssertionConsumerService for a virtual host under a single entityId. So the smart move would probably be to modify existing metadata for each new virtual host.

Before, we were dumbly adding new entityId for each new virtual host.

I think that we will now keep on adding them, but smartly. ;-) 
The reason here is more organizational than technical: if the actual organization behind a virtual host is an an entity clearly different from RENATER, it looks better to me to give them their own entityId in the federation, if only to make clear who is behind the service operated.

Cheers,

David

address@concealed">

-peter

--
A bug in Sympa? Quick! To the bug tracker!

David Verdin Études et projets applicatifs
Tél : +33 2 23 23 69 71 Fax : +33 2 23 23 71 21   www.renater.fr	RENATER 263 Avenue du Gal Leclerc 35042 Rennes Cedex

Attachment: smime.p7s
Description: Signature cryptographique S/MIME