Friday, September 17, 2010

Cluster authorization with pattern matching

I've added a new plugin to AUTH which allows for pattern matching to determine who can join a cluster.

The idea is very simple: if a new node wants to join a cluster, we only admit the node into the cluster if it matches a certain pattern. For example, we could only admit nodes whose IP address starts with 192.168.* or 10.5.*. Or we could only admit nodes whose logical name is "groucho" or "marx".

Currently, the 2 things I match against are IP address and logical name, but of course any attribute of a message could be used to match against.

Let's take a look at an example.

<AUTH auth_class="org.jgroups.auth.RegexMembership"
      match_string="groucho | marx"
      match_logical_name="true" />

This example uses the new plugin RegexMembership (derived from FixedMembership). Its match string (which takes any regular expression as value) says that any node whose logical name is "marx" or "groucho" will be able to join. Note that we set match_logical_name to true here.

Note that AUTH has to be placed somewhere below GMS (Group MemberShip) in the configuration.

<AUTH auth_class="org.jgroups.auth.RegexMembership"
      match_logical_name="false"  />

This example is a bit more complex, but it essentially says that all nodes whose IP address starts with 192.168 are allowed to join the cluster. So and would pass, while would be rejected.

I have to admit, I'm not really an expert in regular expression, so I guess the above expression could be simplified. For example, I gave up trying to define that hosts starting either with 192.168 or 10.5 could join.
If you know how to do that, please send me the regular expression !


  1. (192\.168|10\.5)\.\d{1,3}\.\d{1,3}(:\d{1,5})?

  2. Excellent, thanks Takayoshi !

  3. Excellent! I'm sure people will find this very useful.

  4. Anonymous5:52 PM

    Are there other ways to limit who can and can not join the cluster? Can you request new members to provide user ID and password (or some other way to authenticate) before they will be admitted to the cluster?

  5. Yes, the following plugins are currently shipped with JGroups:

    - Fixed membership: predecessor to reggular expression. Essentially a list of IP addresses (I'd prefer RegexMembership)
    - A simple MD5 hash
    - SimpleToken: a simple password
    - X.509 certificates

    The mechanism is pluggable, so anyone can plug in their own authorization mechanism...

  6. explains this in a bit more detail

  7. Perhaps some IPv6 addresses should be normalized to IPv4 ones (or the opposite)? For example, ::1 is identical with as you know. Actually normalization is non-trivial when IPv6 is involved since there are couple abbreviation rules. Once implemented, it will be a good utility though.

    BTW, what the example tries to achieve could be done using the CIDR notation + some port range property? (e.g.

  8. Yes, I guess this could be done. The mechanism doesn't need to change; the dev has to provide a correct regex to match IPv4 or IPv6 addresses. For IPv6, the regex can become quite complex though...