If you find that you do not want to utilize the AuthorizationInfo construct,
you are of course free to subclass the AuthenticatingRealm directly instead and
implement the remaining Realm interface methods directly. You might do this if you want have better control
over how the Role and Permission checks occur for your specific data source. However, using AuthorizationInfo
(and its default implementation SimpleAuthorizationInfo) is sufficient in the large
majority of Realm cases.

If the cache property has not been set,
the cacheManager property will be checked.
If a cacheManager has been set, it will be used to create an authorization
cache, and this newly created cache which will be used as specified in #1.

getAuthorizationInfo

Returns an account's authorization-specific information for the specified principals,
or null if no account could be found. The resulting AuthorizationInfo object is used
by the other method implementations in this class to automatically perform access control checks for the
corresponding Subject.

This implementation obtains the actual AuthorizationInfo object from the subclass's
implementation of
doGetAuthorizationInfo, and then
caches it for efficient reuse if caching is enabled (see below).

Invocations of this method should be thought of as completely orthogonal to acquiring
authenticationInfo, since either could
occur in any order.

For example, in "Remember Me" scenarios, the user identity is remembered (and
assumed) for their current session and an authentication attempt during that session might never occur.
But because their identity would be remembered, that is sufficient enough information to call this method to
execute any necessary authorization checks. For this reason, authentication and authorization should be
loosely coupled and not depend on each other.

Caching

The AuthorizationInfo values returned from this method are cached for efficient reuse
if caching is enabled. Caching is enabled automatically when an authorizationCache
instance has been explicitly configured, or if a cacheManager has been configured, which
will be used to lazily create the authorizationCache as needed.

If caching is enabled, the authorization cache will be checked first and if found, will return the cached
AuthorizationInfo immediately. If caching is disabled, or there is a cache miss, the authorization
info will be looked up from the underlying data store via the
doGetAuthorizationInfo(org.apache.shiro.subject.PrincipalCollection) method, which must be implemented
by subclasses.

Changed Data

If caching is enabled and if any authorization data for an account is changed at
runtime, such as adding or removing roles and/or permissions, the subclass implementation should clear the
cached AuthorizationInfo for that account via the
clearCachedAuthorizationInfo
method. This ensures that the next call to getAuthorizationInfo(PrincipalCollection) will
acquire the account's fresh authorization data, where it will then be cached for efficient reuse. This
ensures that stale authorization data will not be reused.

Parameters:

principals - the corresponding Subject's identifying principals with which to look up the Subject's
AuthorizationInfo.

Returns:

the authorization information for the account associated with the specified principals,
or null if no account could be found.

getAuthorizationCacheKey

clearCachedAuthorizationInfo

Clears out the AuthorizationInfo cache entry for the specified account.

This method is provided as a convenience to subclasses so they can invalidate a cache entry when they
change an account's authorization data (add/remove roles or permissions) during runtime. Because an account's
AuthorizationInfo can be cached, there needs to be a way to invalidate the cache for only that account so that
subsequent authorization operations don't used the (old) cached value if account data changes.

After this method is called, the next authorization check for that same account will result in a call to
getAuthorizationInfo, and the
resulting return value will be cached before being returned so it can be reused for later authorization checks.

doGetAuthorizationInfo

Retrieves the AuthorizationInfo for the given principals from the underlying data store. When returning
an instance from this method, you might want to consider using an instance of
SimpleAuthorizationInfo, as it is suitable in most cases.

Parameters:

principals - the primary identifying principals of the AuthorizationInfo that should be retrieved.

permissions - the String representations of the Permissions that are being checked.

Returns:

an array of booleans whose indices correspond to the index of the
permissions in the given list. A true value at an index indicates the user is permitted for
for the associated Permission string in the list. A false value at an index
indicates otherwise.

an array of booleans whose indices correspond to the index of the
permissions in the given list. A true value at an index indicates the user is permitted for
for the associated Permission object in the list. A false value at an index
indicates otherwise.

checkPermissions

Ensures the corresponding Subject/user
implies all of the
specified permission strings.
If the subject's exisiting associated permissions do not
imply all of the given permissions,
an AuthorizationException will be thrown.

This is an overloaded method for the corresponding type-safe Permission variant.
Please see the class-level JavaDoc for more information on these String-based permission methods.

checkPermissions

Ensures the corresponding Subject/user
implies all of the
specified permission strings.
If the subject's exisiting associated permissions do not
imply all of the given permissions,
an AuthorizationException will be thrown.

roleIdentifiers - the application-specific role identifiers to check (usually role ids or role names).

Returns:

an array of booleans whose indices correspond to the index of the
roles in the given identifiers. A true value indicates the user has the
role at that index. False indicates the user does not have the role at that index.