Apache Shiro Authorizers

Handy Hint

Shiro v1 and v2 version end-of-life notice

As of February 28, 2024, Shiro v1 was superseded by v2.

As of June 29, 2026, Shiro v2 was superseded by v3.

Role in the SecurityManager

The SecurityManager does not perform authorization checks directly. Instead, it delegates authorization decisions to its internal Authorizer instance. When a Subject calls authorization methods such as hasRole(role), isPermitted(permission), or their variants, the SecurityManager delegates to the Authorizer.

The Authorizer determines whether the Subject is permitted to perform the requested action by checking the Subject’s roles and permissions. If the Subject has the necessary role or permission, the authorization check passes. If not, an AuthorizationException may be thrown.

ModularRealmAuthorizer

Shiro uses the ModularRealmAuthorizer by default. This implementation supports coordinating one or more Realms during the authorization process.

When an authorization check is performed, the ModularRealmAuthorizer:

Iterates through configured Realms
For each Realm that implements the Authorizer interface, calls the corresponding authorization method (hasRole*, checkRole*, isPermitted*, or checkPermission*)
Aggregates and evaluates the results according to Shiro’s authorization semantics
Returns the authorization decision to the caller

It is important to note that the ModularRealmAuthorizer treats Realms differently depending on whether they implement the Authorizer interface. If a Realm does not implement Authorizer, it is not consulted for authorization checks.

Permission and Role Checks

The Authorizer performs two types of authorization checks:

Permission Checks

Permission checks verify whether a Subject is allowed to perform a specific action on a specific resource. Methods for permission checks include:

isPermitted(permission) - returns true or false
checkPermission(permission) - throws an exception on failure

For example:

if (subject.isPermitted("account:read")) {
    //User can read accounts
}

subject.checkPermission("document:delete:report123");

Role Checks

Role checks verify whether a Subject has a specific role. Methods for role checks include:

hasRole(role) - returns true or false
checkRole(role) - throws an exception on failure

For example:

if (subject.hasRole("admin")) {
    //User is an administrator
}

subject.checkRole("user");

How Authorizers Work with Realms

The Authorizer does not directly know where to retrieve authorization data. Instead, it coordinates with configured Realms to perform the actual authorization checks.

A Realm is a security-specific data access object that knows how to retrieve authorization data from a data source (database, LDAP, file system, etc.). The Realm is responsible for:

Determining if it implements the Authorizer interface (which indicates it can perform authorization checks)
Retrieving the Subject’s roles and permissions from the data source
Evaluating whether the Subject has the requested role or permission
Returning the results of the authorization check

The Authorizer simply orchestrates this process by delegating to Realms and aggregating their results. This allows you to use multiple Realms where authorization data may come from different sources, and Shiro will coordinate the results appropriately.

Authorization with Multiple Realms

When multiple Realms are configured, the ModularRealmAuthorizer consults all Realms that implement the Authorizer interface. The results are aggregated to determine the final authorization decision.

Typically, if any Realm grants permission or role membership, the authorization check succeeds. However, the exact behavior depends on the authorization data model and how the Realms are configured. Custom Authorizer implementations can be used to implement different aggregation strategies if needed.