Nirvana Admin API - Nirvana Security Groups

The Administration API allows groups of users to be defined. These groups can then be used in ACL lists in-place of individual ACL entries for each user.

Security Groups can contain any number of users (user@host pairs), and may also include other Security Groups.

A new security group can be registered as follows:

nSecurityGroup grp = new nSecurityGroup("mySecurityGroup");
grp.add(add(new nSubject("user@host");
realmNode.getSecurityGroupManager.registerSecurityGroup(grp);

The SecurityGroupManager can be used to edit memberships of multiple groups at the same time, for example:

nSecurityGroupManager mgr = realmNode.getSecurityGroupManager();
mgr.registerGroupMembers(group,members);
//Members can be a single subject(user@host), a group, or a collection
//containing many subjects, groups or a combination of these.

Once a security group has been registered, it can be added into ACL lists as you would normally add a user@host entry. Subsequent changes to the membership of the group will be reflected in which users have permissions for the corresponding resources.

nSecurityGroup grp = securityGroupManager.getGroup("myGroupName");
nChannelACLEntry aclEntry = new nChannelACLEntry(grp);
aclEntry.setFullPrivileges(true);
leafNode.addACLEntry(aclEntry);

Groups can also be deregistered from the realm. This will remove the group and will remove the group reference from all ACL lists where the group currently appears. As with the other examples, this can be done via the nSecurityGroupManager:

As with all ACLs in Universal Messaging, privileges are cumulative. This means that, for example, if a user is in a group which has publish permissions on a channel, but not subscribe permissions, the user will no be able to subscribe on the channel. Then, if an ACL entry is added on the channel for his specific username/host pair, with subscribe but no publish permissions, the user will then be able to both subscribe (from the non-group ACL permission), and publish (from the group ACL permission).

Deeply nested Security Groups hierarchies are generally discouraged, since this type of configuration can negatively impact the speed of checking ACLs, and may result in worse performance than a shallow hierarchy.