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.bo
o, 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.