I’m thinking about implementing Openfire in a highly secure environment, therefore I was wondering if someone could please point me to a reference URL of what security accreditation Openfire has received or is in the process of receiving.
Cheers,
Cosmo
I don’t think Openfire has any formal (or informal) security accreditation. Here’s a not complete list of CVEs filed for Openfire or other reported vulnerabilities. Some of them still not fixed and i suspect a few not yet discovered. Most of them are about Admin Console. So, if you isolate it (firewall/proxy/etc.) and make sure admin is not browsing the net while having Admin Console opened in the same browser, then it is probably safe enough (not sure about the highly secure environments though). Ignite Realtime Security Information
Thanks for that response.
As the Openfire ‘Admin Console’ is purely an interface to the backend SQL database, which in my case is MS SQL 2016 (which has ‘Always Encrypted’ and ‘Row Level Security’ which can nullify ‘SQL Injection’ attacks), I can basically administer the entire Chat solution via PowerShell GUI scripts that make the corresponding SQL database changes via parsing the corresponding AD Security Groups memberships, hence making the Openfire ‘Admin Console’ obsolete. (e.g. new Chat users and Chat Room memberships and user access rights within a Chat Room, etc…).
So, if one takes the Openfire ‘Admin Console’ out of the security equation, can anyone else see any security issues if one runs Openfire in a very secure environment, that has no Internet access? For example, has the latest version of Openfire been Pen Tested from insider attacks, etc…?
Doing direct SQL inserts is not recommended as Openfire relays heavily on cache usage. One can use RestAPI plugin to complete most of the administration tasks, but i’m not sure if Admin Console is completely out of equation in this case.
I haven’t heard of any Pen test against Openfire. Nobody has shared one and there were none done by the community, i think. There are only a few volunteers here.
Point taken, but why cache the ‘messages’ (stanzas) when they can be inserted directly into the database, which if performance is really required, one can have a database running from memory, rather than disk.
Would you be able to point me to an Openfire URL that states this ‘caching’ feature and why it is used?
PS: I would like to run this solution just like any other large Microsoft enterprise product, that is, using Windows Security Groups and PowerShell automation where ever possible.
This might be partly because how Java operates (running everything in Java Virtual Machine in memory). Also i think the main argument i’ve heard is that RAM is faster than disk operations. Btw, live messages are not written into database, they are transmitted instantly. It only saves offline messages and group chat history. Group chat history on a busy server can generate a lot of disk writes, so it is done in flushes and it is stored in a cache. Also, Openfire’s default embedded database option (not recommended for production, but i use it) is a database stored completely in memory.
I think your best option to get explanation about this is to join our Ignite Realtime: Group Chat and ask there. Guus and dwd (if available) may have better insight on this, as they are actually Java developers (i’m not ).
As about automation, as i have mentioned RestAPI might work for you. You can try finding ‘redeyes’ in the group chat (he is the developer of this plugin) or ask in the forums about RestAPI and PowerShell combining.
Legend, thanks for all you above feed back 
I’ll now close this thread and start up another one in the Ignite Realtime: Group Chat with the same question name (for those who are following this line of questioning)