Virtual domains — discussion

Openfire Openfire Dev
1

So, one of the things I would like to have is virtual domains. E.g., I want to run one Wildfire server and support multiple domains on it. Now, Jive has indicated that they’‘re planning this, but that it’‘s not a near-future thing. I’'d like to see if I can implement it, or at least gather all the requirements and make a design decision.

Some questions:

  • Could the online documentation/javadocs be rebuilt? They’'re still at 2.6.2.

  • Is there a high-level overview somewhere of how everything fits together?

  • Are there any other useful resources devoted to this particular issue? I’'ve seen lots of feature requests in the forums, but nothing going any further than that.

So, let’‘s see if I can think of things that have to change to support this. Please correct me if I’‘m wrong, or add things to my list. Also, I’'d like to take this in steps, starting by looking at the c2s parts, then the s2s part, and then the conference/MUC and other parts.

  • The database has simple username columns everywhere. These don’'t contain the host, just the user part of a JID. This should be changed. Either the column should be made longer to support the full JID in the column or separate columns should be added to contain the hostname for a JID. There might be a problem with the index sizes (in MySQL, at least).

  • The server needs to respond to client streams with the appropriate hostname depending on the JID requesting the connection.

  • The server may or may not select a different SSL certificate depending on the domain used. This is necessary if the SSL cert actually refers to a fixed name – it’'s not important if the server is just using the default John Doe certificates.

What am I missing here? Tips? What parts of the code are especially relevant?

2

You can grab the source from subversion and generate the javadocs from there, if you want the most current. 2.6.2 is the current stable release, so it makes sense that would be the published “standard” until the next release.

As far as I know, no such high level overview exists. I would love there to be one, but Ive never really had the time to document it myself. Indeed, I keep my modifications pretty localized and havent needed to know much outside my little corner of the world.

Ive startted putting together a reference sheet of every property used by wildfire, and documenting in one sentence what its for. I dont really have a good place to host it at the moment, but Im sure that would be useful.

Database Structure[/b]

The current database structure is very tightly integrated into a single domain concept. While some things would be easy to just “extend” by adding a domain to them, that may not make sense in all cases. A lot of system settings are stored in the database, and it will not make any sense to keep those common among all virtual servers. It might make more sense to allow wildfire to just use multiple databases and/or table prefixes. Perhaps some combination of the two?

SSL[/b]

SSL is going to be tricky. Its the same mess as with HTTP, but we do have things a little better. With TLS, its possible to negotiate a hostname first, then the certitifcate to match can be used. But with old-style SSL, the certificate comes first, and the name used on the certificate may not match the name the client is connecting to. This is a problem with the default “John Doe” certs that come with wildfire by default. But, there is an advantage (or disadvantage, depending on your perspective). Most jabber clients silently ignore SSL certificate errors. There is also the matter of the SRV records. If a client is connting as user@domain.com but the SRV records say to use the server jabber.otherdomain.com which SSL certificate should the client expect? This may be documented somewhere, but I dont know off hand. I would think if you know the hostname you are connecting to is jabber.otherdomain.com that should be the certificate you expect.

Kerberos[/b]

Ok, so its not fully implemented yet, but its my baby so I may as well speak up about it now. Kerberos authenticates both ways (client to server, and server to client). This is done via a keytab file with principals ( ie xmpp/domain.com@REALM.COM ). SSL issues aside, this should work just fine. In fact, its even acceptable to put multiple principals in the same keytab. However, Java wants to know the principal name to use via its own config file (not in the wildfire.xml) so multiples of these files (gss.conf at the moment) will be needed.

Code[/b]

Ok, some places to start looking in the code:

  • The JiveGlobals stuff. Many, many things go here to get details about this particular setup. So this object will need to be modified to handle multiple instances (one per virtual host) and a method for getting the right[/i] instance needs to be worked out. If not multiple instances, something needs to follow with the client thread (even though its not exactly one thread anymore) to indicate which virtual domain is being used to it can pull the right info.

  • The network connections. The domain is already being parsed, you just want to start doing something different with it.

  • All the database calls. Some idea of which virtual domain is being used should be taken into account.

Of course there is more. But this is some food for thought right now.

3

There is also the matter of the SRV records.

If a client is connting as user@domain.com but the

SRV records say to use the server

jabber.otherdomain.com which SSL certificate should

the client expect? This may be documented

somewhere, but I dont know off hand. I would think

if you know the hostname you are connecting to is

jabber.otherdomain.com that should be the

certificate you expect.

Per url=http://rfc.net/rfc3920.htmlRFC3920[/url]:

"Certificates MUST be checked against the hostname as provided by

the initiating entity (e.g., a user), not the hostname as

resolved via the Domain Name System; e.g., if the user specifies

a hostname of “example.com” but a DNS SRV lookup returned

“im.example.com”, the certificate MUST be checked as

“example.com”."

4

Per url=http://rfc.net/rfc3920.htmlRFC3920[/url]:

"Certificates MUST be checked against the

hostname as provided by

the initiating entity (e.g., a user), not the

hostname as

resolved via the Domain Name System; e.g., if

the user specifies

a hostname of “example.com” but a DNS SRV

lookup returned

“im.example.com”, the certificate MUST be

checked as

“example.com”."

So in the example of using SSL, the initiating entity cannot indicate to the server the hostname before the SSL session. The question is, which certificate does the server give the initiator?

5

So in the example of using SSL, the initiating entity

cannot indicate to the server the hostname before the

SSL session. The question is, which certificate does

the server give the initiator?

That’'s a pretty sticky issue, as the SSL certificates are mostly sent BEFORE the user is sending his or her JID. That would make it impossible to do vdomains, right?

6

Not completely. But, you cannot use the old style SSL with mutliple certificates on the same IP address. There are ways around it though. First and foremost, use TLS. Since the encryption negotiation happens in the stream, the hostname can be negotiated beforehand. Second, you can use multiple IP’‘s. Not everyone can afford multiple IP’'s, but that is the solution that HTTP uses (since TLS is prettymuch unused in the HTTP world).

The third solution may not be a real solution as its possible it violates protocol. I would need to read the RFCs again to be sure. If you use dns service records, you are pointed to a name that dosnt match the virtual domain you are using. Using that name might be a better idea. In the Kerberos world, the service keytab needs to match the hostname, not any alias you might have for it, so its the same idea. Here is an example.

xmpp-client.tcp.virtdomainA.com. IN SRV 20 0 5222 realhost.com.

xmpp-client.tcp.virtdomainB.com. IN SRV 20 0 5222 realhost.com.

When using SSL, couldnt the client assume that the certificate when connecting should be for realhost.com not virtdomain*.com ? Again, this may violate some RFC, more research needs to be done unless someone can verify it for me.

7

For me, a “hostname” is specified by an A-entry (or AAAA), not an SRV record…

8

Multiple domain support is also a feature that I desire. How is the implementation effort going? I am keen to help.

9

Any news on this issue ?

10

any news on this one?

i dont expect that it will happen in 3.1?!