JGroups has always been pretty weak on the security front, so there wasn't any encryption until about 2 years ago (ENCRYPT), and any member could join a group and wreak havoc. To be quite honest, I never cared much about security (I think it's pretty boring), and in most cases JGroups is used behind a firewall anyway, which is generally considered a safe zone.
However, with more and more users using JGroups in a WAN setting, this meant that (unless you used VPNs or secure IP tunnels), anybody could eavesdrop on JGroups traffic, and even worse: anybody with a matching stack could join the group and start receiving and sending messages !
So about 2 years ago, Steve Woodcock, a smart bloke from London wrote ENCRYPT, or rather rewrote it (the first version was pretty bad). So we had encryption of messages... but still anybody could join the group.
Over the last couple of months I've heard more and more requests for a feature that allowed only authorized members into the group. So naturally that feature was discussed on the JGroups dev list. However, often times a lot of people add their 2 cents, but nobody is willing to actually implement it :-) Then, this summer I went to do a JGroups consulting at a large insurance company in Switzerland, and we somehow got into the topic of authentication. The discussion got pretty detailed (I think we had time left at the end of the 2 days), and we came up with a pretty detailed description of AUTH). They, however, didn't have the time or resources to implement it right away.
Enter Chris Mills, who attended my Clustering training in Washington D.C. in October. In the JGroups presentation I mentioned AUTH, and he started hacking away at it. At the end of the training, he had a prototype ready, and last week during my Clustering training in London, he presented a quite complete version of it. I think he started writing it because he wanted to see how a JGroups protocol works, and (maybe unexpectedly?) ended up with a full blown protocol. Great job Chris ! We will see this being integrated into the 2.3 head version of JGroups early next year. This is how it works:
- AUTH is just below GMS and intercepts JOIN_REQ requests
- On the client side, AUTH adds some credentials (e.g. a X.509 cert or a password) to the JOIN message
- On the server side (coordinator), AUTH extracts the credentials and verifies it. If true, it passes the request up to GMS, otherwise it sends back a JOIN_RSP, which will causes an exception at the client on Channel.connect().