Security improvements in upcoming Sun IM server release

The upcoming release is going to see some improvements in the authentication and security aspects of the XMPP server.
The primary changes are :
  1. Full support for starttls extension in addition to the legacy SSL support we had earlier.
  2. SPI's which allow server side as well as client side extension to add support for arbitrary SASL mechanism.
  3. Full support for hosted domains using Sun's access manager.
  4. Most of the relevent server side api has been made 'multi-domain aware' for extending and supporting custom implementations.

The first is actually something which was supported since IFR release to JES4 - we have significantly improved this aspect though.


The second is something which is going to be very interesting addition to the server/client spi.
Let me elaborate a bit on this :

Until now, plugging in a custom authentication mechanism used to leverage either the SSO Provider api, or a complete custom server side Realm will need to be authored.
Even then, it was restrictive since it would allow only a username/password form of authentication.
Starting from the coming release, server supports ability to plugin SASL authentication mechanisms - hence ability to support much more complex authentication schemes requiring multiple round trips.
The spi takes care of abstracting out the XMPP specific details and exposes a simple and consistent interface to the developer.
Hence, authentication can now be extended in two new ways in the server :

- Write a complete custom SASLRealm, and provide your own SASL mechanism's.
- The ldap realm, which is provided out of the box, allows for plugging in a list of arbitrary SASLServerProviderFactory's.
(Only constraint is that the user returned after authentication should map to the ldap tree.)

So, if developers want to take a full fledged custom authentication route : they can either go all the way (like support a database based Realm) and add support for complex forms.
Or else, they could just plug into the ldap realm, add support for some custom mechanisms and at the end of successful authentication, map user to the configured ldap tree.

Ofcourse, it should be remembered that adding server side support for a custom mechanism is just half the story - this will just lead to it getting exhibited to the client.
For the mechanism to get used, the client should also support of this - hence we have added corresponding client side spi to allow this.
The server and client side spi are consistent with each other - so famialirity with one should allow developer to easily mirror it at the client side reasonably fast.
It should be noted that the new authentication server side spi is already multi-domain aware.
The new server api is com.sun.im.provider.SASL\*
The new client api is org.netbeans.lib.collab.SASL\*
After the product is released, I will write a sample server and client side SASL mechanism factory and provider here to illustrate the simplicity and allow some template for others to work on.


Sun's access manager supports hosted domains through organisational mappings : though Sun IM server used to leverage hosted domain for the purpose of authentication - there were other aspects of it which was not very well supported.
Instead of fixing this feature piece-meal, we took a more holistic view and revamped the server to completely support multiple domains a.k.a hosted domains.
With this release, the server is fully hosted domain aware : it will ofcourse continue to support the legacy behaviour.
Suitable api/spi additions have been made to allow for customers to write their own implementations of Realm's and associated infrastructure which is multi domain aware.
The new server api which allows this would be com.sun.im.provider.MultiDomain\*


One interesting mention about the client side api.
The client side api has moved from com.sun.im.service.\* to org.netbeans.lib.collab.\*
We will ofcourse continue to support com.sun.im.service.\* but new feature additions will happen only to the netbeans api package (the older api impl actually just delegates to appropriate netbeans api).

What is the 'cost' of moving ? A simple search and replace of "com.sun.im.service" to "org.netbeans.lib.collab" !

Does the old api continue to work ?
We have taken significant pains to make sure that it continues to do so.
And to make sure that we do not miss out anything inadvertently, our java based IM client actually uses the old api to make sure that we do not regress anything.
Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

mridul

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks
Blogroll

No bookmarks in folder