Access Control Lists (ACLs)
Note:
ACLs provide authorization for your application, but authentication is also required for robust security. To achieve robust security you should use either LDAP or SSL client-side certificate authentication in addition to ACLs. If authentication is a concern, refer to the LDAP description in the section
Using SASL , or the SSL client certificate authentication description in the section
Using SSL.
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:
Modify - Allows the subject to add/remove ACL entries
List - Allows the subject to get a list of ACL entries
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:
Use Admin API - Can use the nAdminAPI package
Manage Realm - Can add / remove realms from this realm
Manage Joins - Can add/delete channel joins
Manage Channels - Can add/delete channels on this realm
Access The Realm - Can currently connect to this realm
Override Connection Count - Can bypass the connection count on the realm
Configure Realm - Can set run time parameters on the realm
Cluster - Can perform cluster operations, such as create, delete or modify cluster information
Manage DataGroups - Can add, delete and manage any Data Group on the realm
Publish to DataGroups - Can publish to any Data Group on the realm
Own DataGroups - Can take ownership of any Data Group on the realm
Channel ACL permissions
The Channel Access Control Entry has the following controllable flags:
Write - Can publish events to this channel
Read - Can subscribe to events on this channel
Purge - Can delete events on this channel
Get Last EID - Can get the last event ID on this channel
Named - Can connect using a named (durable) subscriber
Queue ACL permissions
The Queue Access Control Entry has the following controllable flags:
Write - Can push events to this queue
Read - Can peek the events on this queue
Purge - Can delete events on this queue
Pop - Can pop events from the queue
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.
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 |
If a user is matched by more than one wildcard ACL, the user receives the cumulative permissions of all of these wildcard ACLs. If a user is matched by a combination of wildcard ACLs and non-wildcard ACLs, the effect of the permissions is also cumulative.
The subject *@* is a special case. It 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 the realm configuration parameter OverrideEveryoneUser is set to false (this is the default), then *@* will override any more specific ACL entries which match a given user. If this parameter is set to true, then *@* will be overridden by any more specific ACL entries which match a given user. OverrideEveryoneUser is one of the parameters in the Global Values realm configuration group; see the relevant section of the Enterprise Manager documentation for further information.