powered by Jive Software

User ID question

My organization is currently working to implement a Jive Messenger server to handle our internal IM. I’'ve run into an interesting problem.

We plan to create a Jabber client which will run as an applet on a web page. In order for the applet to connect to the server without requiring the user to enter their name and password again, we want to dynamically generate the web page so that it will pass those parameters to the chat applet. We want those parameters to be an ID number and an arbitrary login ticket rather than the username and password, so that the name/pass won’‘t be visible from a browser’'s ‘‘view source’’. We will then create a custom authentication class that checks the ID number and login ticket against users who are already logged into our web systems.

I’'ve been able to write my own AuthProvider class to handle our authentication system. The problem I ran into is how to take a successful ID log in and ‘‘rename’’ the user to his real username. Is it possible for the Jive Messenger server to authenticate a user, and then change his name?

This is an interesting feature request. Right now, authentication credentials are mapped directly to the JID that you become. We could support becoming a different username after authentication but older clients (XMPP “.9”) don’'t handle this well in all cases. But, a modern client using resource binding should be able to do this without problems.

From an API perspective, we’‘d need to change AuthProvider to return the username that the user should be authenticated as after successful authentication. Once we add in full SASL support, it would probably make sense to do the change to AuthProvider – especially since some SASL auth modes won’'t have an obious correlation to username based on auth credentials alone.

For now, I would recommend using the correct username but a special one-time password for each authentication. That will let you implement the security you want for now until we make these changes to AuthProvider. The algorithm could be:

Given the username, see if the given password matches their normal password. If it doesn’'t, see if the user is logged into the web and if the one-time password matches the one defined in the session. If so, accept login.

Let me know if that will work.

Regards,

Matt

I think this is enough to get me up and running. For now I’'ll use a username and a one-time use password. It would be useful in the future to be able to use a one time user username and do the username switch we discussed and I think that it has applications to other situations as well.