I know this is specifically for scalability, but there are some concerns that I have that I’'d like to have answered before this project gets too far along.
The goal is to be able to support 100k+ users (which by looking at how far this project has come, I wouldn’'t be surprised to see it reach that level of capability).
Well, if (for whatever reason) a site would like to keep the jive user database in MySQL/Postgres (as many smaller and mid-sized sites do), what thoughts have been given in the direction of JM-291: “Allow hashed password to be stored in the db”?
Given the size projections that are being shot for, security / user passwords must be in a secure format and not in clear text. Client <-> Client or Client <-> Server <-> Client encryption help secure the data, but that still does not help if the user databases have been compromised.
Ultimately, my question is:
Along with higher user capacities managed by JiveMessenger, are the other concerns of Enterprise scale requirements being taken into account?
Thank you.
I just saw the message about the knowledge base article.
I’'ll just wait to see if this gets addressed at some point by the main development group at some point.
I’‘ll address your last question first regarding the Enterprise scale requirements. Simply put, yes. We’‘re looking at improving Messenger to be better integrated into an enterprise. The first cut is to provide better O&AM (Operation, Administration, & Management) of the entire system. With Pampero, there will now be more than one jvm to manage and it can quickly get out of control if a problem arises. We also want a mechanism to capture statistics on runs so we know that our improvements are actually working. This will be accomplished by using JMX. ryang is working on a commercial plugin for monitoring messenger and he’'ll most like take advantage of this architectural decision.
Now to address your original question. There are two ways to look at this problem. If JM is working by itself and you don’‘t have an existing user database, than JM-291 is the solution we need to look at, at least for passwords. This also assumes that the other profile information isn’‘t important and that if you are comprised by say a nosey operator, then at least the passwords are secure (to a point…hopefully MD5 was suggested as the hash function). JM-291 is the first perspective, the second, and this will probably be more interesting to those looking at Pampero to extend their existing community is to leverage their existing identity database (like AD, iPlanet or OpenLdap) in which case, the security of users’’ password is not our concern (except for that pesky profile data).
Interestingly enough, the chat with Rod Chavez from Google Talk revealed that Google uses it’‘s equivalent for a CM to delegate to a Authentication service before sending it back to their core XMPP server. I think that authentication is expected to be performed on our messenger server for the time being, but it does highlight a architecture decision that we should take a closer look at. Since Google’‘s authentication is strictly their own, interoperability is easy…however getting back to your second question, what identity options would you like to see? libertyproject.org comes to mind, but that’'s a pet interest of mine.
Noah
So I’'m still not sure how to enable password encryption (hashing) in the database. Is this an option in the GUI?
Thanks for any help,
Rob