Aliases or login JID not "real" JID

9 posts / 0 new
Last post
Aliases or login JID not "real" JID

I want to have a permanent JID that is basically a GUID as the node part. This seems normal. But I want to be able to have the user login using an alternative username/JID that isn't their GUID (so they don't have to memorize this GUID). The XMPP server will be used mostly for automated non-human logins, but sometimes a human will login as well. Everyone has a GUID as their username but we don't want to force the humans to memorize a GUID.


- Fred's real JID is abcdefg1234567@test.tld, but he logs into the XMPP server as
- Jane can send messages to Fred via his real JID (the GUID-based one). Or optionally (not required for my needs, but would be nice) she could send messages to his login JID that isn't the GUID-based one. No matter what, I'd want the "from" address to be the GUID-based JID, not the "fake" login JID.

It seems like it could be done at login: receive the user's login JID during the login process and convert it into the proper GUID JID (discarding the login JID is fine). This would need to be done on the server side, not on the client side.

Could it be done with a stringprep processor? (I'm not totally clear on the stringprep's intent, but maybe?)



I am afraid this is not possible right now. I mean there is no ready to use solution. Some coding is needed. First place to start would be with SASL authentication and resource bind, which both can help you with authenticate one JID while using another.
There is however no way you can internally redirect traffic addressed to one JID to another JID. Aliases are not available yet in the Tigase, sorry.


If I were to write the appropriate code for this, where would I do it? What handles the resource binding? I have a feeling that it would be the best place to start.

All the plugins are locates in package: tigase.xmpp.impl. There is also an online guide to plugin development. You definitely have to modify authentication plugin as it is responsible for setting correct user name (JID) and also you might need to modify resource bind plugin as it sends user JID back to the client.
But this is the easy part. Much more difficult is to do the redirection part inside the Tigase server, so packet addressed to one JID is delivered to another JID.
To be honest, it is not yet implemented in the Tigase because I don't have a good idea how to do it efficiently. Unfortunately I am too busy right now to work on this.

Actually, I have just realised I am working on something which can solve your problem right now!
I am working on AMP implementation for the Tigase server. One of possible actions for the message is 'forward' which could be somehow used to forward message addressed to one JID to be delivered to another JID.
It is not entirely aliasing and what you are asking for but it might be used to some extent.


"But this is the easy part. Much more difficult is to do the redirection part inside the Tigase server, so packet addressed to one JID is delivered to another JID."

I'm not so worried about the redirection. The only important part for me is that the server can deal with the login JID (jim@server.tld) being different from the real user JID (38a52be49352453eaf975c3b448652f0@server.tld).

I'll start digging into this and see what comes out.



This is what I did to make it work. The code below was stuck into server/xmppsession/ in handleLogin(). And of course I created my own MyMappingDB class to do the mapping I needed. Pretty easy! I don't know if there are any gotchas with doing it this way yet, but it works nicely so far.

if (conn.getDomain().equals(""))
userName = MyMappingDB.uuid_from_loginid(userName);
conn.setDomain(new VHostItem(""));
// this below line already existed in the file
userId = BareJID.bareJIDInstance(userName, conn.getDomain());

Hehe, nice stuff. I wish there was something more pluggable in the Tigase so you don't have to modify existing code. This would make you easier to upgrade to later version.
To be honest i am not sure what are the implications in terms of performance, resource usage and inter-domain federation.
I guess you will soon find out.


It seems that it reliably only does this mapping one time at login. That way there would only be an extra bit of effort at that one moment, and not every single packet (which is what would have to happen if we didn't do this mapping, for our purposes, unless we used a cache all over the place, but that'd be less preferable for us). It *feels* efficient, but we'll see what happens over time. Hopefully I'll report back with some details about that after we've tested it out.

We don't need inter-domain federation (in theory), though we do need clustering. I'm not sure what effect this will have on clustering. If it's a negative effect, we'll have to re-visit how we've done it and fix that. I'm hoping it just works. We will see. Of course our mapping tables would be replicated along with the rest of the database that is replicated between XMPP servers in the cluster. We haven't tested or even implemented a Tigase cluster yet, so we don't know what effects this will have on it.

I know that we'll have to actually put work into upgrading to new versions, but that might be okay for us. Tigase will be a pretty major part of our system and we're willing to put in work to make sure we can keep using new versions. If we can figure out some neat pluggable way to do this same thing, we'll probably submit a patch to help out with that.

So far we're really loving Tigase. You guys have done fantastic work on it.