What OpenFire components/source files probably need to get updated in order to implement this? Any caveats?

maybe this could as well add support for 'vhosts'. e.g. 'anonymous.example.org' and 'registered.example.org', so that you can nicely restrict resources for anonymous use etc.

cmer

I'm planning on doing a partial implementation of this for the Openfire server we use on http://mugshot.org (the same server instance is going to be the backend for the GNOME online desktop work - http://online-desktop.org). I'm not at all confident that the work will be even useful as a starting point for a real implementation ... there are huge amounts of features and subsystems of Openfire that we don't use at all and that I'd have no way of testing even if I had the motivation to try and update them, but I'll post here a patch for what I come up with

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.

I'm not sure how "server aliases" are supposed to work. What user data exactly is supposed to be shared between aliases? The roster, too? This is likely to cause problems I think: Say someone logs in as user@alias1, adds person@external, then logs out and in again as user@alias2. Then person@external will be in the roster (with presence subscribe=both) but person@external still has user@alias1in the roster - thus, presence will be broken for both users. Of course the server can do alias rewriting but I wouldn't know what the point of aliases is then as local (aliased) users only show up under one alias externally then.

As I said "I'm not at all confident that the work will be even useful as a starting point for a real implementation"... rosters and, in fact, presence don't really matter for our use case so it's not something I've thought about a lot. But my assumption would be that in general each user would only log in to one alias or the other, and not switch between the aliases. If the user does switch, yes, the roster state will be mildly inconsistent.

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.

This will likely have a pretty significant impact on all aspects of openfire. A subversion branch was started to explore the possibilities without breaking trunk.

I'd like to see one instance of the server software able to view users from multiple domains and allow user searrching across those domains.

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.

Much of this discussion has been about using the same users on different domains. What I really, really
desperately need is the ability to have virtual hosts where one instance of openfire can server up multiple domains where the users are NOT shared. Otherwise, right now, I have to use some kind of IP proliferation scheme where I map XMPP ports based on the domain name to different internal IPs and different instances of openfire. That is, essentially, unworkable.

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.

Alex, I believe ejabberd has that support for some time now. That was the other choice for me, but at the time, multi-domain support isn't critical to me (yet very desirable!) so I went for OpenFire back then.

Well, I'm stuck. The alternatives are a good solution for me and so I'm going to have to figure out how to run openfire.

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

I will join the choir and say that this missing functionality is a blocker.
OpenFire has a very sexy feature set and it is by far the easiest to setup/install/manage (love the admin gui) from all the Jabber Servers i tested but without multi-domain support we can't use it.

Jorge, which other server software will you use? We need multi-domain support, even if the other software is more of a pain to configure.

Craig: I will probably use ejabberd.

Even in high voting, this feature will be put in the roadmap ? I am also looking for the feature as Alex mentioned, single instance of openfire to serve multiple domains w/o sharing.

I really need this feature too...
I need to configure subsets of a real world domain of Active Directory like below:

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

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

This is BY FAR the most votes for feature, yet it is still only marked for "future versions", and not for 3.5 ...

Bart:

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.

Then make us pay for it. Develop the multi-domain support and add it only to the 'enterprise' version. With so many people wanting it, this would be the ideal way to drive sales of the enterprise Openfire product.

I think the "make us pay for it" argument doesn't really fly here. I'd be willing to bet that the vast majority of administrators who want this feature are "just" users of the free version. I am one of those users. I'd guess that most companies buying Enterprise Edition only really need one domain supported and would much rather their money go to their own pet issues.

I found a way to work around this by using MS ADAM. If you're using Active Directory then check out this link:
http://www.igniterealtime.org/community/docs/DOC-1534

Very cool! Although that's not the same multi-domains that this issue is talking about. This issue is referring to the ability to have a single Openfire server handle something like:
mydomain.org
mycompany.com
igniterealtime.org
ninjas.net

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

