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.
Recovering Accidentally Removed ACL Permissions
If you cannot connect to a Universal Messaging server because you accidentally removed realm ACL permissions, you can use the SECURITYFILE property in the Server_Common.conf file of the server to restore the lost ACLs. The server processes the SECURITYFILE property even when a realm configuration exists on disk in the realms.nst file.
To recover permissions, create a security file with the required super users in the format
user@host and specify the file as a value of
SECURITYFILE, as described in
Server Parameters. Then restart the server.
Consider the following information when you recover permissions:
The
SECURITYFILE configurations you pass to recover permissions are not permanent, but are kept temporarily in-memory as long as the server is running. You must manually add the lost ACLs after you regain access to the server to persist them into the realm configuration on disk.
If you want to grant super-user privileges to an ACL entry that already exists in the realm configuration but does not have full privileges, you cannot do so by adding that ACL to the security file because the server will disregard it. The workaround is to add a new ACL entry.
For example, the realm configuration contains the ACL admin@* that does not have full privileges. To restore full privileges for the admin user, you can add a new entry to the security file, such as admin@127.0.0.1, which will grant the admin user full permissions for the realm at host 127.0.0.1.