Public/Private Key Authentication

Openfire Openfire Dev
1

I would like to allow users to sign up using a on SASL based, but non-standard conforming authentication method by using public/private key method. Development of the authorization process isn’t any problem. The issue is how to catch the auth- and response- queries when the mechanism is set to something line “X-MY-PLATFORM”.

Using AuthProvider is not an option for that kind of authentication, since it doesn’t use a password. I’ve tried to implement a packet filter using PacketInterceptor. But I’ve had to learn that is not possible since the PacketInterceptor only filters IQ, MESSAGE and PRESENCE packets. AUTH and RESPONSE packets are immediatly routed to the SASLMechanism.

Does anybody has a workarround for authentication processes when there is no username/password combination used?

@Openfire Devs: It would be very, very helpful if you could make developing custom authentication processes easier in a future Openfire release.

2

We need this, too. Currently we have a ugly workaround for this. Roughly:

  1. login with ANONYMOUS.

  2. Do a RPC call to Openfire to request the Openfire password, which is returned encrypted with user’s public key.

  3. decrypt the password with private key and login in with DIGEST-MD5.

I’ve checked Openfire’s source code and saw that appearently you can set your own set of mechanisms:

String available = JiveGlobals.getProperty(“sasl.mechs”);

But it’s rechecked to be in a predefined array, with a nice comment:

// Check that the mech is a supported mechansim. Maybe we shouldnt check this and allow any?

if (mech.equals(“ANONYMOUS”) ||

mech.equals(“PLAIN”) ||

mech.equals(“DIGEST-MD5”) ||

mech.equals(“CRAM-MD5”) ||

mech.equals(“GSSAPI”) ||

mech.equals(“EXTERNAL”) ||

mech.equals(“JIVE-SHAREDSECRET”))

{

Log.debug(“SASLAuthentication: Added " + mech + " to mech list”);

mechanisms.add(mech);

}

If I think about it, it might be enough, to remove the above check and register your own SaslServer via java.security.Provider in a plugin (and also fill the sasl.mechs property).

Opinions?

1 Like
3

Really like your idea. But I don’t like manipulating Openfire code directly. It would be great if the Openfire developers would accept your idea, since it wouldn’t require much change anyway.

4

If you have time on your side, maybe you could check, if my idea works at all in the first place.

That is:

  1. Write a plugin.

  2. Write a javax.security.sasl.SaslServer implementation and add it with Provider/SaslServerFactory.

  3. Debug Openfire and maybe comment out the check and see what happens.

I guess you already have a client which supports your custom mech (X-MY-PLATFORM)!?

If this works, that would be huge and I’d really like to know what others think about it.

If there are no concerns about removing the check, it might go into a future release.

5

Yes it work. I’ve had to implement SaslServer, SaslServerFactory and Provider. Then using Sasl.addProvider() and SASLAuthentication.addMechanism() and everything works fine. There is even complete error handling implemented in Openfire for custom mechanisms, I don’t have any idea why these fixed-code check is added there and there seem to be no reason why not removing it.

I’ve added the whole stuff to a plugin and tested dynamic adding/removing for enable/disable plugin too. I’ve also checked how the server behaves when using non-existing (=auth failed+one INFO debug line of someone tried to use XYZ for auth), broken (=auth failed+stack trace in log) and blocking (ends in timeout for the client session) auth mechanism and everything seems to get handled like I would have expected it.

When implementing a custom SaslServer the easiest way is to look how ClearspaceSaslServer is implemented and do exactly the same.

But since I don’t like to use customized Openfire versions and instead like to use plugins for such stuff I hope the check will get removed in the next update of Openfire since there seems to be any reason anyway.

6

Thanks for testing this out!

I’ve filed this as OF-752.

Let’s wait, what others think about the change.

7

I just tested with myself and noticed that it does work even with the check in Openfire.

The mechanisms are only checked once at startup (static initializer).

Then the plugin is loaded and just adds another custom SASL mechanism.

From then on, everything works as one would expect.

Is there any need for action at all?

8

Hi CSH,

I am trying to build a custom authentication mechanism, since openfire supports only Anonymous and Plain when configure custom authenitcation provider.

I am looking forward to try the approach proposed by Michael. Please guide me in building a custom mechanism.

Regards,

Sagar