How Permissions are Granted

When an EMS client attempts to perform an action that requires permissions, the EMS server looks in several locations for authorization.

  1. First, the server checks the acl.conf for authorization. This is the standard EMS mechanism for granting permissions, as is documented in Authentication and Permissions.
  2. Next, the server checks the Permissions Module allow cache for authorization. If an entry matching the username, action, and destination exists in the cache, the request is allowed.

    Because destinations with wildcards can exist in the cache, an entry can have a wildcard destination that contains the requested destination. If that entry specifies the same username and action, the request is allowed. For more information on this topic, see Implications of Wildcards on Permissions below.

  3. The server then checks the deny cache for a matching entry. If an entry exists in the deny cache, the request is denied.

    As in the allow cache, wildcards used in destinations can result in a cache entry with a destination that contains the requested destination. If that entry matches the username and action, the request is denied. For more information on this topic, see Implications of Wildcards on Permissions below.

  4. Finally, if there are no matching entries in either cache, the server passes the username, action type, and destination to the Permissions Module, which returns an allow or deny authorization response. The response is also saved to the cache for the timeout specified in the response.

    If the Permissions Module does not respond to the request within the timeout specified by the jaci_timeout parameter in the tibemsd.conf file, the server denies authorization by default.

Actions that require permissions are the same as those listed in the acl.conf file, and include operations such as subscribe to a topic and publishing to a queue. Permissions are described in acl.conf. The following figure shows the decision tree the server follows when granting or denying permissions.

Note: In general, permissions are checked when a client initiates an operation. In the case of a browsing request, it’s useful to note that the server reviews permissions only at certain points during the browsing operation.

The server checks for browsing permission when a client starts to browse a queue and whenever the client needs to refresh its list of browse-able messages. The client receives the list of messages from the server when it first begins browsing. The server refreshes the list and rechecks permissions whenever the client browses to the end of the current list.