They STILL don`t have this feature... im smashed.
Im just want migrate from jabberd2 to OpenFire but im need multi-domain support for it.

Same for me. Though I currently have to stick with ejabberd.
At least it appears on the schedule for 3.x by now ...

Such a great software lacking such killer feature.

I can't wait for this feature to be added to openfire. This will be a hugh benefit for openfire.

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

I wouldn't ask for too much for now. But the separate SSL certificate makes me wondering how I would handle it. I'd need to buy another cert for the second domain to use it for myself without warnings and probably also for secured s2s connections. Did anybody consider this yet?

If each "virtual server" were on its own IP, you would need different certs for each IP. If they all share an IP, things get more tricky.

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

agreed on separate SSL certificates. help keeps costs down and administration.

any news on this requested feature?

This would be great considering that I have around 10 domains and I'll like to have some with different users on them.

In regards to SSL certificates - wouldn't it suffice to have a single certificate, identifying the target of all the domains' (pretty common-looking) SRV-record?

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

Jesper: certificates and multi-domain problem should be IMHO solved by TLS (using port 5222, not 5223) - because information about certain domain is sent by client in plaintext before starting encrypted communication (<starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/>) → so the server could use the proper certificate/key for particular domain.

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.

may be other feature can help me. I need only aliases, for example: mydomain.com and jabber.mydomain.com. I have jabber.mydomain.com (i didn't know about SRV DNS), but now i want to use mydomain.com else.

František:
My main issue with this approach is, that decent certificates are pretty expensive.

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)

Yes, it would be cheaper, but would make the certificate check completely worthless.

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.

Maybe I should add that I'm the one who implemented the certificate check for XMPP into Adium.

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.

Since this topic seems to have gained some momentum again, I thought I would weigh in.

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.

Jay,

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.

Jesper,

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

OpenFire is a very nice, well-documented jabber server. So I'd be happy if he'd like to have multiple domain support.

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!

Has anyone noticed that this bug is attached to the "OpenFire (ARCHIVED)" project? And this project hasn't had an issue resolved since June of 2009. Should we re-create this issue in the "current" project that is being worked out of to get more attention? Or can we request it be moved?

Tontaube: If you settle for having one independent GUI for each platform, you can run multiple instances of OpenFire on the same IPv4 but on different ports - port number can be specified in DNS records - for each domain different.

Much better solution is having one GUI, one database, one instance for all domains - but it is quite painful redesign of OpenFire. (but it would be great).

Ad Edward Rudd: yes, this bug should be moved. Can any admin do that?

There is an aplication for Conference room booking, called MRBS, I have this configured for multiple domains,
It accepts an array of dommains, and when the user logs in, it checks the domains for that user, if it f ails, goes to the next one on the list. if success, returns success.
It is clean and works for my situation, which is.
DFComany.com.hk
DFComany.com.ph
DFComany.com.sg
DFComany.com.cn
DFComany.com.my

Seems not a big problem to solve, only limitation is if a user name is duplicated in more than 1 domain, eas to overcome if you know about it. Another method was to include the domain suffix, for example, dfhk\myname or dfsg\myname at log in, or adding a drop down list of domains to append to the login screen.

I see 2 solutions to this. It maybe a solution for a plug in to be deployed for various styles of solution, considering that the LDAP part is also a plugin of sorts.

So I am still trying to figure a solution for openfire. any success stories yet?

I know that something along this line was possible with s2s communication, therefore I had thought it may be possible to create a plugin that utilizes the s2s protocol to create the appearance of multi-domains. If a plugin were designed to interface with this, and says, "oh you're talking to this other domain, let me check if this is a valid use... ok it is, handle the connection", it seems plausible.

Hi all,

We realize that adding multi-domain support to Openfire is a very sought after feature. We're very aware of this request, and, if this was easily achievable, we would most likely have done it already. In reality, the way that Openfire code has been set up makes running multiple domains from one instance effectively very hard, if not impossible, to realise in any effective manner. For this reason, we're going to close this issue as "won't fix". I'm aware that we're going to disappoint a lot of users this way, and I'm sorry for that. Sadly, this feature is currently not feasible.
Regards,

Guus

Hi All,

Even I am facing the issue in adding multiple domain in one openfire server, If any of you know how to configure it, please help me.

I need to configure domain1.com and domain2.org in a single openfire server.

Ravi

It looks like ejabberd supports multiple XMPP domains: http://www.google.com/search?q=xmpp+multiple+domains+ejabberd

Prosody XMPP server also supports this and it's running happily on my server for quite some time now, replacing Openfire.

Hi, I need this feature. Is this Jira closed by mistake, impossible to add, lack of resource?

Yes, that would be a really, really welcome addition

Many moons ago when I looked at implementing this, I asked around and it seemed most people who needed it only needed a few (2-4) domains or domain aliasing (example.com and example.net go to the same place). The level of effort required to refactor OF to support this is pretty high, and the gains seem minimal. If you only need a few domains, you can set up multiple OF instances on the same system by giving the system multiple IPs and binding instances to specific IPs. Its not a solution for all problems, but there is not enough interest/drive from the development community to implement this feature. If its of value to you (or anyone else) your best bet would be to hire a programmer to implement the feature.

It is possible to reopen this ticket?

Hi,

Is there any way to add multi-domain support in openfire by installing single server instance.
If this feature was enabled in newer versions please let us know the version number.

Please note that Openfire does not, and will not, support multi-tenancy. Please read the comments made earlier if you're interested in the reasoning behind this.

Despite popular demand, this decision will not be reverted. I am closing this issue, to prevent further comments on this issue.