Access Control Lists (ACLs)
Universal Messaging's Access Control List (ACL) controls client connection requests and subsequent Universal Messaging operations. By default access control checks are performed within a realm.
The Universal Messaging Administration API exposes the complete security model of the Universal Messaging Realm Server, remotely allowing customer specific security models to be created. This means that it is easy to integrate Universal Messaging into an existing authentication and entitlement service.
It is also possible to manage Universal Messaging ACLs using the enterprise manager GUI.
The Universal Messaging realm has an ACL associated with it. The acl contains a list of subjects and the operations that each subject can perform on the realm.
Users are given entitlements based on their subject. A subject is made up of a username and a host.
The username part of the subject is the name of the user taken from either the operating system of the machine they are connecting from or the certificate name if they are using an ssl protocol.
The host part of the subject is either the ip address or the hostname of the machine they are connecting from.
The subject takes the form of :
username@host
For example:
johnsmith@192.168.1.2
Each channel, queue and service also has an associated acl that defines subjects and the operations the subjects can perform.
A subject corresponds to the user information for a realm connection
Each type of acl entry has a number of flags that can be set to true or false in order to specify whether the subject can or can't perform the operation.
General ACL permissions
The following flags apply to every ACL.
![*](chapterTOC_bullet.png)
Modify - Allows the subject to add/remove ACL entries
![*](chapterTOC_bullet.png)
List - Allows the subject to get a list of ACL entries
![*](chapterTOC_bullet.png)
Full Privileges - Has complete access to the secured object
Universal Messaging Realm Server ACL permissions
The Realm Access Control Entry has the following controllable flags
![*](chapterTOC_bullet.png)
Use Admin API - Can use the nAdminAPI package
![*](chapterTOC_bullet.png)
Manage Realm - Can add / remove realms from this realm
![*](chapterTOC_bullet.png)
Manage Joins - Can add/delete channel joins
![*](chapterTOC_bullet.png)
Manage P2P Services - Can create/destroy P2P services
![*](chapterTOC_bullet.png)
Manage Channels - Can add/delete channels on this realm
![*](chapterTOC_bullet.png)
Access The Realm - Can actually connect to this realm
![*](chapterTOC_bullet.png)
Override Connection Count - Can bypass the connection count on the realm
![*](chapterTOC_bullet.png)
Configure Realm - Can set run time parameters on the realm
![*](chapterTOC_bullet.png)
Cluster - perform cluster operations, such as create, delete or modify cluster information
![*](chapterTOC_bullet.png)
Manage DataGroups - Can add, delete and manage any DataGroup on the realm
![*](chapterTOC_bullet.png)
Publish to DataGroups - Can publish to any DataGroup on the realm
![*](chapterTOC_bullet.png)
Own DataGroups - Can take ownership of any DataGroup on the realm
Channel ACL permissions
The Channel Access Control Entry has the following controllable flags
![*](chapterTOC_bullet.png)
Write - Can publish events to this channel
![*](chapterTOC_bullet.png)
Read - Can subscribe for events on this channel
![*](chapterTOC_bullet.png)
Purge - Can delete events on this channel
![*](chapterTOC_bullet.png)
Get Last EID - Can get the last event Id on this channel
![*](chapterTOC_bullet.png)
Named - Can the user connect using a named (durable) subscriber
Queue ACL permissions
The Queue Access Control Entry has the following controllable flags
![*](chapterTOC_bullet.png)
Write - Can push events to this queue
![*](chapterTOC_bullet.png)
Read - Can peek the events on this queue
![*](chapterTOC_bullet.png)
Purge - Can delete events on this queue
![*](chapterTOC_bullet.png)
Pop - Can pop events from the queue
P2P Service permissions
The Service Access Control Entry has the following controllable flags
![*](chapterTOC_bullet.png)
Connect - Can access this service
Wildcard Support
As well as being able to specify an access control entry for a specific subject the subject itself can contain wildcards. In this way you can specify access control based on hostname or on username.
The subject *@* is provided in all ACL objects by default, and corresponds to the default permission that all subjects inherit who connect but do not individually appear within the ACL. If a subject is listed in the ACL, then the entitlements given to that subject overrides that of any wildcarded entry, including the *@* default subject.
Example Wildcard ACLs :
ACL Entry | Description |
*@* | Represents all users from all nodes |
*@client1.com | Represents all users from the node client1.com |
username@nodename | Represents the user "username" on the node "nodename" |
username@* | Represents the user "username" on all nodes |