I am looking into how Openfire deals with users. At the moment I am using an LDAP server as a user provider for Openfire, but I am running into difficulties because it is treated as read-only. I am using the userservice plugin to deal with user data from external services, but obviously it cannot modify any information for a user because I use LDAP, so that is not very helpful. Having looked at the source code of Openfire, this appears to be simply because these operations have not been implemented, for example createUser, deleteUser:
Openfire/LdapUserProvider.java at master · igniterealtime/Openfire · GitHub
I am thinking about patching the Openfire source code so that it supports these operations for LDAP, but is there a good technical reason why they were not implemented in the first place? What do the original developers know about LDAP that I do not? If it is inadvisable to patch the code in this way, what is the best approach for working with LDAP and modifying user data? I have heard (and also seen in the source code) that Openfire has a user cache, so deleting directly from the database is not recommended because it would cause problems with that.
Also, I am using Openfire 3.9.1 because I have heard about the problems with LDAP in Openfire 3.9.3 and I am also using the Hazelcast clustering plugin to allow several Openfire servers to work together.
We are desperate for Openfire developers with LDAP expertise to help improve the code. I suspect the reason it has always been read-only is just to prevent confusion and all kinds of potential tracebacks as write-operations are attempted. Are you able to help out with the LDAP code?
So far, I have this ‘solution’: use the userservice plugin to delete all roster items for a user; use an external module that already interfaces with the LDAP server to delete the LDAP user outside of Openfire. Openfire does not seem to care that I have deleted a user from LDAP externally and the user simply no longer appears inside Openfire. It seems that in the worst case the user remains in the Openfire cache for a few hours before it is removed by the system. However, I am concerned about the possibility that references remain in the in-memory cache that point to deleted users since these changes happen outside of Openfire. I am afraid in that case that I will start getting NullPointerExceptions (or similar) possibly causing a crash or at the very least, errors in the log files. Can you give details on the internal workings of the Openfire user management system?
As for me personally working on the Openfire LDAP code, I am hesitant to do this. Firstly, I have been discouraged to do this on company time and I do not find the problem attractive enough to work on in my free time; secondly, I am in no way an LDAP expert and I have no real-world Java experience; thirdly, I have a feeling that this problem will be like opening a can of worms – as I said, I am suspicious as to why it has not already been attempted. Having said that, I do think I could probably pull it off, which is why I thought about doing it in the first place. Please could you provide a detailed description of what needs to be done? If it does not take zillions of hours, I might consider doing it in my free time.
Thanks for your interest in Openfire. Note that we have intentionally avoided providing an LDAP administration console within Openfire, and this is not a capability we intend to add going forward.
In most deployments an LDAP-based installation will come with its own set of administrative tools for managing users, groups, and policies (for example, Windows AD server). These tools are designed to provide centralized management of various access controls across multiple applications and services. The Openfire LDAP integration is designed to integrate with these LDAP-based services for authentication and user/group association on a read-only basis, as a dependent application rather than as a standalone LDAP administration utility.
I am using the userservice plugin to deal with user data from external services, but obviously it cannot modify any information for a user because I use LDAP
As Tom pointed out, why are you not using LDAP tools to update LDAP directly for users and groups?
You can still add roster Items and roster groups, but no shared groups or users. If you are using MS Windows Active Directory, then this is best done with PowerShell.
We specifically would like to do this, ideally with LDAP:
user1 has a private roster item with user2
user1 also has a private roster item with user3
However user2 and user3 are not on each other’s roster.
Can this be managed purely in LDAP? We understood that you can only manage groups which would mean, user2 and user3 are visible to each other if they are both in a group with user1.
One way is to create a shared group for user1 and user2 and another for user1 and user3 from LDAP. You still need to enable the ldap groups as roster groups from Openfire admin. Openfire has a group properties table that holds the exItra group data.