Implications of Wildcards on 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.

Similarly, an entry in the deny cache remains there until the timeout has expired and the entry is removed. Only then does the EMS server send the request to the Permissions Module, so that a change in status can take effect.

Overlapping wildcards can make this situation even more complex. For example, consider these three destinations:

foo.*.baz
foo.bar.*
foo.>

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.