![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
Your Permissions Module runs in the JVM within the EMS server, and connects to tibemsd using the JACI interface. Like the LoginModule, the Permissions Module provides an extra layer of security to your EMS application. It does not supersede standard EMS procedures for granting permissions. Instead, the module augments the existing process.When a user attempts to perform an action, such as subscribing to a topic or publishing a message, the EMS server checks the acl.conf file, the Permissions Module, and cached results from previous Permissions Module queries, for authorization. This process is described in detail in How Permissions are Granted.In order to speed the authorization process, the EMS server caches responses received from the Permissions Module in two pools, the allow cache and the deny cache. Before invoking the Permissions Module, the server first checks these caches for a cache entry matching the user’s request.
•
1. First, the server checks the acl.conf for authorization. This is the standard EMS mechanism for granting permissions, as is documented in Chapter 8, Authentication and Permissions.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.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.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 on page 248. Figure 16 shows the decision tree the server follows when granting or denying permissions.Figure 16 The Permissions Decision Tree
There are some special circumstances under which the request, although it is not exactly matched in the acl.conf file, will be denied without reference to either the permissions cache or the Permissions Module. Any request will be denied if, in the acl.confIn general entries in the acl.conf file supersede entries in the Permissions Module, allowing you to optimize permission checks in well-defined static cases. When the acl.conf does not mention the user, the Permissions Module is fully responsible for permissions.A permission result from the Permissions Module can allow or deny the user authorization to perform the action on a range of destinations by including wildcards in the destination name. For example, even though the application attempts to have user mwalton publish on topic foo.bar.1, the Permissions Module can grant permission to user mwalton to publish messages to the topic foo.bar.*. For as long as this authorization is cached, mwalton can also publish to the topics foo.bar.baz and foo.bar.boo, because foo.bar.* contains both those topics.As long as a permission to perform an action on a destination is cached in the allow cache, the user will be authorized to perform that action, even if the permission is revoked in the external system used by the Permissions Module. This permission also extends to any destination contained by the authorized destination through the use of wildcards. The EMS server checks the allow cache for permissions before checking the deny cache and before sending an uncached permission request to the Permissions Module. In other words, the authorization status cannot be changed until the timeout on the cache entry expires and it is removed from the cache.It might seem that, if foo.*.baz were in a cache, then foo.bar.* would match it and permissions for that destination would come from the cache. In fact, however, permissions could not be determined by the cache entry, because foo.bar.* intersects but is not a subset of foo.*.baz. That is, not every destination that matches foo.bar.* will also match foo.*.baz. The destination foo.bar.boo, for example, would be granted permissions by foo.bar.*, but not by foo.*.baz.Since not all destinations that foo.bar.* matches will also match foo.*.baz, we say that foo.*.baz intersects foo.bar.*. The cache entry can determine a permission if the requested destination is a subset of the cache entry, but not if it is merely an intersection. In this case, permissions cannot be determined by the cache.The destination foo.>, on the other hand, contains as subsets both foo.bar.* and foo.*.baz, because any destination name that matches either foo.bar.* or foo.*.baz will also match foo.>. If foo.> is in the cache, permissions will be determined by the cache.Extensible permissions are enabled in the EMS server, through parameters in the tibemsd.conf configuration file. The required parameters are:
• authorization—enables authorization.
• jaci_class—specifies the class that implements the Permissions Module.
• security_classpath—specifies the JAR files and dependent classes used by the Permissions Module.The Permissions Module will be used to grant permissions only to those destinations that are defined as secure in the topics.conf and queues.conf configuration files. If there are no topics or queues that include the secure property, then the Permissions Module will never be called because the server does not check permissions at all.Because the Permissions Module runs in the Java virtual machine, you must also enable the JVM in the EMS server. See Enabling the JVM for more information.The Permissions Module is a custom module that runs inside the EMS server within a JVM. The Permissions Module is written using JACI, a set of APIs developed by TIBCO Software Inc. that you can use to create a Java module that will authorize EMS client requests. JACI provides the interface between your code and the EMS server. JACI is a standard component of EMS, and JACI classes and interfaces are documented in com.tibco.tibems.tibemsd.security.
• The Permissions Module must implement the JACI Authorizer interface, which accepts information about the operation to be authorized.
• The Permissions Module must return a permission result, by way of the AuthorizationResult class. Permission results contain:
− An allowed parameter, where true means that the request is allowed and false means the request is denied.
− The destination on which the user is authorized to perform the action. The destination returned can be more inclusive than the request. For example, if the user requested to subscribe to the topic foo.bar, the permission result can allow the user to subscribe to foo.*. If a destination is not included in the permission result, then the allow or deny response is limited to the originally requested destination.
− The action type that the permission result replies to. For example, authorization to publish to the destination, or authorization to receive messages from a queue. Permissions can be granted to multiple action types, for example permission to publish and subscribe on foo.>. Note that the EMS server creates one cache entry for each action specified in the result.
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |