Openfire has a hybrid auth provider so it should be possible to use two different data sources for access. You may need to look at the source code to set it up. Maybe it’s more easy to add all users to your AD.
You may want to install a connection manager for the internet users: (Internet users -
connection manager in DMZ -
Openfire). A CM seems to be a XMPP server for the clients, so they will not notice it. And you can shutdown it separately if you want to keep the internet users out.
LG
Javadoc:
org.jivesoftware.openfire.auth.HybridAuthProvider
The hybrid auth provider allows up to three AuthProvider implementations to be strung together to do chained authentication checking. The algorithm is as follows: Attempt authentication using the primary provider. If that fails: If the secondary provider is defined, attempt authentication (otherwise return). If that fails: If the tertiary provider is defined, attempt authentication. To enable this provider, set the following in the XML configuration file: <provider>
<auth>
<className>org.jivesoftware.openfire.auth.HybridAuthProvider</className>
</auth> </provider> The primary, secondary, and tertiary providers are configured as in the following example: <hybridAuthProvider>
<primaryProvider>
<className>org.jivesoftware.openfire.auth.DefaultAuthProvider<className>
</primaryProvider>
<secondaryProvider>
<className>org.jivesoftware.openfire.auth.NativeAuthProvider</className>
</secondaryProvider> </hybridAuthProvider> Each of the chained providers can have a list of override users. If a user is in an override list, authentication will only be attempted with the associated provider (bypassing the chaining logic).
The full list of properties: hybridAuthProvider.primaryProvider.className (required) -- the class name of the auth provider. hybridAuthProvider.primaryProvider.overrideList -- a comma-delimitted list of usernames for which authentication will only be tried with this provider. hybridAuthProvider.secondaryProvider.className -- the class name of the auth provider. hybridAuthProvider.secondaryProvider.overrideList -- a comma-delimitted list of usernames for which authentication will only be tried with this provider. hybridAuthProvider.tertiaryProvider.className -- the class name of the auth provider. hybridAuthProvider.tertiaryProvider.overrideList -- a comma-delimitted list of usernames for which authentication will only be tried with this provider. The primary provider is required, but all other properties are optional. Each provider should be configured as it is normally, using whatever XML configuration options it specifies. @author
Matt Tucker
Following it2000’s suggestion, one idea might be to not use a connection manager but to use a machine in the DMZ that is running a copy of Openfire with embedded database, and restrict the server 2 server interconnectivity between the two to only allow the other server. that way, you have full control over your “internal” openfire with AD, keeping it completely separated from anything else while allowing the “external” openfire server to be reached from the internet.
For the solution with connection manager, what are the requirements of hardware in the case of 300+ users from internet. Is Connection manager server in DMZ like Openfire server about resources?. Where are the extern users storaged?. Is the implementation simple?
For the solution with other Openfire server, how can i run a copy of the original Openfire server?, How can i create the copy? How do i establish the interconnectivity between both servers?. Is necesary federated servers? Is the solution simple?
For the solution with other Openfire server, how can i run a copy of the original Openfire server?, How can i create the copy? How do i establish the interconnectivity between both servers?. Is necesary federated servers? Is the solution simple?
Thank you for response
Actually, you don’t want to make a straight copy of Openfire, but rather make 2 different installations of Openfire: one in the DMZ, and one internally. (ext-jabber.domain.com and int-jabber.domain.com, for example)
So, on a different server machine (either a physical or virtual machine, makes no difference) that is in the DMZ, you install Openfire, and set it up to allow connections from the Internet/office network outside your own LAN for your users who are outside the company. You can choose here to authenticate against a different company user database (that isn’t using Active Directory), by using the embedded one with manually created different users you want to give access to the company jabber server.
In the server to server setup, you tell it to only allow server connections from your other openfire server with a whitelist (server settings > server to server > allowed to connect : whitelist). This way, the “external” users can only see the DMZ Openfire server, but can still chat with “internal” users, and the internal server and active directory is not in any way exposed.
See also the small image I slapped together, hope that clarifies what you could do. It’s relatively easy to set up, and you can do a lot more than what I just said with it, like automatic grouping/rosters, filtering traffic, etc, but this is the basic setup.
In this case, the only port that needs to be open between the DMZ and the internal lan is TCP 5269 to connect both servers (note: both directions, lan > dmz and dmz > lan), and that can be further restricted to just the IP of the other server. Everything else can be closed.
As for the other ports in that document, depending on what you plan to use, open the relevant ports.
For only client connections to the server in the DMZ, port 5222 TCP should be all you need, and perhaps 7777 if you wish to let it work as a file proxy too. Since it will be strictly private jabber servers, no other connections to the outside world would be needed from the DMZ.
I’m not familiar with this product and don’t have time to do this kind of research, but ANY software that filters/routes IP properly shouldn’t be a problem.
I suggest you look up the licensing information of all the products involved in your solution (Openfire, novell ichain, etc.),to see if there are any costs for the combination of products you use.
This process is quite simple really. But you must start with giving your openfire server a real world Fully Qualified Domain Name (i.e. chatserver.domain.com). With any luck your intranet domain is a sub domain of your external domain, meaning they both end the same way (domain.com). If not you can still name your openfire server with an external domain name. Here are the steps (blue are needed if internal domain is onot a sub domain of external domain):
Stop the openfire server
Edit the openfire.xml setup tag to be <setup>false</setup>
Start the openfire server
During the re-setup give the server a FQDN for your external domain (i.e chatserver.domain.com) on the second scree in the field Domain
Add openfire FQDN to external DNS as an A Record pointing to a real world IP
Map the ports you wish to use from attachment below from the external IP to your internal IP on the openfire server on your router, pix, firewall or what ever is between the internet and your intranet
Test by accessing the sever via a client pointing to the external FQDN, and test accessing the admin page via the external FQDN
Use the external FQDN for all clients, internal and external.