|
[
Permalink
| « Hide
]
M.Kiesel added a comment - 07/31/07 11:42 AM
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
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 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:
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 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. 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.
I really need this feature too...
I need to configure subsets of a real world domain of Active Directory like below: 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
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). any news on this requested feature?
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. 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.
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).
This may be a better (and cheaper) solution 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.
Oh, sorry, this is true, we cannot trust DNS → so this is cheap but foolish solution.
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?
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! |
||||||||||||||||||||||||||||||||||||||||||||||