cmer

http://mugshot.org

http://online-desktop.org

As I see it, there are two fairly different things that could be covered by this bug report:

A) "server aliases" - the server acts as multiple different domains, but the set of users is the same on all domains
B) "virtual hosts" - the server acts as multiple domains, with a separate set of users on each domain. Other aspects of the config might also be different for different domains

I'm only really interested in A) at the moment. My basic plan of attack is to keep the idea that a server has a central master domain, configured as the property, but to add a separate property xmpp.domainAliases which is a list of additional domains that the server thinks it is.

There are many places that could conceivably be affected by the change (searching for references to XMPPServerInfo.getName()) but I think you can get a usable amount of functionality going ignoring most of these. Some of the places I do expect to have to change:

• When a user connects directly to the server, we should look at the "to" attribute of the stream and use that to select the domain that the user thinks they are connecting to. This should be the used to build the JID for Session.getAddress()
• XMPPServer.isLocal(), MessageRouter, and IQRouter need adaption when deciding what is a local JID
• ServerDialback.isHostUnknown needs to recognize the domain aliases

Feedback appreciated if the above sounds horribly wrong or misguided.

You probably could fix things up by say, remembering the JID the user had when they added a roster entry and using that as the 'from' for subsequent <presence/> sent as a result of the roster entry, but whether that is of any use really depends on the use cases people have. It may be that people want and need full virtualization of the user database instead. That isn't conceptually hard, but is certainly not something I'm planning to touch.

So user@sistercompany1.com can login to the same server as user@sistercompany2.com even though each company has it's own LDAP server. The two users should be able to do searches and find each other. Ideally this would scale to around 7-10 domains supported.

As much as I like openfire, I'm going to have to switch to something that supports multiple domains via virtual hosts--if such a server exists.

...if I had the time I'd write the code!

domain.local
aa.domain.local
bb.domain.local

Is there a way to configure it actually? I need it working tomorrow.. hehe

To implement this will require very significant changes to the core Openfire code, and is not going to be an easy task. Having the most votes helps Jive determine what the public is interested in, but other factors play into what features actually get implemented. Paying customers tend to have better say, of course. If some community members are willing to start work on the process, Im sure several others will join in, perhaps even with some support from Jive. But this is not a project to be undertaken by a single person.

etc in other words, more than one XMPP domain at the same time. =)

Such a great software lacking such killer feature.

Here is what I would like to see for each virtual domain account

• their own users
• their own admin to administrator their account and users
• users can get access online to update their profile
• each virtual domain account assigned to their SSL certificate since they will be using a different domain name, example im.abc.com.
• super admin have right for permitting plugins used for each virtual domain account.
  Here is an example, virtual domain account xyz.com does not want their users to be allow file transfers and other IM gateways because of their internal policies. abc.com wants file transfers and other IM gateways for their users.
• virtual domain admin can add or change permissions for plugins

However, at the moment Openfire is not anywhere near ready to support multiple domains (it will require significant code changes).

This is, as I see it, one of the huge advantages of vhosting in the XMPP specification - please correct me if I'm wrong.

I used Wireshark to listen the communication and it looks that this solution is possible

I vote for this feature, it would be great - I use OpenFire for my domain, but I would like to use it for hosting too.

When details about the hostname that handles XMPP for a certain domain is stored in SRV-records, it should be possible for this host, merely to identify itself in accordance to its own PTR-record, and the corresponding A-record, pointing to it. In this way, one valid certificate, identifying the "vhosting" XMPP-server, should suffice for all the domains hosted by it.

My main issue with this approach is, that decent certificates are pretty expensive.

Which certificates are expensive? IMHO you can have number of ordinary „cheap" certificates for every domain you host - and open fire will choose the right one acording to domain requested by client (still before starting TLS).

When details about the hostname that handles XMPP for a certain domain is stored in SRV-records, it should be possible for this host, merely to identify itself in accordance to its own PTR-record, and the corresponding A-record, pointing to it. In this way, one valid certificate, identifying the "vhosting" XMPP-server, should suffice for all the domains hosted by it.

This may be a better (and cheaper) solution (Supposing that XMPP client will accept valid certificate for the real hostname and do not require certificate for exactly @virtualdomain.tld)

The user only enters the virtual domain name into the client. The client does an SRV lookup and then connects to the host given by the domain name server. Since the host name given by the DNS cannot be trusted (since DNS cannot be trusted, see Kaminsky), comparing the CN to the hostname would only help against accidental misconfiguration, not malicious intend.

Of course, this would change when DNSSEC is used, but that's not the case right now.

We have an additional feature there: It's possible for the user to override the SRV entry by specifying a host manually in the advanced configuration. When this is done, the certificate is checked against this name, not the one given by the JID.
This allows us to support Google for Domains without certificate warnings.

Since the host name given by the DNS cannot be trusted

Oh, sorry, this is true, we cannot trust DNS → so this is cheap but foolish solution.

It's possible for the user to override the SRV entry by specifying a host manually in the advanced configuration.

It is nice, but BFUs do not like „advanced configuration". Of course, it is good, that this option is here.

And what about the inner architecture of OpenFire - how hard is to implement multidomain support?

Since the host name given by the DNS cannot be trusted

A very valid point - I really didn't think about that. Another reason to get DNSSEC introduced in our tld-zones as quickly as possible.

Still, I'm very eager to get this feature implemented in Openfire, and I would appreciate any insight given on the matter. If I can help in any way, I would gladly spend some time on the implementation myself.

First: Virtual Hosting of XMPP has been done before (with other servers), and as such if/when Openfire implements it, there should be some research into how other services do it. (not the internals, but the concepts) There is no need to reinvent the wheel here. Much of what is being discussed here has already been solved elsewhere.

Second: Openfire's internal architecture will make this a significant feat to accomplish. The database for one, assumes the xmpp domain and leaves if off all values. This means either a completely separate database for each virtual host, or a complete rewrite of the schema- neither of which is an attractive solution. There are also hundreds (or more!) calls inside Openfire that would need to be rewritten to keep a domain context in mind.

So in the end- this is not a simple fix. Discussion is welcomed, of course, but until some more people step up to the plate to actually do the programming behind this, it will NOT happen. That is to say, there is no timeline, no estimated version this will appear in, and currently no effort being put into this, with the exception of user requests.

I would love to step up, and try to help implementing this feature, but I've only looked at the OpenFire code a few times, and I'm certainly not familiar with its overall structure.

So. How does one get cracking on this thingy? Is the recommended fashion just to open Pandora's Box, read code for a while, and start hacking? Or should I contact someone to offer my help, and perhaps gain an introduction?

All in all, any advice is most welcome.

I would just start playing with it. There are some good developers on the forums, so just ask your questions as you come across them. Since you dont know the OF structure well, you might just try the first attempt bind (ie- just try trying to make it work) but realize that first attempt will never be released. After you learn the lessons to learn, plan it out better, and start over

For me isn't important if there would be a database for each domain (and each domain has here own gui); but there should be only one IPv4 Address needed for all the domains.

Enough explained - I vote for it!