# 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.

Copyright © Cloud Software Group, Inc. All rights reserved.