History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: JM-919
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Gaston Dombiak
Reporter: Matt Tucker
Votes: 121
Watchers: 77
Operations

If you were logged in you would be able to see more operations.
Openfire

Add multi-domain support (Virtual Domains)

Created: 12/21/06 09:12 PM   Updated: 05/26/08 04:04 PM
Component/s: Core
Affects Version/s: 3.1.1
Fix Version/s: 3.x

Time Tracking:
Not Specified

Support Plan Customer Issue: No
Acceptance Test - Add?: No


 Description  « Hide
Add support for Wildfire to handle multiple domains from a single instance.

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
M.Kiesel - 07/31/07 04:42 AM
What OpenFire components/source files probably need to get updated in order to implement this? Any caveats?

constantin m. - 07/31/07 05:42 AM
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


Owen Taylor - 08/02/07 04:35 PM
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.


M.Kiesel - 08/03/07 03:27 AM
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.

Owen Taylor - 08/03/07 11:29 AM
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.


Jay - 08/16/07 09:46 AM
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.

Craig Woodward - 10/30/07 02:49 PM
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.


Alex Milowski - 11/07/07 01:09 PM
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.


Yves Goergen - 11/07/07 01:19 PM
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.

Alex Milowski - 11/15/07 10:33 AM
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!


Jorge Chandra - 11/30/07 09:42 AM
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.

Craig Woodward - 11/30/07 10:02 AM
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.

Jorge Chandra - 12/03/07 09:49 AM
Craig: I will probably use ejabberd.

Bill Chan - 12/10/07 01:14 AM
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.

Alipio Luiz - 01/09/08 07:11 PM
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


Bart Verwilst - 02/11/08 07:52 AM
This is BY FAR the most votes for feature, yet it is still only marked for "future versions", and not for 3.5 ...

Jay - 02/11/08 07:57 AM
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.


Craig Woodward - 02/11/08 09:02 AM
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.

Brent Stephens - 02/24/08 02:01 PM
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.

Craig Woodward - 05/25/08 10:31 PM
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

Daniel Henninger - 05/25/08 11:44 PM
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. =)